xazax

Windows is very resource hungry, for example you always run several GUI related services. However if you use linux, the base system can use really low RAM, for example: 50MB or bellow.

A better practice to store pernament data in SQL tables.

I think it is a great idea to cleanup the leftovers from txt from makefile. Fixing the problems with script files are also a great thing to do. Unfortunately I'm not competent enough with makefiles to revise your changes, but based on your description I like them so far. My only request: just try to test the new settings on as many platforms as possible.

About comments above functions... Doxygen?

Same, I really wanted to do one with Z3R0 but then he vanished and I kinda got lost with other stuff lol. <off>Yay! Mercurial is back! </off> There were multiple script converters posted in the dev area, I don't know where did they go. Once I started to write an item converter with Muad, however unfortunately my time schedule become extremely busy (university, job and research). But the aegis databases are soo different, it is not straightforward to write a converter, but it would be great to have one. As far as I remember Mercurial likes to write parsers and converters with his beloved .Net and C#. Let's make him write one

Status icon would not be a problem, I'm almost 100% sure about that. As long as the selected status icon is available on the client side of course.

In my opinion using scripted statuses would not reduce performance significantly (of course they would not perform as good as hard coded ones, but I doubt that overhead would be noticeable even for popular servers). However maintaining scripted statuses would be easier.

I would prefer a branch to macros, but I definitely would not like to see pre-RE dropped, since lots of the servers still using it.

@MarkZD Is it planned to implement unique id's for stackable items? The most valuable items in most of the servers are the cards, so probably one wants to track them. Even though the community seems to like this feature, I kinda dislike incomplete features. IMHO the gain of this feature (even if fully implemented, including support for stackable items) does not worth the complexity penalty of the code. About the naming conventions, I think all of the proposed field name is ok, as long as it is clear from the documentation (of the corresponding config option) what it means. @Kisuka You should really learn to respect others. Your achievements do not make your superior and do not authorize you to write in this manner. Enumerating your contributions is not an excuse.

Well, HUGE +1 to have uniform names for variables.

Maybe it is just me, but I prefer to only do one specific refactoring with one commit. For example to turn on one warning in gcc and fix those warnings with the same commit may be a bit easier to track in the future than huge changesets. For the same reason it may be better to first enable several gcc warning and only set w4 warning level in visual studio after the warnings in gcc are fixed.

To real skill usage for NPCs, NPCs certainly need stats. However forcing the scripters to specify all stats for a skill feels a bit cumbersome for me. And do not forget, there are several possible data that skills might use beside stats. It involves crit, dodge, def, atk, matk, items etc. Some of them can not be manipulated by stats, such as the item part of def. Some skills are use certain item stats to calculate their formulas. I see this feature as the source of many troubles. Some skill may not work as expected this way, or cause crashes.

Has this stuff been merged into trunk? O.o IMO it was too early then.

Yeah, I think it would be better to alter the VS project files rather than the code.

Agreed. Cleanarea atcommand could have an optional area size. About the script command.. Yeah, as far as I know, we do not recommend to use atcommands in scripts, so maybe it is worth add these command too.

As far as I remember, the client can not handle arbitary number of character slots. At least old client couldn't, I do not know how the new clients behave. So I believe MAX_CHARS is there because of the client limitation. The chars_per_account is the settings users should use to limit the number of characters per account. Because modifying (especially increasing) MAX_CHARS may result in unintended behavior. But correct me if I'm wrong.

I do not like to add all the events to one file. It doesn't feel structured enough for me. At leas at my server I rather increase the size of the event queue, than forcing unstructured layout of scripts. Of course it is just my personal preference, probably others think differently.

Even though maintaining pre-re support involves additional work, I do not feel like throwing it away. I don't think it would have significant impact on dev's productivity.

I think it is not a valid point. IMO a better solution is, to pull the mesasage from SQL. I'm all for removing motd support and replacing it with a script. It is always better to get rid of redundant features. Futhermore scripts are much more flexible. The logging in is not a too frequent action, so I doubt it could become a performance bottleneck for any server. Anyways I think the default value of the event queue is way to low.

Some small notes on the patch to consider before it is commited: Naming like: pc_has_permission(sd,PC_PERM_DISABLE_STORE), is a bit confusing I think. So, has permission to not to have permission to open store, or something like that. I think it is better to avoid unnecessary negations. In my opinion permissions like: pickup, exp, store etc are more expressive than the disable_ prefixed counterparts. The default settings should almost always preserve the original behavior. For instance, if gm's were able to pick up items until now, the default for disable_pickup should be false in groups.conf. And finaly, if you increased the number of digits of an enum, append the additional 0's to the beginning of the other constants to match the style. Other than that, it looks ok for me, nice work Edit: just noticed, there are already some other disable_ prefixed permissions, however I still do not think, those are the right way to handle them. Alway better to keep it simple.

It wasn't done yet? O.o Even though all of us agreed.

What I used to use with my server was a script which detected if the server crashed and issues the following command: gdb -q -s $1 -c core -ex 'bt full' -ex 'quit' >> crashdump.log where $1 was the name of the server. Of course the script executed ulimit -c unlimited before it started the servers. I think it is pretty easy to implement some shell script for automatic dumps, the problem might be to make it platform independent, I don't know how big the differencies are across linux distributions for instance.

It seems to be ok to me, good idea.

Making the diff up to date is definitely is a good idea, but I think we should not merge it unless the community demands it.