Re: [crossfire] Moving server towards a modularized system?
tchize wrote: much about removing code removed I agree that removing/disabling code is a valuable feature. I'm just not sure that any of the methods either of us have talked about is really a good method. From my point of view, making it really easy/convenient for developers to disable code is less important than a method where it can be done on the server. And when I say 'on the server', I mean literally through a running crossfire server, and not by shell login. I'd see the most likely scenariou that a DM on a server that does not have shell access seeing that applying an item (or some other action) is causing the server to crash, and thus wants to disable that. IMO, having the server unlink .so files probably isn't a great solution (and in fact, may not always work, as the .so files may be installed with a uid different than what the server runs under). Also, disabling at an entire module level may not be desirable. In my example above, you may want to disable the applying of items, but still want ot be able to get descriptions of items, identify them, etc. Likewise, any disabling of functions should be persistent accross runs until re-enable. Disabling that apply function doesn't do much good if something else crashes the server and it is enable again. So what I started thinking was you could have a module control, with things like: operation type operation name operation value, eg: function scroll:apply disable (operation name would be module:function name, with potential wildcards, so you could do something like) function scroll: disable to disable all scroll code. This then allows other things like: variable scroll:max_level 25 To set module values to various things. this requires support of the module initialization code (checking to see if it shouldn't set the callback, change global variable, etc). If callbacks aren't used, the first line of various functions could be things like: if (!module.apply) return; That is marginally more complex than other methods we have talked about, but probably more flexible (I do especially like the clearer documentation of setting variables and how they effect things). I'd also think that once this glue code was written for one module, it could pretty easily be re-used for everything else. IMO, compiling/not compiling something isn't an issue - if something is so broken that it doesn't even compile, it should be fixed ASAP or be removed. Yes, assuming it's easily fixable (does not take 3 days of work). Well, if it takes 3 days of work to fix, then perhaps it should be removed, or disabled from the make system. After all, right now at least, the current built environment isn't especially graceful about continuing when it fails to compile a file (you can always do make -k) And I'd personally be concerned anytime I see something failing to compile. But as modules, it should at least be able to disable compilation of that one problematic file without affecting anything else. If you don't put the modules in plugins (at least what we could modularize from current server code) you would have two things - 1) code to manage hard linked modules (eg arrays of module callbacks to explores and so on) - 2) code to manage additionnal behaviour which could be requested by plugins (be it python, animator or another one) That mean during modularization process, at each place we consider splitting appart code in modules we have to handle separetly - main server module - plugin managment code This is twice the effort during the modularization process. I disagree it would be twice the effort. It _may_ be more work - it certainly wouldn't be quite as consistent. But if you pluginize a lot of code, I'd say there is more code that would need to be rewitten/changed than if it was modularized. This isn't enough for modules. Of course modules can be gathered .a and gathered a link time. But you also need to clearly separate them. Currently it has nothing of modularized. A piece of code in random map can call functions present in the socket, a piece of code in weather can call functions in maploader. Same for piece of code in protocol which makes call to maploader.c I don't see how you can avoid that. At the most basic level, almost any module of code is going need to talk to the socket (draw_info commands at most basic, but I can also see need for lots of update object commands). Now you can perhaps wrap some of those functions or use callbacks, but that really isn't changing anything. If we are talking about apply code again, the module will need to know about the NDI_ values as well as perhaps the UPD_ values. Now the plugin could have its own private file, but then somewhere in that plugin logic, it has to convert those values (PG_BLUE to NDI_BLUE or whatever). And unfortunately, I'm not really sure how many of the current top level include files have dependencies
Re: [crossfire] Moving server towards a modularized system?
We want to cross module boundries and there is no reason for us to want 3rd party module additions (unless one is pro-proprietary). Modules would do 2 things: disallow use of code across module boundries (as they aren't loaded yet), let proproprietary addons be created and work over more then 1 release cycle. Both are bad. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Yes, spagetti code, if that's what you wish to call it. Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). Modules would disallow this (bad) as they are not loaded untill they are called. Call it what you will but this is why subroutienes were invented (subroutines, in assembly, are basically gotos... :) ) so you didn't have to paste the same code everywhere. Oh and I just got a yamaha midi guitar (EZ-AG) :) (I now have a midi keyboard and a midi guitar :D, the keyboard is recognised by linux through USB and rosebud4, I still have yet to get a midi-cable-usb adapter which the geeetar needs). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
On 1/26/06, Anton Oussik [EMAIL PROTECTED] wrote: Is there anything that can be done to improve movement on laggy connections? Could the server send the client a matrix of what tiles on the map can be moved to, and send updates of that as they change for example? Any better ideas? One thing that might work for this, is something I have been idling toying with concerning movement. I was looking a few weeks ago at adding a 'goto' command so that the player could send a command goto xy (relative to the player) and then, as long as they had no further commands sent, they would go towards that point. (in terms of controls, this would map to clicking on the map view somewhere). - the stupid implementation of this is quite straightforward, getting the routing to work properly is harder. In any case if that became the defacto standard way of moving (as it is in most graphical RPGs), then it would be possible to figure out what route the player would take, and send the moves they would make to the other players in the room early. - this would still lead to the ocassional de-sync issue (when they change direction, or something moves in the way) but it would be a noticable improvement over what is currently there. (the extension to that would be to have an attackto command (or a flag to goto) so that monsters could be targeted to get the player to follow them and attack when they are in range. - probably such advance telling of commands should only occur if the ping time is bigger than the tick time though. In general though, if your ping time is over a second, you need a better internet connection, most games are difficult to play when you are that laggy. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
Brendan Lally wrote: On 1/26/06, Anton Oussik [EMAIL PROTECTED] wrote: Is there anything that can be done to improve movement on laggy connections? Could the server send the client a matrix of what tiles on the map can be moved to, and send updates of that as they change for example? Any better ideas? I'm not sure that helps out. What it gains is that the client can 'move' the player to the space they are attempting to go to so that client is slightly more up to date. However, you will get syncrhonization issues - if your lag is 500 ms, any update on that array of spaces is still 4 ticks out of date. So you can certainly get the case where the client thinks it can move to some space, but someone else has already moved there, and thus what the client displays is not just out of date, but erroneous. One thing that might work for this, is something I have been idling toying with concerning movement. I was looking a few weeks ago at adding a 'goto' command so that the player could send a command goto xy (relative to the player) and then, as long as they had no further commands sent, they would go towards that point. (in terms of controls, this would map to clicking on the map view somewhere). - the stupid implementation of this is quite straightforward, getting the routing to work properly is harder. I'd think the straightforward approach would be a good first step. Routing is more difficult, but there is already code that monsters use for this type of thing. IF anything, using that same code for players would just be a good thing - it would probably mean that code would become better as players would see actual bad routing issues. The slightly more complicated part is that ideally, you'd want the server to send the client the proposed route (so the client could display it in some format, so if it is completely bogus, the player can interrupt it and re-route manually. One consideration is the case of alternate routes. One tricky part also, relative to players using that code, is you don't want the player to cheat too much. IF the player is in a maze, they shouldn't be able to click some spaces away and the server now routes them there even though as a player they had no clue. In any case if that became the defacto standard way of moving (as it is in most graphical RPGs), then it would be possible to figure out what route the player would take, and send the moves they would make to the other players in the room early. - this would still lead to the ocassional de-sync issue (when they change direction, or something moves in the way) but it would be a noticable improvement over what is currently there. (the extension to that would be to have an attackto command (or a flag to goto) so that monsters could be targeted to get the player to follow them and attack when they are in range. - probably such advance telling of commands should only occur if the ping time is bigger than the tick time though. I think goto would be very good - simply if when loaded down and heading to a shop that is going to take moment, being able to click it and have your character end up there is certainly more convenient than having to hit the run in that direction. In general though, if your ping time is over a second, you need a better internet connection, most games are difficult to play when you are that laggy. Yes, but here are some other random thoughts: 1) Player movement is perhaps to fast - with most all players moving about 1 space/tick, this obviously results in keeping in sync harder. 2) A 'follow x' command could be added such that you follow player x. Maybe just allow it in parties, with commands like 'lead party' and 'follow party'. Everyone who did 'follow' follows the 'lead'er. The leader would automatically slow down as needed so as not to get too far ahead. 3) Currently, the server processes all the objects/players, sleeps for 120 ms, then does that again. Lag could be reduced by some amount (average 60 ms) if we process data from players immediately when it arrives. However, this only helps out in cases where the player is idle (basically has an action to use). If you're running, it won't make a difference - in that case, the code will look for commands from the socket before it has the players character do anything, so there is the entire 120ms for that to arrive. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
