Should be zlib1.dll. Redowload the server, go into bin, and grab the file by this name and put it in the exact same folder as the .exe. If the problem persists post a picture of the .exe for the server (The file its contained in and the error itself) and we'll see if we can rectify the issue.
I dropped this on Sourceforge as well, but I think I'll put it here to and make sure ti is known.
I suppose this is not a patch per se since I dont have a diff file, but the
help message could be handled prettier by using an array of CStrings.
so instead of the following:
const char *PLAYER_HELP_1 = "&7This is a list of custom features and
commands ";
const char *PLAYER_HELP_2 = "/me [message] &f- Simple emote
command ";
we would have this:
char **PLAYER_HELP[10][MAX_CHAR_PER_LINE];
char *PLAYER_HELP[1] = "&7This is a list of custom features and commands
";
char *PLAYER_HELP[2] = "/me [message] &f- Simple emote command
";
you can then use a loop to run through the help messages. This also opens
up a command to allow one to display the help messages to everyone, or to
only display lines 3-7. Adds much more flexibility and removes some ugly
code.
-Dandistine
Basically replace the const strings with an array of C-Strings that you don't edit. Now that I think about it, this would allow you to edit the help messages while the server is running, you wouldn't have to recompile it every times you wanted to change the message. If they were dynamically allocated as well you would also be able to add new lines (or remove lines) to (from) the help message on the fly.
You can do the same for the block-type messages as well. You can use the type (as a char) to determine which message is sent. This cleans up the code where you change blocks as well since the message is not really static anymore. So instead of the following case statement
or something similar where STD_END_BFFR is a function (look up table) that would normalize the message length based on the block type. So for BLOCK_NORMAL, it returns 34, but for BLOCK_AIR it returns 4.
Since I think you are doing a fill command, an easy way to do it would be to require 6 arguments looking like this:
the set_dir_x (y and z) determine whether the loop needs to be incremented or decremented based on the positioning of the start and end points. And optional command would be /fill X Y Z where X Y Z is the endpoint, and the start point is the location of the user (user could be moved back 2-3 blocks since he is in the way)
All for now. I'm sure i'll come up with some more shenanigans later.
Sorry to hear you aren't feeling well vLK. Hopefully you'll be able to give some good feedback when you feel better.
My whole idea on programming is to provide a general solution, and let the program determine how to use it. A few extra CPU cycles to evaluate an extra function is not that much, but being able to expand the server by adding a single line of code as opposed to 30 means everything.
I'll look through it again, there may be a better (maybe, not sure yet) way to handle the banlist and current character list.
On a side note, maybe the help messages should be defined in a config, would shave a kb or two off the final binary size while maintaining a similar memory footprint.
I think the commands function could be better handled as a case statement with the level evaluations done when the command is being executed. Currently to get to the "most powerful" commands, you have to go through every power check. For instance, if my level is 202 and I ban someone, it shouldn't matter whether or not I'm below level 51. It should move to the command, then determine if I can use it, like the following:
case cmd == ban:
if(player-> level >= LEVEL_ADMIN)
banPlayer(*playerName);
else
invalid_level();
break;
case cmd == unban:
etc
etc
This helps avoid the less useful (and time consuming) checks and when an invalid command IS used, the results are immediate. You don't have to wait for every if statement to follow through before the results are known. The time saving is not particularly important in commands, but it could be in other areas.
Another suggestion, make the level separations adjustable in the config (but make them default to the current). This would be for the same reason that the help messages should be dynamic, it allows customization of the administration.
The case statements work with almost everything without modification (except doubles, floats, and their derivatives).
If it would be done that way, it means that a normal user could run /ban and get refused inside the ban { } rather then after his levels "section".
That is the idea. Regards of where he is refused, the function returns boolean, true or false. It doesn't matter where the command is refused, just that a refusal happens.
If commands are indexed using some number (char, integer, doesn't matter) then a single strncmp() can be performed, allowing the more efficient case statement to be run, rather than compare string X 18 times, string X is converted to a value integer Y which is then used in an if chain or a case (each case checks for proper power level of course). This may actually eliminate some string comparisons (which are inefficient) and it makes things look pretty. At the very least it would take the same time to execute, but the code looks nicer.
New way to do things. Chain together if statements checking power level, THEN check commands.
If(power == admin)
if cmd == ban
ban()
else if cmd == restart
restart
else if(power == OP)
if cmd == tp
tp()
else if cmd = fill
fill
else if (power == user)
if cmd == help
help()
else return false
Something like that. Avoids the unnecessary checks for the higher commands and maintains a semblance of the current structure. Best of both worlds.
Unison, add custom build commands.
Like /box and /line (Credit to Dadido3)
vLK and I are building a waterfall using still water, but it's so big we can't do it by hand.
Exactly the same thing
Should be zlib1.dll. Redowload the server, go into bin, and grab the file by this name and put it in the exact same folder as the .exe. If the problem persists post a picture of the .exe for the server (The file its contained in and the error itself) and we'll see if we can rectify the issue.
did just hide the names and ip, but this did not crash the server, only all the clients!
Basically replace the const strings with an array of C-Strings that you don't edit. Now that I think about it, this would allow you to edit the help messages while the server is running, you wouldn't have to recompile it every times you wanted to change the message. If they were dynamically allocated as well you would also be able to add new lines (or remove lines) to (from) the help message on the fly.
You can do the same for the block-type messages as well. You can use the type (as a char) to determine which message is sent. This cleans up the code where you change blocks as well since the message is not really static anymore. So instead of the following case statement
You can (or could, don't know how memcpy works) replace the entire switch-case section with the following:
or something similar where STD_END_BFFR is a function (look up table) that would normalize the message length based on the block type. So for BLOCK_NORMAL, it returns 34, but for BLOCK_AIR it returns 4.
Since I think you are doing a fill command, an easy way to do it would be to require 6 arguments looking like this:
/fill X_START X_END Y_START Y_END Z_START Z_END
using a loop you can loop through these as such:
the set_dir_x (y and z) determine whether the loop needs to be incremented or decremented based on the positioning of the start and end points. And optional command would be /fill X Y Z where X Y Z is the endpoint, and the start point is the location of the user (user could be moved back 2-3 blocks since he is in the way)
All for now. I'm sure i'll come up with some more shenanigans later.
I have plans already to re-do the help command, I will definitely use your advice :smile.gif:
My whole idea on programming is to provide a general solution, and let the program determine how to use it. A few extra CPU cycles to evaluate an extra function is not that much, but being able to expand the server by adding a single line of code as opposed to 30 means everything.
I'll look through it again, there may be a better (maybe, not sure yet) way to handle the banlist and current character list.
On a side note, maybe the help messages should be defined in a config, would shave a kb or two off the final binary size while maintaining a similar memory footprint.
I think the commands function could be better handled as a case statement with the level evaluations done when the command is being executed. Currently to get to the "most powerful" commands, you have to go through every power check. For instance, if my level is 202 and I ban someone, it shouldn't matter whether or not I'm below level 51. It should move to the command, then determine if I can use it, like the following:
This helps avoid the less useful (and time consuming) checks and when an invalid command IS used, the results are immediate. You don't have to wait for every if statement to follow through before the results are known. The time saving is not particularly important in commands, but it could be in other areas.
Another suggestion, make the level separations adjustable in the config (but make them default to the current). This would be for the same reason that the help messages should be dynamic, it allows customization of the administration.
That is the idea. Regards of where he is refused, the function returns boolean, true or false. It doesn't matter where the command is refused, just that a refusal happens.
If commands are indexed using some number (char, integer, doesn't matter) then a single strncmp() can be performed, allowing the more efficient case statement to be run, rather than compare string X 18 times, string X is converted to a value integer Y which is then used in an if chain or a case (each case checks for proper power level of course). This may actually eliminate some string comparisons (which are inefficient) and it makes things look pretty. At the very least it would take the same time to execute, but the code looks nicer.
New way to do things. Chain together if statements checking power level, THEN check commands.
Something like that. Avoids the unnecessary checks for the higher commands and maintains a semblance of the current structure. Best of both worlds.
When in paint mode, deleting a block instead replaces it with the currently selected block. (Compatible with /setblock).
Like /box and /line (Credit to Dadido3)
vLK and I are building a waterfall using still water, but it's so big we can't do it by hand.
Rules menu!
welcome message
:biggrin.gif:
cool, time for me to update SVN again :smile.gif:.
you can join me :biggrin.gif: im running updated minerCPP on Blaxors Free Build TEST Server :biggrin.gif:
A true work of art :biggrin.gif:
You guys are updating the svn with features too fast for me to keep up, I love it.
You stole my seal. :sad.gif:
I don't care though, as its public domain.