xazax

Well, I think we should add a VERY! primitive plugin system. It could work like this: the plugin system would be able to load plugins (so or dll based on platform), and that is. We would not add any callback or such. This way one could provide a binary distributed plugin to protect her source code, and provide some headers and a patch file to the source code to add the neccessary calls to the code. We would avoid messy callbacks, still provide users with a way to distribute proprietary content.

Agreed.

Well, you can't be 100% sure, but you can code your stuff that way, it is the least likely ther will be a conflict. For example, add as much new code as possible to separate files in functions, and call those functions from other files. Make your customized code less fragmented etc.

And you only need to restart the login server.

Let's also consider how much compatiblity do we want to maintain with eA. The more config format we change, the more work we force to the users who wants to migrate to rA.

As far as I know, saving logs to TXT is still supported.

Maybe what you want is motd. There is a conf for that.

3577

Yeah but the point of this code is that, you don't even send the packet of displaying that npc to the client. However what you want is, still send the packet, if the reciever is a GM. In that part of code, you don't know yet, who will be the reciever, so it would be impossible to alter the conditions. All you can do is, either revert that patch, and give your GM's maya purple card, or move all the checks to clif_send, where you have all the necessarry information.

I don't know if there is a method to make tables versioned, but a primitive way to implement something like that is: have a version table with a version field, one integer. On each database change, the upgrade file bump the version, and of course we also bump te version in main.sql, and in the server there could be a #define that also needs to be bumped, and we can check if those versions are the same. Probably there are some better methods, I'm not experienced with SQL.

If we restructure our database layout we should also make the tables versioned. And the server would throw a warning if there is an outdated table ( somebody forgot to apply the upgrade sql files ). Anyways I think we can purge the really old SQL upgrade files.

To the digest!

We can use our in memory databases. Hopefully we won't implement any leak. I vote for yes.

I think that is not possible to implement it efficiently, the only way is some hack in clif_send but I do not recommend you to edit that code unless you know what you are doing,

Hi! There are several considerations you have to make: * All of the participants of the trade needs to have the trade card? * Are there specific trade cards for specific items, or only one trade card that makes it possible to trade other items? Anyways if only one of the participants do need to have a trade card, you can implement similar functionality without any source edit. An npc can add a player to a group, which have the permission to trade those items, while the normal group of playerd don't.

3401

When I was running a server, our policy was: we never even tried to trace stolen stuff, because it is the player's mistake if it was stolen. Every single time it turned out, the player gave out his or her password. However we developed our own CP, had our own packet encryption mechanism, and only stored salted password hashes in our database, so even GMs could not tell a player his or her password. I admit that, the defaults of eA/rA is very insecure, so players usually can say that, they did not give away ( even if most of the time they did ), so indeed it is an useful feature. If the implementation is not messy, I agree with adding it.

My problem is with stackable items, because if we add uids, users will definitely want them to work with cards. And to proper tracking each card should have it's own uid in the stack.

For what reason do we need uids? To track down item duplication bugs? In that case, as far as I know, cards are stackable, still those are the most valuable items in the game. Is there any dupe report at all? If no, and server owners want this feature to track corrupt GMs and stolen items from (hijacked) accounts, I think it is their responsibility to get good staff, and secure his/her control panel. I think, it is not worth bothering implementing uids, because with the current desing it would be very time consuming to implement it properly, and with a secure CP and trusted GM staff it has no use.

3368

Feel free to work on it, and as long as it is tested against kRO, I will welcome any change.

3349

Yeah, as far as I can see, it would definitely involve giving the database some kind of version. After that, there are 2 options: * Hardcoded updates on startup * Execute formatted .sql files from a folder on startup. One must be able to disable this feature though, because it is a security hole, and you need to set less strict premissions to your server's mysql user. ( however I guess most user do not bother much with permission anyways )

Oh, I see your point now

I think it is possible to create an optional step: importing the whole item_db.txt or item_db.sql to sql at startup. But I don't really see the point in of this feature. What would be more useful, and still possible to implement is: to create a post commit hook, that monitors for db changes, and if item_db or mob_db changes, do automatic conversion, and a commit. This way the sql files would be 100% percent up to date all time.