[crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
[EMAIL PROTECTED] wrote: Module Name: crossfire Committed By: qal21 Date: Wed Aug 17 18:38:35 UTC 2005 Modified Files: crossfire/include: sproto.h crossfire/server: build_map.c Log Message: Fix bugs, and allow buttons and pedestals to be built underneath gates. [...] Index: crossfire/include/sproto.h diff -c crossfire/include/sproto.h:1.133 crossfire/include/sproto.h:1.134 *** crossfire/include/sproto.h:1.133 Fri Aug 12 16:16:31 2005 --- crossfire/include/sproto.hWed Aug 17 11:38:34 2005 *** *** 70,78 /* ban.c */ int checkbanned(const char *login, const char *host); /* build_map.c */ void remove_marking_runes(struct mapdef *map, short x, short y); int find_unused_connected_value(struct mapdef *map); ! int find_or_create_connection_for_map(object *pl, short x, short y); object *get_wall(struct mapdef *map, int x, int y); void fix_walls(struct mapdef *map, int x, int y); void apply_builder_floor(object *pl, object *material, short x, short y); --- 70,81 /* ban.c */ int checkbanned(const char *login, const char *host); /* build_map.c */ + object* get_connection_rune( object* pl, short x, short y ); + object* get_msg_book( object* pl, short x, short y ); + int adjust_sign_msg( object* pl, short x, short y, object* tmp ); void remove_marking_runes(struct mapdef *map, short x, short y); int find_unused_connected_value(struct mapdef *map); ! int find_or_create_connection_for_map(object* pl, short x, short y, object* rune); object *get_wall(struct mapdef *map, int x, int y); void fix_walls(struct mapdef *map, int x, int y); void apply_builder_floor(object *pl, object *material, short x, short y); This patch makes the functions get_connection_rune(), get_msg_book(), and adjust_sign_msg() global by removing the static modifier. What was the reason for this change? (Grepping through the source did show that these functions are both defined and called from build_map.c only.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
Quoting Andreas Kirschbaum [EMAIL PROTECTED]: This patch makes the functions get_connection_rune(), get_msg_book(), and adjust_sign_msg() global by removing the static modifier. What was the reason for this change? (Grepping through the source did show that these functions are both defined and called from build_map.c only.) I did that mainly to follow the convention of the rest of the function. In build_map.c there are many other functions that could have very well been defined as static but weren't, so I changed these functions which I recently added to match. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Map cache
This is an idea I had for a while now, but never had time to implement. If someone has some spare time and wants something to code something for CF they can try this. When the server comes across maps containing large amounts of items it takes a long time to load. While it is loading the whole server freezes for other players, and on very large maps (like the scorn sale shop or some apartments) this can take in excess of 10 seconds on metalforge. A solution I propose is to pre-load large maps and keep them around in memory in case they are needed. Whilst this option would improve the performance of the server like metalforge, it would cause servers with small physical memory size to start swapping the cached maps, and it would then not be beneficial. Therefore the map caching should be optional and off by default if implemented. Casper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Swig Libraries Proposal
Recently in another thread, there was some discussion on making a new editor to deal with some of the issues in both crossedit and the current java editor. I suggested possibly using python/pygtk to do it. However I also believe using the existing C code in common/ would be very helpful. To aid this type of development, I propose that the server code tree should include the option of building libraries for use with scripting languages by using Swig (http://www.swig.org/). As Swig can be used with many languages including python and perl, it could also make it very easy to make small scripts to search archtypes and maps and such, so it could be useful even if it doesn't lead to a new editor. Also note, this is not at least at first, intended to replace the python plugin for the server (though that might possibly be something to consider for the futute) I am very sure I should be able to set up the input files for Swig that define how the bindings should operate, however I'm thinking I may need help for integrating it into the build system. These pages look helpful: http://www.signal6.com/cgi-bin/wiki.pl?SwigFaqAutotoolsConfiguration http://www.swig.org/Doc1.3/Introduction.html#Introduction_build_system however I have no experience with dealing with autoconf and makefiles and will probably need some assistance on that. Anybody have any suggestions on dealing with the makefiles, and comments on the proposal in general? Thanks, Alex Schultz P.S. Please keep discussion specifically on making a new editor in the other thead and keep this thead to discussion on setting up Swig bindings for common/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
On 8/25/05, Anton Oussik [EMAIL PROTECTED] wrote: A solution I propose is to pre-load large maps and keep them around in memory in case they are needed. Depends what you mean by pre-load. It might be possible to have the server check each map when it loads, and then load all maps on exits leading of from that map in an independent thread. Of course this requires that the map loading be thread-safe, and I'm fairly sure it isn't. An alternitive (which might be easier) would be to have a seperate map loading thread at all times, and when a player enters an exit, not change their map to the new one, but instead place them in 'limbo' if the map isn't loaded (a unique map which is 1x1 and has no objects. Then the player object would need to check every tick to see if their map is ready. This still poses some problems with what to do with the command queue, if a player has hit multiple arrow keys, should they be discarded? The other approach is to simply say that all the world maps put together are fairly small, compared to the amount of memory many servers have these days (and this is increasingly more and more true), so it would be possible to just load all maps at start up, and keep them loaded until they reset. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
