sketchyphoenix

LChar-Server can now save registries to a sqlite or mysql database. It also has user authorization. Just need to plug this into rA so I can use the hashing functions for the inter-server user/pw. LLogin-Server being worked on.

In before mac bans.

So what's been holding me up for so long was 1) i got a new job and 2) I was torn on how to finish off variable storage. It came down to this. I needed to send registries from map to char or login for saving, but I had 2 ways to do it. I could either do it with Lua or do it using rA's inter-server stuff. Tried the latter first. Then I realized that doing it with inter-server functions is really hacky (take variables from Lua -> conver to struct -> send to char/login -> char/login reconstructs the table, send it back to Lua then save it. So I decided to just have char/login server have its own Lua server just to handle that since I was already giving char/login their own lua states for sqlite support. Now I'm in the process of writing that.

Last I remember, the client doesn't have an embedded web browser so... and if it did, you would need a client hack most likely via injection.

I'd like for guild skills to not lag a server during WoE. One day a sqlite implementation for local testing would be nice since that's pretty much the logical conclusion for /rAsql Not realistic but the skill engine would be better off remade into something more modular so it's much easier to make skills.

Still alive, but having to plan out the rest of my short term work so I don't get bogged down by too much. I'm taking notes on what I need to remove to get the old script engine out, since technically it's still in but disabled since I decided at the time that trying to remove it and fixing whatever that depended on it in the source took more time than I would've liked to put in it. Also I plan on having an update next week.

I'm positive it's something with the custom script not scripted correctly but obody can help you without posting it.

Not making any sense.

So you're saying you are against SQL DBs because whatever front-end you are using is garbage and not anything to do with SQL itself.

Well, to clarify a few things. rA isn't just 3rd jobs and skills. It's great and all that it's starting to support them, but there's more to the emulator than that, even if the code is transparent to most of the users. The plugin system needs work. No mistaking that. Debating over open/closed source isn't the objective of the thread. If people want to share their code, they can post a source mod. Otherwise, they can code a plugin. Also, @Epoque, If you want to take 10 minutes off my hands to code some functions to load shared objects, I won't object

Pretty much, we want to avoid the mess of having callbacks everywhere. There would be two logical methods of implementing plug-ins which should both be supported: Default callbacks. Implemented in areas, like you mentioned, at-commands, script-commands which call default "events" or methods within a plug-in upon initialisation, usage and obviously shutdown/clean. An "event table" which stores string or other integer values as a sort of map, which the plug-in will load into memory upon the library being loaded to which the plug-in creator can then create calls to these methods by writing single lines of code within the source (IE: plugins_call_event("event_name", [parameters as va_arg?])) By providing an "event table", it means people could create closed-source plug-ins, but obviously one critical importance is allowing cross-platform compatibility which will need addressing in the plug-in system. This is a small-scale operation so callbacks are the preferred method. Decided rewriting the system would be a better option and the core of it works for windows, just need to bring in the nix support and i can start testing.

Then we'll just make some. Starting with gm commands for now. Then i looked in source We're late.

The burden of presentation is on the shoulders of the administrator that runs his/her server. While we do provide the base (the emulator, the vanilla ragnarok or as close to it as we can get ), it's not our responsibility to make other people's servers unique. We can certainly make the software easier to customize, but that's the server admin's responsibility to make fun and interesting custom content. This is why I posted earlier that I am not above having a plugin framework for rAthena. It would allow users to distribute modifications much easier than what's in place now. It would be a lot easier to drop a few .dll/.so files in a folder and they just work as opposed to having to build a new binary for even the smallest changes and have to do all kinds of user support because somebody doesn't know what a compiler is, or they thought you just save the .c files and it just works automatically or they didn't add it correctly and now they have compile errors.

Adding all of those source modifications just makes for more unnecessary upkeep. Though I'm not above the idea that rAthena could use a good plugin framework for its most customized features.

What I plan on doing with this there's a lot more going on than Lua's string library!

sup?

A conversion script is the most feasible idea. The problem is it wouldn't be very well written by Lua standards. In other news, I got rid of LuaSQL today. I was writing the db queries to handle variable storage and found that the bindings weren't able to prepare statements, which had me looking for one that could - and that was LuaDBI.

Variable storage is almost done. I just need to write the queries.