Re: [crossfire] scripts
Alex Schultz wrote: Such running scripts from text in memory is very possible indeed :) In fact, we could (and should IMHO) go one step further: Run it from the bytecodes in memory. The python code already has faculties for caching the bytecode of python scripts in memory (caches up to 16 scripts as bytecode in memory) and this increases speed of running the same script over and over VERY dramatically (code for this derived from daimonin's changes in the python plugin before it moved to lua). So, why store text in memory as such to run, when one could store the bytecode which would be much much faster and use less memory :) Right - I was thinking that it may be possible to store some machine format. As someone said, the one disadvantage of these collected scripts is that you can't change them on the fly. However, I'd consider that a pretty minor issue - if you're developing a script, you could certainly store it is a plain file so you can run it over and over again until it works, and then move it to the arch where it gets collected. As far as the idea of collect copying the scripts over to the maps script idea, I think this is a bad idea for many reasons: - In a sense, it pollutes the maps directory as far as SVN goes - you now have a bunch of files under maps which are not part of SVN. As things go right now, you can use a svn checkout for your maps area, and it will remain pure. - The abilities/ownership of the collect process gets many. It probably isn't that uncommon that one uid is used to build the source and run collect, and another is actually used for the make install. In this model, the collection process would be unable to copy the scripts directly over into the maps area - instead, it would have to copy them to a temporary area, (lib/scripts/...), and then the install copies those over. But if we're going to do that, it probably makes sense to just copy those over into some non map area of the install directory (share/scripts/...) or something - This may make packaging (rpms) more of a problem - this is especially true if a map script becomes an arch script or vice versa - now you have conflicting files in the RPMs. If they are in completely separate directories, no issue. As far as pathnames, to me, the simplest thing is to have a basic pathname and there just be a search order - server looks first in maps/scripts/..., then in share/scripts/..., etc. That should be very easy to do - the only issue is if there are two scripts of the same name. Alex Schultz ___ 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
Re: [crossfire] Patches on tracker
Lalo Martins wrote: On Mon, 07 May 2007 22:52:51 +0200, Nicolas Weeger wrote: Le samedi 05 mai 2007 23:10, Mark Wedel a écrit : The fact that the maps are in the 'share' directory means that write access to that area is not a requirement. Lack of write access could be for any number of reasons - permissions issues, or for some sites, something like that could be put on a read-only filesystem. As a side-note, Python can write in the maps's python/ directories, since Python compiles the scripts to .pyc files. Righto, but if it's unable to due to permissions, then nothing will break. And as I think about this more, for almost anyone that is using precompiled binaries (rpms, debs, whatever), there is a good chance that the process/scripts will not be able to write into the maps directory. This because in most all cases, the root user would install the appropriate package, and so would have root ownership, and no write permissions. We strongly suggest that you do not run the server as root, but some other uid, and as such, it would not be able to write to this area. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Background music
Nicolas Weeger wrote: Hello. I just added a 'background_music' field to maps. 'sound' setup has been changed. If client sends '2' as value (instead of 1), support for background music is enabled. When player enters a map, background music name is sent, or 'NONE' if nothing is defined for the map. I almost wonder if it is worthwhile for the server to know/care about the client sound settings - it keeps the server simpler if it doesn't. The only reason it makes any sense is some bandwidth savings, but the savings for this, especially for the backgrounds ones on the map, is pretty trivial. There is still no client-side support, though. Not sure of the library to use for that (SDL sound, maybe?) A fair amount depends on the format we use for the sound files. For the current unix client, I think the current sound program could be used pretty easily with a few minor modifications (basically, it just keeps copying in the sound data to the sound card). background_music value is a free string, so it's up to us to decide what to use. It could be 'style:xxx' to specify a generic style, the client choosing one randomly from its curpus. And 'specific:xxx' to signify a particular background one, for special maps. That sounds good. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Background music
Nicolas Weeger wrote: Replying to various threads in the same message :) Ok, so what about: server merely sends item's name, client-type, and event type? For instance, 'goblin monster type death' or 'dragon monster type move' or 'icestorm spell type move'. Then client handles those values however it wants - play a sound, play a random sound, don't play anything, blink the pic somewhere, The type can also be used as a fallback method - no 'High Goblin' sound, play regular monster sound. That mostly sounds good. However, I still think some standards are needed. What is put in monster type? Remember, monsters don't actually have unique type values - do you mean archetype name? If so, that makes sense. OTOH, it could also mean that there is a huge number of sound combinations - think of the number of different monsters we have in crossfire just in the archetypes - probably more than 100. I'd think a fair number of those may have some common aspects (goblins, orcs, and ogres could/should share some common sounds). While the ideal case would be to have unique sounds for every monsters, I don't think there is any way we could come up with 1000 different sounds - we need to be practical and keep that in mind. I also think that it will be a requirement to be able to set what sound in the object - going by monster name really isn't good. The most obvious case is the 'boss' monsters, which tend to be uniquely named - you really don't want the client to have to know about the sounds for 50 boss monsters - you want to be able to set up the boss monster to use some particular sound (this may be the sound that archetype normally uses, could be the sound a different archetype uses, or could be a unique sound for bosses). You also want to be able to specify what objects do and do not have sounds - I don't think we want implicit sounds (this monster is moving, therefor play a sound), unless something is set for that monster to say we should play sounds. Another example here: Having orcs make a noise whenever they move would be really annoying (annoying enough that most people would probably disable it through whatever way). However, it may be desirable for the boss orcs to make noise. I'd personally suggest that various sound_... fields be used that describe what to play. Once again, these could be general (a directory of sounds files) or a specific sound file. These can then get updated as new sounds show up (I now have a specific sound for a troll moving, so I don't need to use the ogre movement sound, etc) - simple archetype change, and things are good to go. It should probably also be discussed what type of events are needed. Remember, it should be more than just monsters - items the player uses also need events (firing a bow, shooting a wand), spells need events, etc. And for all this to work, these event names need to be somewhat standardized - while it could be nice to have arbitary sound_event strings, like sound_burned_up, there still needs to be logic on the server of when to play sounds. A quick list IMO: sound_move (monster moves) sound_attack (monster attacks - should also be on weapons the player uses) sound_apply (sound when applying something, like a clock) sound_fire (sound when firing something, like a bow) sound_destroyed (sound to play when something is destroyed, like burned up) sound_active (sound for objects active, like a gate) In addition, there probably needs to be a secondary flag which states if that sound is always made or done once. For example, for a gate, you probably want to run just one cycle, but for something like a fountain, should be continuous. Concerning sound files themselves, we should handle them like pics: client has the 'standard' set, and can request from server specific sounds if needed. Will need to check various issues (max packet size, ...) I disagree with that - it adds a fair amount of complexity and isn't really the right direction to go in. In the past, it has even been discussed that the server actually shouldn't server images, but that get offloaded to some other service. Main issue being bandwidth (server may have limited amount). But images are somewhat special - if there is a new object and you run accross it but don't have an image, there really isn't anything very good the client can do. But sounds are really purely optional - I doubt anyone would die because their client is missing a sound - the fact that a lot of people probably don't even play with sound at all basically says that sound shouldn't be a required part of the game (and any map that makes it so should probably state that fact, just like they do for multi player). Also, I'd expect sounds to change a lot less. So putting them on an ftp server someplace works just fine. And that saves a bunch of complexity on both the client and server. If as I suggested,
Re: [crossfire] Obsolete flags
Nicolas Weeger wrote: Hello. There are quite many obsolete things in loader.l, so I'd like to remove'em, but not sure on some things. Also it'll require some map/arch cleaning. First, those flags: * has_ready_rod * has_ready_horn * has_ready_wand mapped to FLAG_READY_RANGE From what i read from the monster handling code, this ready_range flag is actually not required, it'll be calculated again. So IMO those three flags should be removed totally. Probably true - I can't remember now, but certainly at one point, they were used internally - I don't know if they were ever saved out to any maps. * can_use_wand mapped to FLAG_USE_RANGE many archetypes use this flag, many in maps... So should be cleaned like crazy :) At the same time, are there any other can_use_... flags out that that have been replaced/supserseded? * immune * protected * vulnerable those kind of conflict with the resist_ values, they'll override or mess with them. Unfortunately many (~400) maps still use those, so updating won't be easy. yes - like most things in the loader, it supported using these values along with the new, but having both set in the same object was never really considered supported. * armour, which should be resist_physical, doesn't seem to be used much. Any volunteers for helping to clean ? :) Can't most of this be automated with scripts? For flags that just go away, it'd seem to be a simple 'remove this line' type of logic - not hard at all. The immune/protected/vulnerable may be a little trickier, because if an object is using those plus the resist values, just putting in the corresponding values based on the immune may conflict with those other ones. However, I'd think that would be something pretty easy to catch - only in those cases where that is happening would manual interaction be needed - otherwise, this could be automated. It'd also seem to be that baseline scripts that do this conversion would be useful - it would be a good starting point so if down the road, something else is obsoleted, change the script a little bit and you are good to go. I think there may already be some scripts out there that do this sort of thing. I know I wrote some for the map updates (to update exits whatnot). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Discrete damage type
Nicolas Weeger wrote: Hello. I just committed to SVN trunk changes that enable weapons to have discrete damage for each attack type. It works quite simply: * new object fields 'damage_attacktype', so 'damage_fire' and so, like the 'dam' field in living structure * if at least one field is set, 'dam' is ignored for attack, and the discrete values are used instead Random question to everyone at a whole - should the old 'dam' field go away at some point, that is to say, everything should use the discrete damage? This would require map archetype updates, but that could all be automated - if attacktype is set for say AT_FIRE and AT_PHYSICAL, and dam is 10, then script would just remove that and add damage_fire 10 and damage_physical 10. It also means that attacktype basically goes away - instead, that information is conveyed in the discrete damage fields. Which leads to an interesting question right now: If I set up the discrete damage values for an item, but don't update the attacktype to include those attacks, what happens? I can think of 1 of 2 things: 1) Attacktype is ignored - if the discrete damage is set, that is used no matter what (meaning that attacktype basically could go away if everything was updated) 2) The discrete damage isn't used, since the attacktype isn't set. If #2, should probably be documented someplace. Implementation details, issues to check/fix: * the discrete damage are stored in a 'discrete_damage' array allocated only if one value is set in archetype definition Are things smart enough to handle the case where I modify an archetype on the map to included a discrete damage type? For example, suppose I take the standard longsword, which just has a standard dam value, but want to make a specialized weapon - something that still does mostly physical, but a little bit of fire, so I use the discrete damage values to do that. Will that work? IMO, it should, because that is a pretty likely scenario, and from a map maker perspective, I shouldn't have to know the internals of how things work - I should be able to set up discrete damage types and just have it work. * i only changed hit_player_attacktype to handle this discrete damage. It is used by many things, including spells attacks, i think. * i know some parts (specially spell attacks) alter dam based on casting spell level. Thus that code should be changed to modify discrete_damage instead - shouldn't be too hard Don't know if done, but I'd also suggest that things like examine object should dump that information. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Polymorph spell
Nicolas Weeger wrote: Hello. I'm wondering whether the polymorph spell couldn't be reactivated. It's been desactivated for eons, but IMO it could be a fun one - with some limits. Maybe create some scrolls, and have them at end of hard quests only? Or the code should simply be removed if not used, but IMO that'd be a waste :) It certainly can be re-activated. The main concerns I recall: 1) You could polymorph tough boss monsters into easy to kill monsters. 2) Related to items, you could get better items and/or make money. IMO, #2 isn't that much an issue, as long as really great artifact items can't be created. Money is easy enough to come by, that so long as getting polymorph objects mean you are high level, the money gain/less isn't likely to be an issue. #1 could be an issue, but fixed by some monsters not being polymorphable. I also recall that polymorph only worked for single space monsters, so already had some limits. The spell was always in bolt format - I suppose this can be done with scrolls, but aiming scrolls always seemed a little harder than with wands. But wands with limited number of charges makes sense. Since wands have levels, one thought is that it can not affect a monster of higher level than the wand - that makes things interesting then - a level 100 polymorph wand could become a pretty good 'kill one creature' type of weapon, but if sufficiently hard to get, not a big deal there. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Release schedule/notes
[EMAIL PROTECTED] wrote: Other thoughts: I'd say there is nothing prevent some micro releases of some components between now and then, if a change warrants it. For example, map and archetype changes are quite quick to do and contain perhaps some of the more noticable changes to the player, so doing a micro release of those between now and then may make sense. Likewise critical bug fixes in either the server of client would warrant a micro release (1.10.1). To me, it seems more sane to reserve micro releases solely to bug fixes of particular note (affects gameplay significantly or affects security). Generic quick changes seem like they wouldn't be worth doing micro releases for really. I generally agree. OTOH, if someone wants to do a release of some component to fix some aspects, I don't think there is a big reason to stop them OTOH, scheduling has to be done properly - it doesn't make sense to do a micro release 2 days before the next minor release. Main trunk releases: The server is going under some major changes - I'm not sure it makes sense to do releases until that is sorted out. Just from my experience with the 1.10.0 release, it would seem that someone could otherwise be spending a lot of time getting it so the release aspect of it works, only to have a lot of that work go away as files and other paths may change. Agreed. Also note, in terms of finishing major changes first, though the current going code changes are among them, we should also think about gameplay changes, think about what frusturates players, and think about how to change the game mechanics to improve that. Those things are even more important IMHO to warrenting a 2.0 release and we should remember that code restructuring while important, is largely so the gameplay changes and features are easier to deal with. I suggest in terms of gameplay changes/improvements, before we look at things like adding a character creation menu, we should look at things like movement/attack speed which are easier to change the algorithm for but require greater testing and thought IMHO. (Ok, done drifting off from Mark's topic :)) Ordering of what to work on is always tricky. Especially given the volunteer nature. What I'd put near the top: - things which hold dependencies (I can't do Y until X is finished, so X should be done sooner, not later - Changes that result in incompatibilities (say different save file format), or game play changes that would be hard to fix with script, making it so that the only fair thing to do is start with all new characters (changing how exp is gained, enchanting objects, etc, could fall into this case, with the older characters have a perceived benefit that the new characters can't get) - Game changes related to balance, as the process of changing those could take quite a while (this character too weak at low levels, but too powerful at high, etc) while changes to gameplay themselves should be done sooner, not later, it depends on the change. In the example of speed/attack speed - in some sense, that could be done at any time (even to the 1.x release), the main issue being that it could be confusing/misleading to players because they attacked at speed X, and now attack at speed X/2 for example, making things more difficult. This sort of falls into the incompatibilies realm, but to a lesser extent. IT probably also falls into the game game changes related to balance - if player speed is changed, that changes the balance all around - you couldn't do it late in the process. And while some cosmetic changes may not make sense, in other cases, it may make sense rather than doing two versions of the code. For example, if we change the way characters are created (like you get so many stat points), and even extend it to things like choosing some skills, it doesn't make a lot of sense to do it once with draw infos, replies, message states in the server, and then later, write up the nice GUI for it - in a sense, it is less effort to just do that gui while those other changes are going on so that code isn't written that is then thrown away. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Pickup mode
Nicolas Weeger wrote: Hello. I'd like to remove old pickup mode code, and either remove totally support for it, or merge it with new pickup. My thought is that perhaps it should go away, but there be some sort of compatibility mode, such that if you select some value with old pickup mode, it means it is effectively this with new pickup. I know that I'm still in the habit of going to 'pickup 4' to pick up everything in a dungeon, and then 'pickup 0' when I'm done (4=everything, 0=nothing). I don't really care how that works internally, but I'd be nice to keep those old (simple) pickup modes for those of us that do use the command to switch pickup modes. I would think that those could be converted to new pickup modes in most cases, or even pretty close cases (I wouldn't care if pickup 4 actually did skip cursed or unpaid objects for example). Likewise, the value density modes could perhaps get rounded/adjusted to the nearest value in new pickup mode, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Maps passwords/phrases text
Nicolas Weeger wrote: Hello. The real solution here is to use keywords instead of the actual word, like $SCORN_PASSWORD. So you'd have something like: @match $SCORN_PASSWORD you look ok, ... Agreed there, shouldn't be too hard. Also makes everything way more souple, not linked to maps. Of course, there should be appropriate warnings when a variable isn't found in the substitution file. True - as long as some special character is used, that is easy enough to do. $ may be just as valid as anything. Method 2: snip I like that method. IMO, that could even be done through a small plugin - intercept the EVENT_MAPLOAD and do the substitution. I should look at the plugins further. But right now, there is a 'check object' type function in loader.l that is called each time after the object is loaded. Its original purpose was to catch things that changed in various versions. Adding the substitution there would be easier, and perhaps faster than a plugin, simply because that substitution would be done right after the object is loaded, so more likely to have stuff in local cpu cache, vs having to iterate through all the objects in the map later. Plus, you'd have a lot of cases where op-msg is null, and checking for that in that function would be very fast - while also fast in a plugin, you'd still get the overhead of having to iterate through the map objects, so you're spending some extra just going through the object points, going through inventories, etc. But as I think further, if some defined character, like $ is used to denote these, then I think the actual msg parsing code in the lex loader could be used to find these, perhaps make it even faster (could get the variable name from the lex parser, do a simple btree type search to find what it subsitutes to, and copy that in the temp buffer right now - better than doing it later and having to make a new buffer because the size is going to be different, and copy/substitute at that point). Method 3: snip This method has one drawback, in that it adds some overhead to every NPC talk / magic ear/mouth. Note that this is similar to what I did for the quest management stuff, btw (change the message dynamically). The related problem with that is that it also means a lot more code needs updating - anything that references the op-msg probably needs to be updated, where as with method #2, none of the other code has to be touched - everything is handled at load time. I like both methods #2 and #3, because they give DM some more power over the world. IMO we should move to that kind of system for game-related options - let DMs customize. Arguably, it's the role of the server administrator, but he doesn't always have the time for everything, and currently many options require a server restart. For instance, if we ever implement shop opening hours, that'd be something I'd let DMs tweak ingame directly :) I'd almost say there should be different access levels: 0) Normal player, can't do anything special. 1) Extended access granted through in game mechanisms (finishing quests, etc) which provide access to a limited set of changes (lords of scorn changing scorn password, or maybe changing business hours, or perhaps even shutting down shops temporarily). This adds some interest in that by doing some in-game stuff, you can have more noticable effects on the game world. 2) Wiz access granted by server admin. These people would have access to everything/every region of #1 access (change passwords anywhere) plus some extended access (summon players, item creation, etc). There may be some wiz commands not available, like shutdown, which these people generally shouldn't have. 3) Admin access, which can do anything provided through the crossfire interface (all dm commands) . ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Release schedule: was maps/tags/1.10/
Kevin R. Bulgrien wrote: I also think that less than every 3 months is too long a gap - just looking at the client, there were lots of things changed since the last release, such that if there were 3 releases in that time period, each would still have enough changes to be compelling. More frequent releases than quarterly for stable releases seems questionable, and would propose a tri-annual or bi-annual stable release to better line up with major distribution release schedules. Ok. I think bi-annual may be too infrequent, by every 3-4 months is probably reasonable. As far as getting more testers running the code that doing monthly or bi-monthly build releases is a good idea (all the way to packaging so that the release process itself can be tested). I only see this possible if the release process is documented and scripted as much as possible. At work, I do releases where I use a document and a special make file that does all the tasks between events that need operator intervention... using the Makefile as a simple library of things that need to be done... a la `make zip`. I'm documenting the process as I go along. What I have so far is at: http://wiki.metalforge.net/doku.php/crossfire_release_guide (I have yet to the server release) Some things could perhaps be scripted more than they are done now. For example, I could certainly see a top level script along the lines of 'make 1.11 release', which goes, does the svn copy (to the right name), and perhaps even collects that archetype, maps, and sounds. Some of it gets trickier - for example, to make the ChangeLog file appear a little nicer, I remove the 'for top of SVN' in the branch - and just have 'Fixed in release 1.10'. That could perhaps get scripted, but becomes a question of whether it is worth the time to try and script it (it may be that the automatic script fires up an editor). OTOH, automating it too far may be bad. IT may very well be a case that we say we'll do a release on some date, and someone says they'll take care of the archs, another says they'll do the maps, etc. Aside from splitting the load, there could be other reasons - the person doing the most work with the arches may be the person that is also doing the release - this makes sense - he'll know when his changes are in, etc. there are also some things just not easily scriptable. Like for me to build the 32 bit rpms, I have to boot my other computer, log in, run the commands, etc. Running the commands to build the RPM is the easy part - it is the other steps that take more time. In terms of more frequent 'build' releases, I'm not sure how that really differs from a normal release. If it is a semi private release (not uploaded to sourceforge), it probably won't get as widespread testing, and in fact may not get any testing. If it does get uploaded to sourceforge, then it basically becomes like a normal release - people are going to download that (so better make sure all the bugs are fixed in it), etc. I also think there is some limit on how often you can release those and get real feedback. On that note, I'd like to see a top-level tools directory added to SVN to encourage us to put our utility scripts in SVN for others to use. I worked a bit on a map spell checker, for instance, but because it is not good enough to release, it rots in my working directory. Such a directory would be a great place for scripts that could be used to manage SVN's bizarre concept of making you either waste disk space or have bazillions of individual checkouts. It would also be wonderful for the release process to be supported by scripts in that directory. That makes some sense. But from the description, it seems a little odd. If the scripts are not of release quality, there is nothing preventing us right now from putting those in something like maps/scripts-nrq (non release quality), and then just not include that directory when the data is tarred up. That may make more sense than putting them in a top level script directory - I just have visions of hundreds of scripts there, with no real clue what half of them do, and then you start wondering if this or that script should be deleted, etc. I think it also makes sense to have script dirs in the arch and map distribution - there are already a bunch of map checking scripts in the server area, but that doesn't make a lot of sense - people don't necessarily know that they are there, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/
Nicolas Weeger wrote: I think one major issue is how long it takes to make a release. For instance, I know there are some things to do for Windows server/client (and I will write that down somewhere!), but I don't know how long it takes. I know this release is taking a bit more time, but that is also because I'm documenting it. the arch and map stuff is pretty easy - it is basically make a copy to the branch, tar it up, and upload it. Even the server and client is pretty easy _if_ everything works correctly. The directions are basically update the configure.in, run autoconf, do make dist. The issue is when things don't work right - someone adds a file but forgets to update the makefile. Then you go through, fix that, repeat the steps, etc, and hopes it works. Also, for the client server, I do some extra checking, like can I run the client, log into the server, and have it work? Just a basic 'this isn't completely brain dead' type of thing. that takes some extra time, but after being hit one time with something being delivered that was braindead, it seems like a good idea. The time may also depend on your upload speed. Uploading 40 MB of map files takes a little bit of time on an ADSL connection. But in short summary, I'd say that normally it takes the good part of an evening to do a release (2-4 hours). If releases are done more often, I'd expect this to go down some - likelihood of release process getting broken is less when there have only been 20 changes and not 200, etc. IMO, what we should do is: * automatize to the maximum the release process. This can include writing sh scripts for Linux, scripts for Windows, and so on. [as a side note, I'm thinking of doing a small C program for Windows to replace the Perl script for maps, and make the build process more easy, ie change version numbers and such. C because Perl isn't needed, apart for arch collecting which i can do on my linux box) * time how much time a release takes * decide after we automate to the maximum :) See other post about automation. Certainly more automation can be done, and that shaves some time off. I suppose the main advantage of automation is it could be something that you do a 'make release 1.11', go to bed, and next morning, log on to find everything worked and the files are uploaded to sourceforge. At least for me, it may be a little while before I trust everything that much. And I'm sure it could be automated more - I think it basically came down to: A) Do a write a script to automate it more, which will take X amount of time to write and make sure it works B) Just do it by hand, where it takes Y more time than fully automated Where Y*NUM_RELEASES X, but unclear what value NUM_RELEASES are. it's also a matter of time concentration. If Y is 10 minutes, not a big deal - just means I go to bed a few minutes later, and shaving 10 minutes off probably means I go to bed 10 minutes earlier. if X is 90 minutes, that is enough time to actually do something relevant - look into fixing some bugs, writing new features, whatever else. I would aim for something like a release every 2 months. It may appear short, but if release process is automated well we don't take much time to release. It would enable us to have many tests and such. More frequent releases do also have the advantage that there is likely less breakage. Note that we should probably do trunk releases too, so people get to test it. The trunk releases get messy, because from what I recall, what we have right now in trunk may not be compatible with final release of 2.0 (in terms of maps, locations, etc). So it gets sort of tricky to put this out there, but don't rely on it too heavily, because things could change in incompatible ways. But that sort of discourages people from using it. Its sort of a different discussion, but the compatible breaking changes should probably be done as soon as possible, so that the rest of more tweaking, fixing bugs, etc. But time doesn't always work that way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/
Kevin R. Bulgrien wrote: Log Message: --- 1.10 branch Hello. I (and I'm sure others) would have appreciated some notification of incoming 1.10 release, as I'm trying to fix some things related to Windows version of server. Could I ask for ~2 weeks notice before releases, so we can freeze stuff and fix critical/blocking bugs? Nicolas The old adage about CVS not being a replacement for developer communication likely applies well in this situation, IMO. 2 weeks not needed here as _any_ notice would be appreciated. I had two regressions to fix in maps. I could have had them fixed in a few hours, but had just discovered them through playtesting and was needing to experiment a bit to learn how to fix them. (I have fixed them now, but it is too late.) With 24 or 48 hours notice, these regressions might have been fixed for the release as I could have upped priority for hammering out a correction. I acknowledge it is my problem for not having tested well enough before committing. At the time I did test on my server, but did not have in mind the nuances of testing for hidden attribute changes that come in from the arch when switching out floor pieces. I know now, so hopefully it won't happen again. As said before in other thread, sorry about no advanced notice. If I knew I was going to make the release last weekend, I would have given advanced noticed. It just turned out that I found myself with the time to do the release when I sat down at the computer at the weekend. So I basically had these options: 1) Start the release process since I know I had time then. 2) Give notice about an upcoming release, and hope that I'd actually have the time to do it before when I said so. My estimated probability of this was low (and if the deadline is missed, it almost seems like the process is restarted, since at some point, the immediancy of a release coming out goes away. 3) Do neither - wait 2-3 months when I estimate I may have time, and schedule a release then (which would be when the release is done if I missed schedule on #2) IMO, none of those is ideal - the ideal is ability to announce I'll do a release in 2 weeks, and then actually do the release then. But as of right now, that seemed low. And since there were no docs, its not like I could point someone else to do the release in that timely fashion. Hopefully, since I'm writing docs, that may be more doable. Looking back, the only thing I might really change is perhaps saying something on irc like I'm going to do a release starting right now - if you have anything ready to commit, let me know now and commit it, to catch any of those ready to commit fixes (but that in itself can sometimes be dangerous). If I had a time machine, I'd send a note to myself 2 weeks ago to send mail to the list saying I'm going to do a release in 2 weeks. But I have to go on what I knew at the time, not what I knew later. Otherwise, I still think my decision to do a release now is better than waiting another 2 months for a release. Even though the code has some bugs, I'd say it is better than what is out there right now as 1.9.1, and at some level, getting code out there for others to use has some advantages. This is one of the arguments for frequent releases - sure, each build will have some bugs, and could be made better if delayed, but by getting the builds out there, you get people to discover some of those new bugs so that they can get fixed in the next release. If infrequent releases are done, quality may in fact not be better because people are stuck using an old buggy build for a longer time period. Now to turn this more constructive, I think the real question is: How often should we be doing releases? Every month? Every 3 months? Somewhere in between? I think anything more frequent then every month (save for critical builds/to fix something DOA) doesn't make much sense, as I don't think the 1.x branch is changing fast enough. I also think that less than every 3 months is too long a gap - just looking at the client, there were lots of things changed since the last release, such that if there were 3 releases in that time period, each would still have enough changes to be compelling. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] plugin crash on metalforge.
Looking at some of the crashes on metalforge, which is latest 1.x as of a
week
ago. Saw 2 crashes wit the same cause. From the logfile:
[Debug] ** EVENT HANDLER **
[Debug]- Who am I :Moneygoose
[Debug]- Activator :reaper
[Debug]- Event code:1
[Debug]- Event plugin :Python
[Debug]- Event hook:/python/casino/platinumslots.py
[Debug]- Event options :event_apply
/home/crossfire/share/crossfire/maps/python/CFItemBroker.py:23:
DeprecationWarning: integer argument expected, got float
self.object.Quantity=tmp
[Debug] ** EVENT HANDLER **
[Debug]- Who am I :event_destroy
[Debug]- Event code:13
[Debug]- Event plugin :Python
[Debug]- Event hook:cfpython_auto_hook
[Debug]- Event options :event_destroy
[Error] Trying to remove removed object.
arch event_destroy
name event_destroy
name_pl event_destroy
title Python
slaying cfpython_auto_hook
nrof 53
type 116
subtype 13
end
the offending code is Crossfire_Player_dealloc() in
plugins/cfpython/cfpython_object.c:
static void Crossfire_Player_dealloc(PyObject *obj)
{
Crossfire_Player *self;
self = (Crossfire_Player *)obj;
if(self) {
if (self-obj self-valid) {
free_object_assoc(self-obj);
if (self-del_event) {
cf_object_remove(self-del_event);
cf_free_object(self-del_event);
}
}
self-ob_type-tp_free(obj);
}
}
In this particular case, self-obj == self-del_event, which is why I think
this may be getting freed twice, but not 100% sure of that. Can someone with
more plugin exp look at this?
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] House sizes
Aaron Baugher wrote: Mark Wedel [EMAIL PROTECTED] writes: Also, there is some limit on how big multipart images can be - I'd have to look at the map protocol, but I think right now it is somewhere in the 6-8 space range. This could be fixed in various ways. I don't know if there's a limit on tile size, but there's a 1-byte limit on images sent to the server in MAX_IMAGE_SIZE. If you raise that, you soon run into MAXSOCKSENDBUF, which is currently 12239 bytes. (I discovered those when I converted the Demon_Lord into a single image and it was considerably larger than that before compression.) I was able to compress Demon_Lord, which is a 4x8 image, to 7841 bytes, but it only has two colors, so I'm guessing a more colorful image would be larger. There are certainly different things that could be done. One would be to have a separate server/process that serves the data file - that could be desirable for other reasons. I'd probably also be good to really force caching to be the standard also. But this is also a different discussion. Also, do many players still play on an 11x11 map view? Buildings that are 5x5 or so would make that map feel *very* crowded. Maybe we could assume that by 2.0, all the clients would be capable of displaying a larger area than that? I don't know how many play on 11x11 (could look at the logs and figure it out). However, one discussion was to have the map size be closer to 19x19 and not the max of 25x25 it is now. 19x19 is still good size, but start put down houses that are 5 spaces big, you may not see a whole bunch. This could also lead to other areas - the town walls should appear higher, trees perhaps bigger, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Max speed
Nicolas Weeger wrote: Related to bug https://sourceforge.net/tracker/index.php?func=detailaid=1539207group_id= 13833atid=113833 concerning the max_speed when wearing armor, I've changed the logic in fix_object (former fix_player) to always cap speed at armor's max_speed. Apparently that fix was too restrictive, so I kind of reverted it. Now, it would be nice to decide the exact logic we want for max speed handling... Currently, what (apparently) happens is: * speed is computed based on dexterity, and max allowed by armor Strength also plays a role, in that it determines how much you can carry, and how loaded you are also affects speed. * some speed is added, from objects in inventory having exp set (?) For objects, exp was used to denote speed adjustment for characters. This is because the normal speed field is used for animation or other logic so couldn't be used. That should really be fixed, and changed to something like 'bonus_speed' or the like. * some more speed is added, from objects having exp set (but only positive values are taken into account) * carried weight is taken into account * disease induced speed is applied * minimum speed is enforced This looks to me like a kind of mess, so we should probably decide how to fix that :) I had another thought, don't know if there is a tracker item, to completely redo how speed is done. Briefly: Normal max speed is 0.75. Normal min speed is 0.25. These values should actually be things in the settings file. How loaded you are determines your base speed. Eg, if 50% loaded, your speed would be 0.5 (0.75 + 0.25)/2 * (1-0.5) + 0.25. If your are 25% loaded, your speed would be 0.62. These values are to improve playability - if a character speed gets too low, it is just annoying to play, as you move once every few seconds. Likewise, this max speed is so fast objects still move fast - arrows faster than the player, etc. Objects that give magical speed bonus would add to this value. So speed values greater than 1.0 are still possible with things like speed boots, etc. Armor should have some effect - I'm not sure if it should be a hard limit (can't move faster than 0.6), or if those should more denote adjustments to current speed - instead of max speed, have it be speed penalty. That penalty could be absolute (drop .2 no matter what) or could be a percentage - wearing plate is going to drop your speed by 25%, so if you speed is 1.0, with plate, it is now 0.75. If your speed is 0.25, with plate, it is now 0.18 This cleans things up, but I think also improves playability - really fast players are an issue, and real slow players are not a good experience. Note that in above formula, dexterity doesn't play a part anymore. However, it still would for weapon speed, which is done differently IIRC. This could also make some new spells (or maybe they exist) more reasonable. Eg, something like haste that gives you bonus speed of .3 for some amount of time could be really handy - as of now, moderate to high level characters have really high speeds, so don't really need an extra boost. Such a change should be targeted for 2.0, since it would change gameplay quite a bit. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] House sizes
Alex Schultz wrote: Mark Wedel wrote: But I think that is a bit low - there would never be use for any 1 space buildings. a 20x20 seems reasonable. I think to be clear, you need a range, like 15-30/space. In that way, it becomes pretty clear how big an object should be - if 31, that is 2 spaces. Otherwise, if you just say the scale is 20:1, does that mean a building that is 30x30 should be 2 spaces by 2 spaces? What about a building that is 21x21, etc. I'd say ranges certainly do make sense. Personally, I'm not sure 10x10 would be so bad however. To me it seems that outdoor buildings with a scale matching the 10x10 scale would be more immersive. Despite that though, I think it would be best to see some mockups of each scale to get an idea of how it would feel to play with. It just seems to me that if 10x10 is chosen that there would be very few to none single space houses. I can't think of many maps that are 10x10. Another question on this could be height - if a map is multiple floors, after how many floors should the icon depict some height (I'm not thinking about basements/dungeons, but second/third/fourth floors). With the bigimage support, an object can have height without an enlarged footprint - a tower could appear to be 2 spaces high, but still only have a 1x1 footprint. - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns bigger in the bigworld, but at the same time it would make the whole scale more coherent i think I think we need to be careful here - based on the map size (and past discussions which says 25x25 may in fact be too large), you don't want to make buildings too big. Otherwise, the player only ends up seeing 2-3 buildings. But maybe that isn't a bad thing - then at least towns could get big enough to start to be interesting and/or confusing. Well, IMHO it could be a good thing, provided it was well done. So long as it's just as (or more :)) visually interesting, and it doesn't impair navigation of the city much, then it'd have the effect of making things feel more immersive. Yes - bigger cities would be nice. Also, cities that have less empty houses would be good. While it may not be realistic for every building in town to be a map, from a gameplay perspective, it makes exploring more interesting. Also, the 'xyz is closed' is a misleading message to new players - if I saw this, I'd think 'so when does xyz open', thinking there could be time based events, etc. If bigger buildings were done, it could also make sense to add more 'blocksview' spaces to the maps - I shouldn't really be able to see the street behind the one I'm in if its full of big buildings. Individual blocksview type arches would be needed, as if you set it on a multipart building, it becomes the property of the entire building - more likely, it should be set on just the portions of the building away from the street (maybe those should also block passage also - don't know). I'd be wary of actually re-doing existing towns - moving apartments and other permanent maps about starts to get messy. However, no towns could use the new scale. And for some towns, a bunch of small empty houses could get replaced by fewer buildings that actually have stuff in them. Well, one could target re-doing of existing towns at 2.0, we could create true bound-exits where one exit refers to another's location regardless of if they move, or thirdly there is the option of just designing the redid town specifically so the old perm apartment exit was to the right place. Any of those three options would fix the issue IMHO. True - if redone for 2.0, that would work fine, as we'll probably be making enough other incompatible changes that it would be a start over type of scenario. At some point, someone actually investigated doing everything in one scale - that'd certainly make the towns big, but probably too big relative to the current size of the continent. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] House sizes
Nicolas Weeger wrote: Hello. What would everyone think of: - deciding that eg one outside square translates to eg 20x20 squares inside. There may already be such a measurement, but I'm not sure it's that formal IIRC, there was some measure, like each outside space is 1 chain. A chain is somewhere between 60-100 feet. If one wanted to try and unify scales, one could use that as a base. If each indoor space is 10', then for each tile outside, it would correspond to 10 tiles inside. But I think that is a bit low - there would never be use for any 1 space buildings. a 20x20 seems reasonable. I think to be clear, you need a range, like 15-30/space. In that way, it becomes pretty clear how big an object should be - if 31, that is 2 spaces. Otherwise, if you just say the scale is 20:1, does that mean a building that is 30x30 should be 2 spaces by 2 spaces? What about a building that is 21x21, etc. I'd personally like some more buildings, simply because some buildings are getting re-used for different things (the guild building is used for guilds, but also the bank and some other buildings). But some could also just get changed with existing images - to me, the building currently used for the zoo could be a good bank building (it looks like a fortified building, which would make sense). Could even be interesting to have different guild buildings for the different guilds. And unique buildings for more of the religions (some of the ones in scorn are just re-using generic house images, etc). - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns bigger in the bigworld, but at the same time it would make the whole scale more coherent i think I think we need to be careful here - based on the map size (and past discussions which says 25x25 may in fact be too large), you don't want to make buildings too big. Otherwise, the player only ends up seeing 2-3 buildings. But maybe that isn't a bad thing - then at least towns could get big enough to start to be interesting and/or confusing. I'd be wary of actually re-doing existing towns - moving apartments and other permanent maps about starts to get messy. However, no towns could use the new scale. And for some towns, a bunch of small empty houses could get replaced by fewer buildings that actually have stuff in them. There also isn't any reason that the world has to be static - one could certain envision various buildings showing up outside the town walls (town no longer big enough), or a new section of town built with a new section of wall, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Static buffer removal for query_name()
Nicolas Weeger wrote: Another concern is that I may have used a buffer too small for certain things (used MAX_BUF instead of HUGE_BUF like it was). Thus some strings may be truncated, that will need some checking (but that shouldn't crash!). for query_name(), I doubt that buffer size makes a difference. where it may be an issue is describe_item() and get_ob_diff() - but I'm not 100% sure if those return static values or not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Data File (Maps, Archetypes) Encodings
Christian Hujer wrote: Hello dear co-devs. We have a common problem with the text encodings of data files. Examples: * Daimonin used (until a few minutes ago) the ISO paragraph character 0xA7 for separating a map's sound spec from its name. * Daimonin uses the ISO degree character 0xB0 for highlights in messages. * Crossfire uses the a circumflex character 0xE2 for the name of a wine in map /maps/scorn/houses/house3.bas2. Not sure if still the case, but at one time there were some objects that also used special characters - Mjølnir comes to mind. This leads to some problems. * Crossfire x11 client displays 0xE2 as a circumflex. * Crossfire gtk client displays 0xE2 as ? (tested by Ragnor). And it appears in the GTK2 client, it won't draw the entire line/message that has the bad character. For both projects, it makes sense to rethink the file formats. I see three possible solutions: 1. Use US-ASCII text only. That means, only data files with bytes 0x13, 0x20-0x7E are valid. Pro: easy Pro: stable Pro: no changes required. Con: very limited solution And one that is currently not in use, as demonstrated we already have some non ASCII characters making their way in. 2. Use ISO-8859-15 text. That means, bytes 0x13, 0x20-0x7E, 0xA0-0xFF are valid. Pro: easy Con: clients need special handling for non-ascii chars if they are UTF-8 aware and run on UTF-8 systems (e.g. gtk client). Con: limited solution 3. Use UTF-8 text. That means, only valid UTF-8 streams with Unicodes u0013, u0020-u007E, u00A0-... are valid. Pro: future-proof Pro: Allows full unicode (e.g. Chinese chars if somebody likes, or even klingon if the underlying system supports it). Con: clients need special handling. Con: Windows users or users of other ancient OS editions with no good UTF-8 support will have more problems than with ISO-8859-15. I see two places, where the encoding needs to be specified: * Data files * Network protocol My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike 2. ISO-8859-15 very much. #3 probably makes the most sense, and at least for the gtk2 client, looks like it would actually be handled properly (as the message generated on the wine bottle is about invalid utf8 character). Also, I'm not sure how easy #2 is - it is easy from a person writing the maps or archetypes, but as demonstrated, pretty much all clients would have to do special string handling. #3 does make it harder for people putting the strings in (I'd think the map editors could try to do the right thing in those cases and covert ISO 8859 15 characters to unicode) So I'd vote unicode. I'd suspect that for clients that don't support utf8, things won't really be any more broken than right now - the client would display a funky character instead of the correct one. But I don't believe that would break any portion of the clients or protocol. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] desktop file: help request
Lalo Martins wrote: Not for the first time, someone came to #crossfire today, requesting help to install crossfire, and it turned out he already had it, but couldn't find it. It turns out we don't ship a .desktop file for the gtk-v2 client, and distros such as ubuntu and fedora won't modify the package to add one. There is such a file for the gtk client, but it refers to a non-existent icon file. So here's a very simple battle plan: 1: Write a proper .desktop file for gtk-v2; possibly use it as a model to update the one for gtk too. I already committed that file. Looks good. I wonder if we should include something to differentiate the gtk1 2 clients. On my system, I do have the icon with the gnome menus for the crossfire client. And all it says is 'Crossfire Client'. If I hover my mouse over it, it gives me a description, but still doesn't say anything about what client is. Often times on the channel, it is recommended someone use a particular client. As the things go now, other than the person running it, there really isn't much client what client they would get. Even calling it something like 'Crossfire Client (Gtk2)' would be much more useful. 2: Hook up the build system to install this file to $PREFIX/share/applications or whatever is the appropriate autotools magic. I really don't have time to relearn what little autotools I used to know to do this, so if someone who knows has a few minutes, please help here. This is in the RPM packaging. The normal make install doesn't do anything with the files. The fact that for it to be of any use, it must be installed in the global area, which has a pretty high probability of being outside of whatever --prefix is set to is one reason. One problem is that I believe a uniquely named file is needed for each program. So as things are now, with both the gtk and gtk2 using the same name, when installed, one will get overwritten. The one in gtk2 should be probably be renamed crossfire-client-gtk2.desktop - at least in this way, the name of the desktop file does match the executable. 3: The icons should be the ones in pixmaps/*.png, but they are corrupted -- probably need the right propset to be recognised as binaries. Could someone with the svn fu please do this one? This should now be fixed. 5: Again, they need to be hooked up to the build system, so that one of them (presumably the higher resolution) gets installed to $PREFIX/share/pixmaps/crossfire-client.png Is that to make them more easily available for users to find them, or something else? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changelog for maps and archetypes
Nicolas Weeger (Laposte) wrote: Hello. What about we create a ChangeLog file for maps and archetypes too? This way we could track what happens more precisely than commit messages. Perhaps not a bad idea. There actually is a CHANGES file in the arch directory, but tends not to get updated. One problem is that often times, the changes in those seem more trivial, so you get the question of whether there should be a change message for them. There is some understanding that really minor changes in the server/client code don't require an update to the changelog - I'd say for arch maps, more trivial changes should be recorded, because the number of changes that otherwise match the criteria are not very many. Also, I suggest we resurrect the Crossfire Traffic (http://wiki.metalforge.net/doku.php/crossfire_traffic), for gameplay and such changes. That seems like a good idea. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire bots
Alex Schultz wrote: Nicolas Weeger (Laposte) wrote: Concerning feature request Newbie Bot - help those noobs :) https://sourceforge.net/tracker/index.php?func=detailaid=765770group_id=13833atid=363833 is there such a bot currently? I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to such a request? (this request, at least of a bot giving advice, is quite interesting imo) Personally, I think this could be better implemented as a server-side script than a bot, however the base concept seems interesting. Yes - doing it as a bot would seem pretty hard, as what is mentioned in the bug report are some things that it may be harder for the bot to identify. Of course, we could make the newbie area more mandatory, too :) IMHO also a good idea and perhaps even somewhat necessary. As I mentioned, that would seem like a good idea. Some other random ideas: - Give all character 5 or so food to start out with so they will have a while before they need to get some more. - Maybe give them so low power (like 10 hp) healing potions - Looking at the 2 beginner maps, they don't go over some of the more basic points of the game, as mention in the tracker item: - nothing about eating food (and the fact that monster remains can typically be eaten also - Nothing at all about using shops. A very small shop, with perhaps a basic detect curse/detect magic/identify altar on the map, with some cursed/magic items on that map for them to use/try out (maybe make those altars very cheap, but make this map a 1 way journey - once you exit, you can't get back) - Maybe some mention about chat/shout and the etiquette on using the - Not sure if explicitly mentioned in any of the maps, but the fact that just standing around will regain hp/sp It seems the beginner maps otherwise cover basic of attack, traps, spells, so those points are covered. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Duplicate code
Alex Schultz wrote: Hi, I just ran some duplicate code checking stuff over the cf code base, and made a little report of some of the more significant cases. Perhaps we should store this list on the wiki or something so people can easily check off dealing with aspects? Some quick notes, without digging in too deeply on these: Alex Schultz random_roll() at line 66 in common/utils.c random_roll65() at line 111 in common/utils.c Some duplicated code. Not sure at a glance if it can be merged. Actually, that is random_roll64(). In practice, all calls to random_roll() could just be replaced with calls to random_roll64(), which the extra bits on the 64 bit version most likely being dropped (think that is what happens if you cast a larger size to a smaller). It is possible that the 64 bit version is more costly, cpu wise, than the 32 bit version. Probably not an issue. roll_stats() at line 821 in server/player.c swap_stat() at line 872 in server/player.c swap_stat() seems to duplicate some code for resetting some things like level. To me this looks redundent. Hopefully, at some point, those just completely go away with client side player creation, so I wouldn't be too concerned about cleaning those up. find_skill_by_name() at line 147 in server/skill_util.c find_skill_by_number() at line 197 in server/skill_util.c Code to find the correct skilltool object is duplicated. That should probably be moved to it's own function. yes - I'd say the main portion is a little further down - the code that actually readies the skill_tool and finds the name, etc. Since that is about 20 lines that is the same. The block within the for loop doesn't seem to make sense - that is just a single line that does the same thing - putting that in a function wouldn't be that useful. The rest of the for loop itself probably can't be changed much, since it is comparing different things (number vs name). line 306 in include/global.h line 8 in include/xdir.h Handling for HAVE_DIRENT_H is in both. Should be removed from one. Doing a quick grep, it doesn't appear xdir.h is in fact used by anything. So that file could just get deleted and it shouldn't affect anything. fire_bolt() at line 304 in server/spell_attack.c fire_bullet() at line 629 in server/spell_attack.c Identical 14 line code block used for handling reflecting bullets and bolts. Should probably be moved into it's own function. yes - reflect_object() may make sense. socket/*.c In many places there are significant amounts of duplicated code to send or recieve similarly formatted commands. Perhaps more helper functions for socket stuff is in order? Not much that could be done other than add some more helper functions which isn't a high priority. Some of that could also be because of different revisions of similar commands (item, item1, etc). If the old ones are removed, that may clean things up bit. At some point, it becomes harder to figure out if a bunch of: if (protocol) ... else if (protocol2) if (protcol3) Type of things become cleaner with that type of logic, or just duplicating the similar code elsewhere but not having those if's is clearer (so you can just read down the function and see very clearly what it is doing). kill_player() at line 2677 in server/player.c kill_player() at line 2900 in server/player.c Identical 17 line code chunks used for removing poisoning and confusion, once for in battlefields and once for outside. A seperate function should be made for this. Perhaps a two functions, one for poison and one for confusion. Probably even better is one function that takes an option on what to remove, and then returns true/false based on of it actually does anything. This might also be useful in some of the healing and praying over altar code also. line 111 in common/init.c line 696 in include/spellist.h spellpathnames is defined identically in each. It should only be defined in one. Probably best to remove it from init.c Actually, except for that array, there is nothing in the spellist.h file that is actually used anymore. Doing a quick grep shows that spellist.h isn't being used by any function, so could also just get deleted. Otherwise, having duplicate initializers in .h files tend to result in duplicate symbols (the linker doesn't care/know that they are the same value) - that can be avoid by declaring them static, but then the data is being reproduced in every file, increasing file size some (and compilers will often complain about static values no being used also) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Release of 1.10 soon.
I'd like to make a 1.10 release of crossfire sometime soon. So if you have bugs you're currently fixing, getting those fixes in now would be good. If you are aware of any unreported bugs, please report them now. If you need time to fix some bugs, please also let me know. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Code Doxygenification
Nicolas Weeger (Laposte) wrote: Agreed. One thing we should perhaps check is if the terms of use for the sf.net compile farm/shell server allows us to run doxygen on it, not really sure it would but it would be nice if we could. If nobody else is able to, I could run a nightly cron job (which won't run unless the doxygen config or a code file changes in the 24 hour period) for it around 10:00 UTC or so, however I wouldn't be able to host it myself so I would need to upload it somewhere else. Anyone have any suggestions for options for this? IIRC, the sourceforge folks only want the compile farm used for interactive use - no cron jobs, etc. Plus I seem to recall some odd things regarding access to web area (or maybe it was SVN) from the compile farm itself - something with it being inside the sourceforge network/firewall made things different. I'd have no problem setting up a cron job on my home system and copying the data somewhere, but that somewhere is a trickier issue. sourceforge provides web space, but also requires that every web page for the project has the sourceforge logo. I'm not sure if there is an easy way to modify doxygen to include that. I could host the data myself, but it would be better for it to be on one of the more official crossfire sites. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Code Doxygenification
I think that the proposed changes are fine. Updating the functions as they are changed or other nearby functions are changed works, but the end result is that it means it can take a very long time for all the functions to be documented. And if the goal/hope is to have some coherent documentation available, getting it done sooner vs later is probably good. We can sort of look at the other various code cleanups going on - fixing indentation has been going on for quite a while, and still not done. Some functions really are not changing much (the arch.c file gets occasional new function added, but I don't think some of the functions in there have been modified for years), so it could be a very long wait for change to happen. OTOH, doing this cleanup or indentation fixes is something that can be done in small doses. I know that for myself, if I only have 30 minutes to spend, I may not going on a coding project, knowing I will be unable to finish it in that time. However, I could certainly document several functions in that time period, etc. Also, do we have any plans for putting this doxygenification online anyplace? I imagine this could be done automatically (have a cron job that generates the documents and then upload them to some server nightly or something). One nice thing about doing something like that is that then the results are more visible ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Item power/enchantment question
Nicolas Weeger (Laposte) wrote: Hello. Regarding bug https://sourceforge.net/tracker/index.php?func=detailaid=1612838group_id=13833atid=113833 (Problem with item_power code), I'm wondering if there is somewhere documentation about what item power and enchantment are supposed to do? :) So we can fix as the documentation says it should work, or fix the documentation ^_- The armor improvement code appears to be broken. IIRC, the weapon improvement codes does this more properly - each time an item is further enchanted, it just adds one to the items current item power. This perhaps isn't perfect (since the automatic method is sort of exponential), but seems fair. It could be reasonable that some forms of enchantment are more valuable than others, and so should perhaps increase the item power by more than one. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Curse bug
Nicolas Weeger (Laposte) wrote: Reading fix_object (former fix_player), it seems to be there's a big mess waiting to happen (or already happened?) :) Basically, fix_object resets many many things, including all special flags (see in dark, stealth, ...), resistances, ... This means all those custom values will simply disappear whenever a monster will drink a potion, be hit by a curse or a disease, things like that :) Of course fix_object works fine when called with a player, but will horribly alter things for a customized monster. I can see a few possible fixes: * fix fix_object so it handles things correctly It's unclear how one can simply fix fix_object(), because as you describe, there are lots of values modified, so you basically need to know what those are (fix_object has to start with some baseline of what the initial values are supposed to be). * don't call fix_object except when absolutely required. Recode eg curse to simply decrease wc, and restore it later when the force expires. Of course it's a mess with other things modifying wc Yes - especially if the monster has already been modified so some attributes are near maximums. Eg, if a creature has fire_resistance 100, anything that adds fire resistance won't have any effect. But if a player cast a fire resistance spell on the monster, when that spells ends, the monster still needs to have fire resistance 100 (you can't take away the resistance the spell would give). There may be osme other cases like that - the way the bonuses stack, max/worse bonuses (if wc is -120, nothing can improve it further, but if the monster unequips it, his wc should still be wc -120 if that is what the map set it to, etc). Plus, it means you have places all in the code to handle this. I suppose the right approach would be to have a function for applying/unapplying these force objects to the monster, but there are so many odd cases. * we could store all modified values so fix_object knows what to search for. An overkill solution is to temporarily create an artifact for each customized monster, and free it when monster diseappears. Do you mean artifact or archetype? I'd think archetype would be easier - you could update op-arch with the new archetype (but really, you just chare about op-arch.clone). You could even store away the original archetype is op-arch.clone-arch This might be one of the simplest things to do - fix_player() really wouldn't need to be modified, because it already looks at op-arch for the initial starting values. What would need to be modified is the load code (to know when to create a new archtype) and the save code (need to go back to op-arch.clone-arch to get the differences, since the load code would go back to the original archetype for starting values). There is still a little complication - take this situation: Have modified monster, including say wc. Spell is cast on monster, modifying its wc Player leaves map, and map gets swapped out, so wc needs to be saved. You probably don't want to save the wc as modified by the spell, because then when the map is swapped back in, we no longer know what the original (modified) value is. You need to save the wc as specified in the original map (op-clone), and then when loaded back in, know to call fix_player() to get values back to normal (spell effect would be saved in the inventory, so doing this should get the same value back that was there before it was swapped out). That doesn't sound very complicated, but there are some values where you always want to save the op- values and not the op-arch values (hp, sp, grace) - I'm not sure if there are any others - everything else I think could be derived from the temporary archetype values. One other complication is this: Standard orc on a map orc equips some armor map is swapped out - orc now has different AC So in this case, you once again want to do the same thing above - save the orcs original values and mark it to re-run fix_player() at load. Otherwise, it looks like a modified value, and you don't want to create an archetype from that. The extra memory for the archetypes isn't likely to be that big a deal - crossfire as it is right now doesn't use a whole lot of memory given how much memory modern systems have, and if limited to modified monsters, that is a pretty low impact. One other method that could be used to fix the problem: For modified monsters, instead of modifying the values and saving those values on the map, instead create a permanent force object with the modified values (or more likely, the values necessarily to modify the standard archetype to get the modified values). In this way, when fix_player() is called, it finds this archetype, and everything works out. That would require a lot of maps to be updated. Ideally, the editor would be modified so that this is invisible to the map designer - the
Re: [crossfire] Documentation / wiki
Seems like a good idea to me also. I'd probably add that while most documentation is currently in ascii text, we do have a mix of some other formats (postscript html). I'd probably say that having more of the documentation be in HTML if it makes life easier probably wouldn't really cause much in the way of problems. It's not like HTML is some obscure format that people would have a hard time finding a reader for. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote: Mark Wedel wrote: Yes, all of this should go through a common code path, but saying those checks should be in the 'command' code may not be the right answer, depending on what the command code is defined as. What I'm saying, is that 'character initiated' actions should be separated from 'raw actions'. In particular, in some way such that all 'character initiated' calls follow a common code path that only applies to the 'character initiated' aspects. I was thinking that only 'raw actions' should be in the callback system. Though now that I think about it, one could potentially add in a central location, pl_ob_apply(), pl_ob_drop() and similar functions, which would do 'character initiated' aspects then run the callback (ob_apply() and ob_drop, etc.). I'm not sure if it should really make any difference how the operation/callback is happening. If there is a callback for dropping objects, then any way they are dropped (explicit player command, monster dying, chess being burned up, etc) should all use that same callback. This gives us consistent behavior. This is better than cases where different things happen, as from a player perspective, that doesn't seem to look right. That said, for some operations, there is likely need for some upper function that finds/gets the parameters that the callback needs. In the apply example, you'd have the case where the player does 'apply bow'. In that case, the apply command has to find the object of the correct name, and then do the callback. If the player applies it via mouseclick in the client, the server has to look it up by tag, and then pass into callback function Then there could be the other methods (player steps on something like a teleporter that causes the apply logic to come into place). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote: Well, I'm thinking that we do have a BASECLASS, we might as well use it for transitional fallbacks, OR better yet make a TRANSITONCLASS or something, which the BASECLASS is based on. I would say that would be just as easy to follow as things like apply_fallback() and in fact on can make names like that a convention for transitional functions. Also, fallbacks could potentially be handled very easily and generically in the functions like ob_apply(), such as in this example: The only issue with using the baseclass for fallbacks of old code is that the calling structure has to be the same. If the new callbacks have more/different parameters than the old function, then you have to go back to the old function and change it around a little bit. Any functions so called may need other changes - they may generate error messages if the object type isn't handled for example, or possibly other issues. The question then becomes if it is worth it to do changes/debugging vs just change the function, move it to the new code and callback method. I also think more thought/discussion on these different callback mechanisms need to be thought out. The idea of per object callbacks have also been mentioned. How all of these interact need to be clearly defined. For example, is the BASECLASS callback always made, regardless of anything else in the object? Is it only made if if there isn't a specific callback registered, etc? Depending which is done, that is a major difference, and has to be reflected in the code that is written. If it is always called, to a great extent, it then limits the usefulness of the callback structure as a whole (it limits what can be done with the object). If the actual type handlers make the callback to the base function, that is fine - it just needs to be clearly defined that is what should be done. And in that case, it could perhaps be used as a transition. I still wonder how much that does make sense, as in that case, the type callback would know what the legacy function is, and wouldn't really need a baseclass mechanism to figure it out, simply because there is an old function is a single function that would cover everything. I was thinking overrride would be determined by the object (or person) using the objects themselves. In the curse example, you could check the person unapplying it, and if the WIZ, let them do so. Sure, you could pass in parameters for that, but I doubt that is necessary Well, the thing is, I believe it would be beneficial to have the extra flexibility of being able to make these calls and have the caller make overrides for reasons other than WIZ and such. It's not that it's currently needed, but I'd prefer to leave the opportunities for such open if reasonably possible. But how do you reasonably do that, if you don't know what overrides are needed? Only thing I can really think of is to just have an integer parameter that you pass it, that could contain various values (bitmasked) that could be added extended. The main problem there is that if some override is added, there may be 20 callbacks you need to add code to. Which is why having that in the top level handler makes it easier - only one place that the code needs to be written. In all these cases, that code will be someplace - it is just a question of where. For some things, doing it in the command code isn't ideal, because there are several ways for the command to be issued (some are processed by the client and sent as lower level protocol commands in addition to having text commands the player an use, etc) - in those cases, you want the check code in the function all of those call so it is in one place, not 3. Well, IMHO if the command code doesn't have a unified method for calling something like apply or drop, then perhaps that needs to be cleaned up, so putting those checks in the command code would be practical. It depends on how you define the command code in this context. At some level, all the drop stuff eventually calls the same function, and in that function, it can check for various attributes (god given equipment, etc). However, there are probably at least 4 paths to get to that function, depending on how the object is dropped. Picking stuff up would probably be more so if you think about it. There is the automatic pickup modes, there is mouse control (right click), there is keyboard control. You can also get objects indirectly added to your inventory (being hit by an arrow). Using shops can sort of change inventory (coins added to make change, etc). Yes, all of this should go through a common code path, but saying those checks should be in the 'command' code may not be the right answer, depending on what the command code is defined as. ___ crossfire mailing list crossfire@metalforge.org
Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote: Another thought, perhaps instead of the else though, we could use the BASECLASS via another ob_methods structure as mentioned in a different mail, to implement the falling back to the old function. Not only is it well suited to falling back to the old function, it IMHO might prove a useful system to have in place for after the conversion is complete, particularly once getting into per-arch and per-object ones with plugin support. I personally wouldn't be overly concerned about neatness while in the transition. After all, it is a transition, and will eventually go away, so being too concerned about how it work doesn't make tons of sense. per arch/per object I think gets into some other issues. Registering them isn't hard - the more serious question is if those callbacks are in addition to the ones normally for that object, or are instead (or does something control that?). But that is a future discussion. I'd think for generic callbacks, it depends on its purpose. For the transition purpose, I think it'd have to fallback to a single function for all object types. I'd personally rather just see a call like 'apply_fallback()' type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 function for each type, it is easier to follow the code if you see exactly what the function is, and don't have to go look at BASECLASS to see what it is doing, etc. snip The previous example I had was about applying unpaid objects. I can't think of any case where that should be allowed, and if there was some specific reason, I think a flag on the object should control that, and not object type (as presumably, that object would have some behavior like existing objects). I think it is cleaner to have it like: snip (another different case here is dropping of damned/cursed objects - regardless of type, that shouldn't be allowed save for something special (DM)) Well, IMHO those dropping and unpaid restrictions should either be in the command code, or give the callback an 'override' parameter, because of the save for something special cases. Either works for me, but I am inclined against the 'override' parameter as it IMHO creates unnecessary complexity. I was thinking overrride would be determined by the object (or person) using the objects themselves. In the curse example, you could check the person unapplying it, and if the WIZ, let them do so. Sure, you could pass in parameters for that, but I doubt that is necessary In all these cases, that code will be someplace - it is just a question of where. For some things, doing it in the command code isn't ideal, because there are several ways for the command to be issued (some are processed by the client and sent as lower level protocol commands in addition to having text commands the player an use, etc) - in those cases, you want the check code in the function all of those call so it is in one place, not 3. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Protocol extension: exp table
For the client to do things like display scrollbars for exp totals (how close to next level, etc), the client needs to know the exp table the server uses. The following is my proposed addition to requestinfo/replyinfo protocol command. I can't think of anything more to add, but figure it is still a good idea to post it our here in case others have thoughts. exp_table (no parameters) This requests the experience table (what exp is needed for each level) from the server. With this data, the client can easily display how much experience is needed for the different skills or total exp value for next level. Data format: num_levels: uint16 - max level/how many exp values follow. level1 ... level num_levels: uint64 - amount of exp needed for the level. Note that num_levels and the actual exp values are transmitted as binary values. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote:
It may be better working on getting all of this infrastructure/callback
methods
in place, and implementing one type of object using them instead of focusing
on
the specific callback method (the web page mentioned doing all the apply
stuff).
Why? That way, if someone does write code for a new object type, all the
pieces are in place so they can use the new method. If only the apply
callback
is implemented, they can use that logic, but are left using old coding
method
for the other areas, that then needs to be converted down the road.
Also, by doing all the different callback methods, it provides better
coverage
of the callback logic, eg, if there are issues with any of the methods, they
will be found sooner vs later.
Well, my original thinking, was that if I were to do it by completing an
object type, instead of a callback type, then it would be somewhat of a
pain to make it redirect to legacy methods for other object types not
yet implemented in the new system. What's your view on that issue?
Some of it depends on how this is done.
If you replaced the specific calls to apply, drop, etc as they are sprinkled
throughout the code, then doing one type of function is easier.
However, what I was thinking is those functions would still exist, but
instead
of the case statements they have now, they would have something like:
if (callback_Exists_for_this_type) do_callback()
else { do switch statement}
In that model, doing a few types at a time is easier to do.
I also think you still want to have common top level/generic functions so
that
you can have some common code.
An example of this (albeit a trivial one) is checking that objects are paid
for before doing an apply. Rather than have that duplicated in every object
type apply function, you have it in the one generic one that calls the specific
ones.
A better case here may be something like examine/describe item, where many
objects may have some specific/unique properties, but many also have common
properties (value, cursed, applied, etc).
Second, if we're going to be writing all new functions, we should use some
other
'best practices'. In particular, for anything that would return a string
value,
they should be modified so that a string pointer (and length of that
pointer) is
passed in, instead of using static return buffers. This will assist if we
ever
thread the server, but it will also help prevent a few bugs (related to
this,
sprintf, strcat, and strcpy should never be used, but rather snprintf,
strncat,
and strncpy instead)
Well, I wouldn't say necessarily writing all new functions: I believe
some existing functions can be tweaked fairly easily to fit into the new
system. However I believe that when moving functions that map well over,
we should hand review them anyways, and perhaps use a checklist of
things such as those issues you mention like avoiding static buffer returns.
I think a lot of existing code can be re-used. I'm not sure how many
functions can be re-used completely.
I suppose the apply code is a reasonable example. For some object types, the
logic has been broken apart into its own function.
But some object types are still handled within a case statement. In those
cases, you'll basically need to write a new function.
But this really needs to be thought at the time of callbacks, as you'll need
to set up the function pointers to consistent.
To be honest, the only case I can think of right now would be the
describe/examine object logic.
Other thought not related to the above:
Given this is a major restructure, would it make sense to collapse/redo some of
the types, particularly the equipable equipment?
With the change of equipment (body info), for the most part, there is not the
need of all the types right now (boots, shield, helmet, etc) Really, the only
types (or subtypes) needed are likely:
WEAPON - some classes or gods are prohibited from using them so need to know
what are weapons and what are not.
BOW - like weapon above, but these also fire other objects
ARMOR - some classes can't use armor, so need this info. helmets, boots,
gloves, shields, etc fall into this.
MISC - anything else equipable that is not in the above that conveys
adjustments
to the players (eg, wands/rods/horns are not here, because they do not provide
ac, protections to the player simply by equipping them). But things like
rings,
amulets, necklaces (some of these don't exist but are being used as examples)
would be in this category
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote:
Well, the way I was thinking of doing it, would be to replace specific
calls to apply, drop, etc as they are sprinkled throughout the code, and
keep common code such as you say, in a common subdirectory of the
types directory, and then have the callback called by ob_apply(), call
something like ob_apply_common() at the start of it's code.
IMHO, with this method, the best way to handle legacy non-separated
logic would be to move that legacy logic to the types/common
subdirectory, and set it up so ob_apply() and such will call that if it
can't find a callback registered for the type.
That works I suppose. You do get into various questions that have no clear
answer. Like 'should the main drop function be in the commands.c file (since
it
is a command the player issues) or should it be in the types/common.c file'
I'd be somewhat inclined to have the command logic still in the command
(c_...) files, and from there, it does the callback. It seems (to me at least)
that is a little better - the basic command logic is still in the commands
file,
and the actual object specific drop is in the types area. But I can also see
the other point - lets put all the common object operations together.
I also do think that if there are standards in place that all objects should
follow (like not letting unpaid objects be used), that should be enforced, and
not something that is affected by object type. If some objects really should
change the behaviour, I'd be more inclined to say they should have specific
flags for such variations - one reason there are some many object types right
now is that there is some of that 'if type==FOO, I behave 95% like BAR, except
for this one little case'. The problem this leads to is down the road, someone
says 'which do I use, FOO or BAR', where if there was just a flag which
controlled that basic actions, that is clearer.
The other reason I'd like there to be common functions is that I think it
will
make debugging a little easier. With a single function that then makes the
callbacks if necessary, I can easily set a breakpoint in there to catch when
any
object of any type does that action. Otherwise, there isn't any easy way to
catch 'if any object of any type is dropped' type of thing, unless there is a
common function that every object type uses 100% of the time.
But it probably is more stylistically - to me, this seems cleaner:
void action()
{
some common code
make object callback
}
vs
void action_for_type()
{
make_common_call_for_all_types()
do my specific code
}
It just seems that if everything is going to call
make_common_call_for_all_types(), why not just call that in the first place?
Other thought not related to the above:
Given this is a major restructure, would it make sense to collapse/redo some
of
the types, particularly the equipable equipment?
IMHO This should be done as well, though one question is: would it be
worth completely redoing the type numbers and converting all of the
maps/arches? Or should we try to keep the numbers the same where
possible, and have the loader change type values that were collapsed to
the new value?
If maps are changing the object types, they are broken. While it is
sometimes
done, changing object types is pretty much never good behaviour, because other
aspects of the object are not updated.
However, for the archetypes, they should be updated with the new numbers - it
shouldn't be hard to do, and is definitely the right approach.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Few questions: Use form of server/types/foo.c or server/types/foo/bar.c depending on if the object type requires multiple C files to be clean. With the fact that the SVN repository is called server, it is unclear exactly what server refers to. If we include the repository name, is it: server/server/types server/common (example of existing directory) Or server/types common/ (being the exististing directory) IMO, I'd prefer the second form - put the types directory at the top level, relative to the server directory. This is how the socket code is, doesn't have any real disadvantage, but could have some advantages (better for unit tests? Better for stand alone program that does simulations, etc?) Function pointers: It's not specifically mentioned on how the callbacks are registed. I see one of two ways: register_apply_callback(type, funcpointer); or register_callback(type, funcpointer, callback_type) Both have pros and cons. The first case has the advantage that the compiler can do actual type checking on funcpointer. The second has the advantage you don't need as many callback functions, and it makes it easier to add new callbacks (add the new callback_type #define, update the number of callback types, and recompile. One could even do things like: callbacks[ob-type][CALLBACK_TYPE]() It's also not really mentioned on how the callbacks themselves are registered (that code has to be someplace). And rather than having a single function that registers all the callbacks for all the object types, I'd suggest that each type file has something like init_callbacks_weapons (or something). Then in some other place, you have that function that calls all the init_callbacks - having a function of MAX_TYPES lines longer is much better than one of MAX_TYPES * MAX_CALLBACK_METHODS lines long. The other advantage of this is that the individual types files themselves can then declare all the functions except the init function static, so that it can't be called by other functions. I suppose that one could use various system function calls to try and look up the function names and call them (presuming a standard naming scheme, like init_callbacks_46, where 46 is the type number for that object), but that may be overly complicating things. Other thoughts: It may be better working on getting all of this infrastructure/callback methods in place, and implementing one type of object using them instead of focusing on the specific callback method (the web page mentioned doing all the apply stuff). Why? That way, if someone does write code for a new object type, all the pieces are in place so they can use the new method. If only the apply callback is implemented, they can use that logic, but are left using old coding method for the other areas, that then needs to be converted down the road. Also, by doing all the different callback methods, it provides better coverage of the callback logic, eg, if there are issues with any of the methods, they will be found sooner vs later. Second, if we're going to be writing all new functions, we should use some other 'best practices'. In particular, for anything that would return a string value, they should be modified so that a string pointer (and length of that pointer) is passed in, instead of using static return buffers. This will assist if we ever thread the server, but it will also help prevent a few bugs (related to this, sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, and strncpy instead) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22
Alex Schultz wrote: Mark Wedel wrote: A choice between death penalties is interesting. But then you have to ask what the penalties are. Obvious choices: - exp loss - stat loss - monetary loss - time loss (character/player has to sit a while?) - other? Another interesting possible choice would be to complete some sort of quest that takes a while to complete and isn't the same every time. Perhaps put in a riddle generator and other little things. It would have the same sort of effect as time loss, only would be less boring for the player. That could just be annoying, however, if it is actually a requirement. And if it actually gives any benefit to the character (items, exp, whatever), then that becomes less a deterant. Plus, it seems that any maps we can make should be generally available. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Graphics, was Re: IRC traffic for Sunday Oct 22
Alex Schultz wrote: Graphics: -Symbolic value lacking in some cases -Good symbolism means recognizable at first glance I'd think that those could be cleaned up as identified. -Consistancy lacking it many cases That also needs to be cleaned up. I'd say that images should be consistent within the class of images themselves. For example, items you pick up would be one class, ground would be another class, etc. -Larger? That should probably get sorted out sooner vs later, as it has lots of other effects. Going to larger images has a pretty direct impact on viewable map size. Making such a change is a huge amount of work. Choosing a large size could be seen as some advantage, as resizing smaller will generally yield good quality where as the reverse won't. That is to say, if the images are 64x64, some people in order to get the map size they want will scale the images down to 40x40. That will appear better than image the images are 32x32 and for some people, they get scaled up to 64x64. Disadvantage is more bandwidth to download them (but maybe not a huge amount, as I imagine on the 32x32 images, there is a fair amount of overhead for the png header itself?) As an aside, the server does support multiple image sets, so in theory, one could make a 'big' image set. The problem is that the client would have to know that these are bigger images (and not just big images), which would probably require extending the protocol some, but probably not much. Other thoughts: - As per other e-mail I sent out, should player images be made larger to be more visible? - There are still a fair number of images that were never resized properly - several of the shops appear 'small' because they are - only 48x48 (centered in a 64x64 tile). IIRC, this was done in the xpm-png conversion - scaling up the images was disliked because of bad results, so instead the same size was kept, with I believe the hope that they would eventually get scaled up and touched up. That might have been more likely to happen if the images had been scaled up - then they look ugly, and someone takes the task to do the touch up. - IMO, more multi tile images, and greater use of them could be nice. There will always be the problem with scale, so long as the player is a single tile and most of the images they deal with are single tiles. If you had a prety hard rule that all buildings must be at least 2x2 to better suggest scale, that helps things out (but is major map redesign work). But another case could just be terrain. Multi tile hill images, and more/bigger multitile mountains could add a bit more flavor/variety to the game. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] UI changes, was Re: IRC traffic for Sunday Oct 22
Alex Schultz wrote: UI Ideas: -hp bars on player/monster images (darkschneider) I've played some commercial games that does this - this is nice in some regards. But within crossfire, has some more issues. I think it is sort of interesting not knowing how close you are to killing creatures. First, I think on maps with lots of single tile monsters (which lots of crossfire maps have), this could create a lot of clutter. I'd presume that an bars must be a total percentage and not absolute value. If absolute value, the problem is that the high value is 5000+ HP. So at low levels, you wouldn't see anything in the bar, as monster HP are less than 50. But if a percentage, the problem is that for tougher monsters, the bar could appear not to change much, given they have so many hp ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Death Penalty, was Re: IRC traffic for Sunday Oct 22
Alex Schultz wrote: Death penalties: -One of the things that bugs players the most I wonder if this is somewhat tied to some of the other points raised elsewhere, where players can die very easily. I have a feeling that if you had to be really stupid to die (have a low level character wander into a high level dungeon), deaths would be less common, and thus the death penalty wouldn't be so much an issue. -Remove them? -A limbo map? -a choice between certain penalties? -Could make them more tangible There are already a fair number of values in the settings file that could control this. I image if you set the death_penalty_percentage to 0, you wouldn't lose exp. I don't see any option to remove the depletion on death, but that would be an easy change to make. I'm not sure what the limbo map gets us. A choice between death penalties is interesting. But then you have to ask what the penalties are. Obvious choices: - exp loss - stat loss - monetary loss - time loss (character/player has to sit a while?) - other? The problem I think is that this is almost the same thing as removing the death penalty - a player at any decent level is going to choose the penalty that doesn't hurt. Eg, at relatively modest level, you can get potions of life, so the stat depletion isn't a big deal (if we change it to actual stat loss, that could be more a deal). If it means the character can't be played for half an hour or something, it means you grab dinner or a snack, or play a different character. The monetary one could be a way to remove money from the game. I do think the losses have to be tied somehow together, something like: 1 exp = 1 platinum = 1 stat point type of thing. Time loss should probably be fixed no matter what the loss. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Map Design, was Re: IRC traffic for Sunday Oct 22
Alex Schultz wrote: Map design: -Are maps designed badly so players can die too suddenly? Some maps are. I don't have any specific maps in mind. And some of this is just the general speed of the game - the fact that a combat takes less than 5 seconds means that death can happen very quickly. The general case of problem maps are those in which you enter already in danger, and don't have a good clue on how dangerous it is before going down the exit. In some cases, in fact, I do a double apply - apply the exit to the map, and immediately hit apply again, so I can quickly see the layout of the map and what is on it and come up with a game plan. But the specific problems are maps you enter, get assaulted by monsters, and are pretty much dead immediately. I don't have a problem with maps that have monsters by the entrance if the difficulty progression is there (for example, if you just had to kill a dragon to get to the exit leading to the map, having an dragon by the entrance wouldn't be unheard of). But many maps have creatures that are much more difficult (or a completely different type, so you may be prepared for a dragon and get a titan) type of thing. -Proposed standard view size -Is it needed? Perhaps LOS should always limit seen distance instead of a hard map size limit. For indoor maps, that is often the case. But it also depends on what the hypothetical target is. I'd say there are not a lot of maps where a 25x25 map will see much more than a 19x19 map (but there are some that do have large open areas). But I'd say there are probably a lot of maps where 19x19 will see quite a bit more than 13x13. 13x13 means you are seeing 6 spaces way from you - even twisty dungeon maps often have straight passages here and there that are longer than 6 spaces. I would say that pretty much every underground map should use darkness code, which does limit visibility quite a bit. However, the player still has an advantage here - shoot an burning hands (or other flame spell) in some direction - that illuminates the area and also kills anything that is there. And I'd say that if things are done so that LOS makes it so that you never see beyond 9 spaces (thus, 19x19), you may as just make that the official map size. I recall the real issue here was what advantage do different players get for different sized maps. At the most basic level, I'd say let players use whatever map size they want. If they decide to play on an 11x11 map, they are making the choice to disadvantage themselves. The problem there, of course, is if some map has some visual clue that is 8 spaces away (pulling a handle operates that gate, etc) that you don't see on an 11x11 map but would on a 17x17 map. (as an aside, there is no way to prevent players from using small maps if they want, because they can always modify the client to show whatever size they want) So the issue really comes to mapmakers. If they want to hide something from the players, they should probably do it via LOS and not by distance (put the lever behind a bend in the wall, etc). But to be honest, I can't recall many issues where this comes up. The few cases where this does sometime come up isn't related to gameplay, but just visual continuity. Some maps have 'views' of the surround area (I'm think the comet quest, where when at the top level, you see the surrounding area). In many cases, those were designed for 11x11 mapview, so if you have a view larger than that, it doesn't look right. But that is in some sense easy to fix - if those are adjusted for 25x25 view, they would never be incorrect. One random musing in this: Dungeons maps are generally limited in size per level for various reasons (performance and monster creation being the main ones), with things like exits/stairs from one level to the next. It'd perhaps be interesting to make a rambling dungeon with map tiling, with monsters getting tougher the deeper you go in. Wonder if the random map code could be changed to make such maps. This would fix the problem you don't know what is about to kill you when you go down an exit - you'd always have a chance to see the monsters at some distance in such a tiled dungeon. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Alex Schultz wrote: Agreed with the reason below, but the problem with that, is that version.h shouldn't append -r unless it has a SVN_REV, and easier to check in defines if SVN_REV is defined at all, instead of checking if it's or not. Because of that, it seems like a better idea to me to leave the SVN_REV check as I suggested, not include svnversion.h in SVN, and make it just make an empty file if it doesn't have a revision. That would be fine. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire protocol cleanup
Brendan Lally wrote: On 10/9/06, Mark Wedel [EMAIL PROTECTED] wrote: - May not be able to use a 2.0 client to play on an older server (depends on how old, and what protocol commands to use). Could still use the 1.x clients of course. Might I suggest then, that when the 2.0 protocol changes are (vaguey) finalised, a version of the 1.x server be released which understands a 2.x version number and acts as though all of the appropriate setup flags were set (without adding any of the new features), and also is aware of any new commands that can be sent to it, but merely ignores them (with suitable draw_info-ed error messages). That way it should be possible to have a compatibility upgrade to the server allowing both sets of clients to work for however long it would be until most distros have upgraded the versions they ship. It's really hard to say how well that will work until all the changes to the protocol are done. And I don't know right now what all those changes may be. There are several potential issues: - Some existing protocol command is removed from the trunk branch, replaced by something else. In this case, it is easy for the client or server to ignore the command, the problem is that if this command has critical information, doing so results in a broken setup. This scenario probably isn't too likely. - An existing command is extended to include values it did not include before. Depending on the direction of the command, this may or may not be easily handled. For example, if the 2.0 server will send some existing values that the 1.x server won't, that probably won't cause any issues for using a 2.0 client on a 1.x server (it can handle those values, would just never get them). A 1.x client on a 2.0 server will have problems - it will get what it sees as bogus data in some commands. The protocol commands are not self documenting, so the best the client can do is just ignore all data after that bogus value (it won't know the size of the bogus data so won't know how much to skip, etc). And if the change is in the C-S direction, then scenario is reversed - 2.0 client on 1.x server would have issues. I think this scenario is fairly likely to occur. - New values are not added, but rather the meaning or type of existing values are changed (something is currently sent as 16 bits, we decide it should be 32 bits, etc). This basically has all the same issues as the point above. So going back to the original point of the post, which was having a 1.x client that could play on 2.0 servers, this is what I would see have to be done: 1) the 1.x client would have to fully understand the 2.0 protocol. anything less, and there is too great a risk of serious functionality be missing or bugs happening, etc. 2) For this to make sense, this 1.x client would have to be released quite a while before 2.0 is released. releasing it 2 weeks before 2.0 wouldn't make sense - at that point, just grab the 2.0 client, etc 3) Such a client would still have to know/be valid on the protocol version numbers. The client itself could change what SC/CS_VERSION it reports to the server based on what the server tells it (basically lie). It would then choose not to do the setup command based on this. 4) To be compatible with 1.x server, basically all the code related to 1.x protocol commands has to be retained. Now as I type all this in, I see a major problem. If we do the above, it basically removes/obsoletes the 2.0/trunk version of the client. If the 1.x client is fully functional with everything, why do you need a 2.0 client? And it then makes other proposed changes more difficult (getting rid of some of the older client interfaces, doing a cleanup, etc). It would pretty much mean that the 1.x client branch would probably have to be maintained pretty for the duration of the 2.0 release. It's easier to remove old clients or support at the major release than later. In short, if when 2.0 comes out, we say you have to use a 2.0 client, people would not their head and say OK. If instead, when 2.0 comes out, you can use a 2.0 or 1.x client, it becomes very difficult when 2.1 comes out to say you can't use that 1.x client anymore (people will ask what has changed, what can be done, make patches, etc). I don't mind this being unofficially supported (can't control that anyways), but I don't want to support it personally. So what probably makes more sense is this: Release a 2.0 client some time (3 months?) before the projected 2.0 server release, to allow time to make it into the various distributions, etc. Maybe call it a beta release. This 2.0 client could only be used on 2.0 servers (likely missing support for 1.x servers). At the time of the client release, the 2.0 protocol version strings are frozen, and any changes made to the protocol have to go back to using the setup commands. This may have other advantages - I'd expect
Re: [crossfire] Improved/redone client.
Kevin R. Bulgrien wrote: I have been giving this extra thought lately, and fired up the gtk2 client. I have to say I do not agree with the statement that the clients are too geeky, but then again, I score high on nerd tests too. At first I thought the gtk2 client tabbed information was cool, but, I still go back to the gtk1 client, again because I can see everything. The fact is, the more information you have at the ready, the better you can shoot the bogey's down. There really is no other way to do battle effectively. The resistances might qualify for hiding, but even they help remind you who not to go up against without checking equipment. Maybe if you are high-level, you never look at those things, but I would not find crossfire nearly as fun without the geek factor of the GTK1 client. Every time I try the GTK2 client I get frustrated at how much is not on screen. That may illustrate some of the problem however. I suspect that if we did a widescale pool, we'd get following results: Everyone would agree that some elements should always be displayed (hp, sp, some others). A mixture of people agreeing what other things should always be displayed. Some would say that ABC should always be displayed, but I don't need DEF. Other saying I really like DEF, but don't care about GHI, etc. And you'll get different input on how that data should be displayed. For example, in the gtk1 client, things like skills and protections are in scrolled windows - some people may find that annoying, etc. I think the best we can hope for is a try to get something that most people would agree on. I don't think we can ever get anything that everyone would agree on (and probably, even in the case of the current clients, everyone has something they'd like done slightly differently). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Here is a screenshot of my gcfclient2, with some comments about where some space optimizations could be implemented: http://wilber.gimp.org/~raphael/crossfire/gcfclient-ui.png I don't think I ever responded to this. But one of your points is that the look/inventory icons are too big. You can already control this - -iconscale command line option, or there is also a space for them in the config windows. Set it to 50, and they are now half the size. Now it may be reasonable to make the default value something other than 100 (maybe 50?) Simply because when the tiles were increased from 24 to 32 pixels a while back, that obviously decreases density. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Alex Schultz wrote: -Less flexibly, as a gtk2 theme with small changes in logic and hacks to make popups have custom title bars and stay within the game view (might involve interesting platform specific code). The second would probably be less work, however IMHO more hackish and more likely to have odd quirks. I'm not sure which I would deem better overall though. Actually, that isn't an issue. Within gtk/x11, there are several placement methods. There is the general I don't care where this window pops up, in which case some window managers let the user place it, other window managers decide for the user where it should go. There is the true pop up, which appears beneath the mouse pointer. Right click within a gnome-terminal and you get this. There is the window created by the application (what we've been calling pop ups, but aren't really). The application can set where these windows should appear, and the window manager will put them there. If the window manager doesn't, it is broken, and not something we can concern ourselves with. A basic example of this is the metaserver window within the gtk2 client. It is set to be centered on the parent, and that is where it shows up. We could do other things within gtk, like align on left edge, etc, if we so wanted. That said, these are still windows, so the window manager to still try to manager them (close the window, move them around by hand, etc). But if players start doing that, that is their decision. In fact, I could actually see that be a bonus for some players. The gtk2 client doesn't support splitwindows anymore, I don't think, but if we had an inventory window, being able to drag it of so it isn't on top of the client could be considered a plus. Well, at least for me it could be, given I run dual screens. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
I'm going to try and summarize the 20+ messages here. 19x19 map size: --- Didn't get many comments, but a few people expressed desire to be able to set this (either because of very small screens, or very large screens). Now scaling of the images (-mapscale already supports this) could be done to compensate for this, but that doesn't look really great. One thought is to at least set a minimum map size (must be set to 17x17 or something) so that map designers could know that a player can see 8 spaces away from them. Yes, people playing on a 25x25 display have an advantage, but so do those with faster connections, etc. I would also be inclined to require on display dimensions, so that the player is always in the center of the screen, not off by a tile. making client fullscreen: - General consensus seems to be no on this point. I don't think I saw anyone that actually said they would use full screen, and to me, that is a red flag right there (if no developer is using it, no one will find bugs, etc). But more so, I think it is that in a linux environment, people are not expecting full screen apps. Full screen could allow custom widgets, but some dislike expressed on that. And I do think that is a valid point - being able to use GTK2 makes coding a lot simpler/faster. There is a reason that the gtk clients have a lot more features/abilities than the X11 client, which isn't using any widgets and thus has to have the widgets it does have done by hand. standardize on one client (gtk2): - Generally OK, but gtk2 client would need to work better on low resolution displays. At lease some people are still using 1024x768, which has more space issues. My thought might be to make a different glade layout file for lower resolution, which also chooses some other defaults Client ui improvements: --- - pop up window for inventory handling: Mixed reviews on this one. It could be that some sort of compromise/hybrid be done. My thought: Have a pop up window for in town use, etc, which could present a lot more items or data than currently provided. Within that, allow for some custom filters or favorite items, and have tabs (in the main window) for those, and have those in a smaller inventory area. So while in a dungeon, you can easily get to the items you need (more easily in fact, because they would be the only thing in particular tabs), but in town, can do everything you need to do. The look window would always be active like it is now (but when the popup is in use, maybe have that data replicated in the popup also to make it easier to access stuff) - add theme support: No real issues, as long as the ability to keep default theme is allowed (it would be). My thought is to handle this like firefox and lots of other apps do - you can use the system theme, but it may have various custom themes which could make it appear more 'gamey' - display important info: Figuring out what is important is hard. Generally, it seems that protections and skills (both) is important, general stats less so. Maybe should investigate to see if we could display both of those in one tab. Overall exp displayed should be added to the scrollbar stats window (sp/hp/grace/food), with the scrollbar representing percentage to next level. For exp values, maybe in the 'compact' list, display the last 5 (or X, where X is not a really large number) of skills that have gained exp? Thus, while in the dungeon, you'd see your combat skills in that window, and could track progress, and in town, you'd see your town based skills. Range attack is also listed as an important to know item. Also suggested that within the protections themselves, that maybe they go red/green for some amount of time when they change, making it easier to see when a spell expires. Could be used for all values that change. Text messages are always an issue. Other than the space used, I don't think the way the gtk2 client does it now is bad. I'm not sure that writing them over the map area would be useful - crossfire generates so many text messages, I think you'd always be bringing up the console to see what you missed, so having the console (text area) always up probably makes more sense. - improved help - should be done, now to just do it. - Improved key binding - should removed duplicate keybindings (or present warning). Also, should have some method of different key binding profiles, so you could load up the mage vs fighter profile (or maybe the dungeon vs town profile). If loading different keybindings can be done by a keybinding itself, this would be doable. In addition, more data on how the keybindings work should be added. - background music should be added. - Better magic map handling (colored dots like cf+?) I had also thought that instead of sending colors, maybe magic map
Re: [crossfire] SVN revions in version
Alex Schultz wrote: A few times, tracking the svn revision instead of the $Id strings has been brought up. IMHO this should be done, both in the client and server. I propose we implement it as follows in both: Create a version.h file containing something like: #include svnversion.h #define BASE_VERSION 2.0.0-dev It should actually get that version number from autoconf, like it does now. Then as part of that, for official releases, the -dev tag can be removed from configure.ac In release tarballs, the -dev postfix to BASE_VERSION will be removed and it will be adjusted to ignore SVN_REV. Then have a defaultly blank svnversion.h file, which the building process will create simply in the form of: #define SVN_REV 5678 The ./configure stage will check for the presence of .svn and the svnversion command, while the build process will run svnversion. The check for .svn would be better done in the makefile. configure can check for svnversion. In addition, if the makefile doesn't find a .svn directory, or does not find svnversion, it should create a svnversion.h file with an empty SVN_REV, eg: #define SVN_REV To the best of my knowledge, there isn't really any way to include a file if it exists, don't include it if it doesn't. So it is just a lot simpler to always include it. You really don't want the svnversion.h file to be any part of SVN, because otherwise people will accidentally check it in and now have a version number that isn't correct. The build process running svnversion because not all revisions require ./configure to be re-run. Also, it will only write svnversion.h if a check shows that it was checked out from official crossfire svn, this is to ensure all revision numbers correspond to the same repository. I think checking for official repository checkout is probably overkill and isn't needed. After all, if a developer really wants to have a bogus SVN_REV number, there are a lot easier ways to do it. This version would both be used in the client for outputing to the console instead of the rcs-id values, and the server will use this version for reporting to the metaserver as well as console output. Does this model make sense to everyone? That sounds fine to me. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Brendan Lally wrote: I'm not sure it is such a great idea to send the revision number to the metaserver, certainly not if the metaserver is going to push that information out to clients, in that case, someone who wished to be annoying could look for servers with revisions predating certain bug fixes or balance tweaks and abuse or exploit them. OTOH, this really isn't much different than right now. Server xyz is running 1.9.0, which doesn't have some bug fix in 1.9.1, etc. At some level, it becomes security through obscurity. And if we believe that 2.0 will take quite a while to finally get out and release, and that some servers may start running 2.0 for testing purposes, they may very well want to advertise their version. Of course, that is all up to the server - as far as the metaserver protocol is concerned, it is just a text string, so doesn't care what is in it (I could modify a server right now to claim it is version 2.5 for example). If you are talking about sending the revision as a seperate field to the metaserver, that isn't for propagation to clients. then that is a different issue altogether, and could provide useful information about things like how quickly updates are made available in practice. Current metaserver protocol doesn't really support more fields. It wouldn't be hard to add. There was some discussion in the past about a new metaserver layout - that is a different discussion, but could be worth revisiting. Likewise, although the clients need only open a connection to the metaserver to recieve the server list, having the official clients send their revision numbers by default would give some indication as to which versions of the clients are in use. (assuming the metaserver were suitably modified to read that information from the socket). See note above. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Alex Schultz wrote: Brendan Lally wrote: I'm not sure it is such a great idea to send the revision number to the metaserver, certainly not if the metaserver is going to push that information out to clients, in that case, someone who wished to be annoying could look for servers with revisions predating certain bug fixes or balance tweaks and abuse or exploit them. Hmm, well I guess that is somewhat of an issue. What about having ./configure time option to make it very easy for server admins to decide if they want the revision number included in the version string sent to the metaserver? It should be a settings option, not a configure option. Putting it in the settings makes it a lot easier all around. configure options should really only be used for things that need a recompile to take affect (libraries, compiled in options, etc). It shouldn't be used for things that are easy to control at run time. It would also be pretty annoying to loose such a change because you re-run configure without specifying all the same options. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Christian Hujer wrote: On Friday 13 October 2006 19:15 Brendan Lally wrote: Likewise, although the clients need only open a connection to the metaserver to recieve the server list, having the official clients send their revision numbers by default would give some indication as to which versions of the clients are in use. (assuming the metaserver were suitably modified to read that information from the socket). Oh that would make it easy for a bogus server to abuse or exploit known client bugs to hack client machines. Well, right now, the client does support some basic information to the server when it connections (type of client, its last official version (1.9.0, 1.9.1, etc). Since generally speaking, there isn't any real way to fix old clients (if someone is still using 1.8.0 client, making a patch for known bugs to that client isn't likely to help, as most likely, person isn't going to get it updated), there could already be a pretty large list of exploits. Things like 'if client is older than 1.9.1, these bugs exist which I could exploit'. Whether the server knows the SVN number or not probably won't make a big difference. However, I do agree, there really isn't much reason for the server to know the SVN number. What would be more interesting, from a data collection standpoint, is knowing the number of people that are actually compiling out of SVN vs using officially downloaded clients. I'm not sure what I would do with that knowledge, other than to say 'hmm, interesting, x% of players get there client from SVN'. Related to that could be precompiled vs non precompiled clients somehow reporting that. However, that really is more dangerous. If a server admin was going to try to hijack a client, using a precompiled client is the way to do it. Any 'compile it yourself' client has so many variables (compiler options, version of the compiler, type of system it is compiled on) to make most all exploit bugs (typically buffer overflows) virtually impossible. However, if the developer can download the same client that players are using (precompiled), they can play around with the exploit, write the code that properly hijacks it, etc with a high level of success (different versions of some of the libraries may make a difference). So if anything, not having clients report their version doesn't make it harder for server admins, they just can't know who to target. And if the 'fixed' clients have some form of reporting (server abc sending bogus data that looks to be trying to exploit bug abc), and the server can't know which of those clients might report, that may make it so that the server admin won't try it. I would say that any server that is trying to do such things should be blacklisted from the metaserver (and potentially reported to the service provider). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Food consumption
Kevin R. Bulgrien wrote: Mark Wedel wrote: Kevin R. Bulgrien wrote: I am running an x86_64 test server with an Opteron processor. Food consumption seems unreal... I never played Gaea before... That's what's doing it. Regeneration +2... Man, I need to carry a refrigerator around with me... :-) A separate discussion could perhaps be change food consumption rate. High food consumption just means you carry around lots of food - not much other affect. Hmmm... Well, food beep seems to not be working again... Lately I have been working on maps with my client up and running, and have died quite a few times due to starvation because the warning seems to not work anymore. It has been patched ages ago, but I guess something has broken it again. Looking at the code, I don't see anything odd with the foodbeep code. Also, the poor halfling cannot carry very much weight, so has to resort o eating carcasses... blech... in a dungeon crawl. He is not nearly high enough level to have create food, town portal, and the like. Not complaining here so much as saying its not quite as simple as carrying lots of food. IIRC, carrying capacity is directly related to strength. Of course, halflings have a strength penalty, so that doesn't help. I don't think that is true. The 3-1 rates mentioned in the original post were standing around doing nothing. That's what limits you. Now, is it more real? Probably, but it isn't scaled well with the other characters. Which is maybe a decent question - the regen rate for Gaea is seen as an advantage. I don't know if the high food consumption rate was factored in as a disadvantage, or is an unintended side effect. And in some sense, having it as a granted ability from Gaea is a disadvantage, in that you can't turn it off. For other character, you can just take off the ring of regeneration and be back to normal food consumption. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Alex Schultz wrote: -If you try to make a keybinding over a key that is already bound something, it shouldn't just append to the list, it should warn you and if you choose to continue, remove the old binding first. Yes - that is a valid point - overbinding a key doesn't make sense. But it gets a little odd with modifiers. -One idea that might be good, is while it is waiting for you to press a key to bind to, it should come up with a graphical display of the keys on the keyboard, and with color coding showing which keys are already bound. Tooltips when hovering over a key show what is bound there and clicking a key counts as if you pressed that key. I don't know if there is a widget for that or not. That is not something I'd want to have to write ourselves. We just can have a universal looking keyboard - after all, laptops, different keyboards, etc, can have different layouts. Inventory control via keyboard: I'd be interested in how people think that should work - I really can't envision much any reasonable way to control the inventory only by keyboard, whether we use gtk2 widget or write our own. I'd personally consider this to be a pretty low thing to do. Personally I think this would make a big improvement if it could be pulled off in a reasonable manner. The best I've seen for keyboard inventory control in large inventories, would be how nethack does it even in it's gtk interface. That keyboard interface might work well if we used popups, however see the popup issues above. One could do something though with giving focus the inventory list and allowing keyboard scrolling of it and pressing keys to apply from it or drop etc. however one would need to make it VERY obvious to the player when they have focus on that, and also would have to make it very difficult to accidentally trigger while easy to trigger manually (and for fairly obvious reason I don't think focus on click would work well for it...) A valid question may be whether the inventory interface should be completely redone. The mouse buttons I believe kept what was used in the old X11 client. I don't think the current button presses conform to what people would expect from a GTK application. I'd say that a single button press being the expected behavior is not standard. What comes to mind could be something like this: Left click selects an item. A double click applies the item (most common operation). Double middle click drops item (second most common operation?) Right clicking on a selected item brings up a little pop up menu on additional item actions (drop, lock, apply, examine, mark, etc). I think that is better than having these odd shift and control combos. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
A nice thing would be to have a generic client, with an interface layer. This way we could apply different interfaces while retaining a common layer. Think something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest to use that language for the interface). Maybe with a widget system? Let users write (in Python? LUA?) their own displaying widget to display game information? The problem/complication is that at some level, the UI becomes a pretty major portion of the code. And it probably makes more sense to spend our time to just get a good, thorough working client with (for lack of better term) hardcoded toolkits and not have some scripting writing language that no one really uses. Now an intersting side point to this is that the gtk2 client uses glade for all the layout. In theory, someone could write a new glade file/description, and as long as all the widgets remain the same, could just be dropped in place. This in fact may be the thing to do relative to high and low resolution clients - rather than trying to have layout to cover everything, having two glade files might not be that unreasonable. Now I do think the current code may need some additional work. In such a model, I could certainly see some versions not implementing all the widgets (for space reasons, whatever else). That can easily enough be handled I think in the code to make sure the widget isn't null, but that checking isn't there right now. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Quick note - the client reorganization/cleanup/entire discussion is aimed at the 2.0 branch. I don't really forsee many of things things going into the 1.x client. Will try to quickly catch up with all the issues at once : Keybind profiles: I think that is doable, and makes sense (keybinding for a spellcaster vs non spellcaster is quite a bit different). From what was described, it sounds like there would be two keybinding profiles in use at any time - the common set, and then the specialized one for the given character type. That gets more complicated, because if you add a new binding, have to record where it goes (specialized binding or general one). It certainly wouldn't be hard to have an option on what keybinding profile to use. OTOH, presumably players would want this somewhat intelligent (if I play character X, use this binding, if I player character Y, use that binding), but probably don't want one binding selection per character. And even keying on character names may not be good, as different types of characters with the same name could be played on different server. Keybinding interface: I don't think anyone mentioned this, but I know people have said they don't like the current interface in the gtk2 client (which is really the same as the one in the gtk client). Not positive how to improve it - it seems with the number of spells, etc, we're always going to have a lot of keybindings in crossfire, but would be interested in hearing ideas. GTK2 client resolution: Yes, it is/was aimed at higher resolution screens. One reason was there is lots of buggy/complicated code in the gtk1 client to try and adjust based on window size, etc, and I want to avoid that complication in the gtk2 client. And at some level, I think that making changes to layout based on screen resolution has other disadvantages (it's hard to optimize for both low and high resolutions, which is one problem I had with the gtk1 client - fine on moderate resolution systems, but not very good on high res). I'm not sure the perfect solution here, but perhaps designing a layout for 1024x768 and seeing how it works might be a good start. The doc that says I won't take patches for lower resolution is not accurate. Containers: How to handle them can always be a bit of pain. I never thought it opening on the ground beneath the player was very intuitive (and would then create odd issues like you can't get to objects on the ground with an open container, etc). A quick fix for closing containers in the inventory is a 'close all containers' button could be added to the top of the inventory area. Quick item handling: In the ideal world, the client should be able to support some better form of filtering, perhaps even having like a 'favorites' tab which only shows items marked as your favorite (in this way, you could put all your items that you frequently apply there). Some games have the 'paper doll' type interface - I think that could still be a good idea for equipping, but I'm not sure if it is good during general purpose play (I can't think where that would fit in the client) Map size: The 19x19 was to make that the only supported map dimension as far as protocol/setup is concerned for viewable player map. The game map files won't change. And the client could of course have a larger visible map, but just wouldn't get data from the server for it, so its only use would be to use that for fog of war. I tend to think that letting the player select map size doesn't have much in the way of downside (yes, some players may get more information, but that hasn't seemed to have been a big problem in the past) Fullscreen client: The reason I don't think changing resolutions should be a method is because I don't think that will be very well supported. There is no guarantee what resolutions the system may support. I can certainly see people with LCD only having 1 valid resolution defined (native resolution of the screen). And you get the complication of widescreen (its not 1280x1024, but 1280x800). So you're now in a case where you may still need to support several resolutions. The other problem is that the client has to be more bulletproof to change the resolution back to the original when done. But the interesting point about fullscreen client, is that while several people say it may be useful, I don't think I've seen anyone actually say that is what they would use (they would use windowed mode). Which to me sort of suggests that this isn't something really worth pursuing - we're trying to guess what other people want. Pop up inventory window: I'm perhaps seeing this more as a secondary interface to the inventory, not the only way. So the existing scrollbar exists, but when dealing with lots of store, or perhaps more advanced operations, a pop up window could provide a better interface. OTOH, having two different interfaces would seem confusing.
Re: [crossfire] msg/endmsg in maps/objects
Kevin R. Bulgrien wrote: Mark Wedel wrote: Kevin R. Bulgrien wrote: Mark Wedel wrote: Ideally, I think most of the newlines from the msg/endmsg structures should be removed - the client is plenty smart enough to do proper wrapping. There are also a few messages which should have the '[fixed]' tag added, since they are maps or diagrams, and just don't look right when printed with the proportional font. BTW, not sure what proper wrapping means. In gcfclient, it mercilessly chops the text to fit the window. Word boundaries are not honored. The gtk2 client handles word wrapping properly. It turns out, blank lines are stripped. I don't know how to add blank lines. This is can be problematic when you use split windows because, for example, if you walk down the main drag in scorn reading all the signs, all the output is just strung in sequence with no separation between signs or headings. It is pretty hard to scroll back and see what happened, and, it is hard for any given message to be well formatted so that paragraphs are separated nicely. Does anyone know how to output a blank line in message text? I tried \n, but it does not seem to work. The gtk2 client seems to also handle this just fine. I'm not positive where the issue is in the gtk client. I know for the word wrapping, it is left to the widget to do the wrapping, and it instead just chops the lines - I'd think that there is probably an option there someplace to have it wrap, but it is also using a deprecated (relative to gtk 2.0) widget. mediaTags seem to be of limited usefulness, or are broken. The following DOES NOT work... The tags are output as text, at least in the GTK 1 client. The tags appear to be applicable only for cases where server code writes to the client, but not when that text is extracted from an arch msg block. I'm in the process of updating all the code in the server to do the right thing in this regard. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] HallOfSelection in crossfire 2.0
Alex Schultz wrote: It's not a big thing, just a little detail, but it's a fun thing. I'm thinking that the top section of the HallOfSelection that's displayed when players are logging in, should have some cosmetic changes in the trunk (2.0 branch). It would be nice if to make it so what was displayed there would be something that would make players think something like Ooh, this looks shiny when they first see it, and when seeing in the future, can at the slightest glance be like Neat, a 2.0 server. I'm thinking that it would be neat to use either movers or the cfanim plugin to make an interesting animation for it. Anyone have any comments on this simple but fun idea? :) The way I see/envision things, the hall of selection map will just go away. This is because there will be another method of character creation that does not involve moving a character around a map to choose race, etc. So the question then becomes what should be displayed. There is the current issue now that when you first run the client, nothing at all (or just the generic crossfire icon) is displayed - and this is displayed at the metaserver selection window, etc. It'd just be nice to have something better to display then, vs just some big black empty area. The easiest thing, IMO, is to have some static image of good size (png or the like) that is displayed in that window. Given this doesn't have to be a map, it could really be anything, but probably easiest to have some map like form (that represents what the game looks like to some extent), maybe with lettering and the like overdrawn (Crossfire 2.0 or something). The follow up question is then: Should the server provide an updated/different image while receiving the player name/password, or just use that one in the client? From a practical matter, I don't think there is anything prevent arbitrary images from being in the arch directory, and thus served to the client. so a large image could exist in the arch tree, and through some basic negotiation at startup, the client could figure out what the image is, download it, and display it. OTOH, I'm not sure the likelihood of different servers going to the work of customizing that image, and most players will log in relatively quickly so probably wouldn't notice any difference, but who knows. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Removal of output-count/output-sync from server
Yes, I use it too to control how much garbage scrolls by in my client. Please don't remove that until there is a replacement in the client. Gene Alexander Ok - followup question this: the current implementation in the server has several buffers that it uses to store/track different messages. What this means is if you have messages like: you hit orc you hit orc hard you hit orc hard you hit orc you hit orc ... They get compressed into something like: 3 times you hit orc 2 times you hit orc hard and so on. Is that extra logic still needed, or is it sufficient to just track the last message an print repeat counts? I'm thinking that if this is most often just used for things like search locks or other repeated checks, just buffering/repeating the last message would be sufficient, and is certainly a bit simpler to do. The disadvantage is that if there is a bunch of other messages being generated as you search for traps (say your suffering from poisoning), that would cause the search messages to get broken up, etc. Thoughts? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire protocol cleanup
Please note that everything discussed in this message only pertains to the targetted 2.0 release of crossfire, which is in the trunk. Changes won't be made to the 1.x branch. It has been noted that within both the client and server, there is a fair amount of old code around to support older versions of the servers and older versions of the client. The setup command has also gotten a lot of options with methods to negotiate what protocol commands it supports, and directly related to that, there is a lot of code in the server that does/does not do something based on what has been negotiated. The idea here is to clean all that up for 2.0. Specifically: - Change the SC_VERSION and CS_VERSION to 2000, to represent 2.0 release. - server and client must have some version to work correctly - mismatched versions may or may not work (client may get data it doesn't understand, server may get client commands it is unable to process) - Version 2.0 compliance means that the client supports the latest implementation of the protocol. Support for superceded protocol commands is removed from both server and client. - Version 2.0 compliance also means that the client supports all the relevant items within the setup command, so that doesn't need to be negotiated (spell info, 64 bit exp values, whatever, so those are not needed in the setup command. Note that there will still be some things done via setup, like faceset, map size, etc - things that are actual preferences, and not protocol selection info. - While 2.0 is in development, any updates/changes to the protocol will result in updating the SC/CS version numbers, and not done via setup. This may mean people need to update their client to play on their test server, but since this is while doing development, I don't think that is unreasonable. - Once 2.0 does release, then any changes to protocol would go back to being enabled via setup commands like done now. - If/when alphas/betas for 2.0 are done, both a client and server release snapshot is done, so no issue with version commands. Pros for doing this: - Helps in code cleanup (get rid of old code) - Enables more rapid code development (easier to make protocol changes, and can remove obsolete code at time new code is added). Note: This doesn't remove the need for discussion on protocol changes - Simplifies protocol, make it clearer what new developers should program to. Cons: - Need 2.0 client to play on 2.0 server (would probably be a requirement at some point anyways) - May not be able to use a 2.0 client to play on an older server (depends on how old, and what protocol commands to use). Could still use the 1.x clients of course. - Developers would need to keep their client and server in sync to play, given requirement of equal protocol versions (may not be that big a deal - I'm not sure how often the protocol will change, and doing svn updates shouldn't be that hard) thoughts? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Improved/redone client.
One of those perennial items on the TODO is an improved client interface. Unfortunately, seldom are good details provided. I had a discussion with a few people on irc a little while back on this, and some ideas where exchanged. Note that this is likely far from a complete list: == Standardize on 19x19 map size. This size was chosen as that the map could still fully fit on lower resolution systems. Standard size so that map makers know what to design to, and so players don't have an unfair advantage (if I have a 25x25 map and you only have 19x19, I have more info). To me, the idea seems reasonable. Having a single map size to supports certainly makes programming easier. As a user of high resolution displays, that would seem to leave the map a bit small to me (it has been suggested to make a 'large sized' image set with 64x64 tiles, but that is probably a separate discussion). It maybe that resizing the images on hi-res systems to be larger is the way to go, or the client displays fog info in the extra space it has. == Make client fullscreen. Reasoning here is that most games run in fullscreen mode, so it becomes more like most games. It can also ensure that other applications are not grabbing keystrokes/button presses (eg, window manager, etc), so if we tell the player to press a key, we can know for sure that if the player presses that key, the client gets it. For lots of reasons, would still need to support a windowed mode of operation. My thoughts: I personally find fullscreen applications annoying, so would also use the window mode (I think most people using unix don't expect full screen apps). While we can run fullscreen, I don't think we can or should attempt to switch resolution. This does then mean that client could be asked to run at odd dimensions. I think this issue needs to be investigated further - it may be possible to make the pointer captive in a non full screen window. I also think that if we do full screen window, it needs to be pretty clear how to get out of it (nothing more annoying than an app taking over your system) == Standardize on one client Doesn't make sense to be supporting 3 clients in the current client distribution alone, plus a few others hanging around out there. This is just more work when a bug/issue shows up (may need to be fixed in all 3, or maybe only shows up in one client, requiring digging in there, etc). So in the trunk, should just use the gtk2 client, and get rid of the x11 and gtk1 client (note, they would still exist in the 1.x branch). Related to this, SDL mode in gtk2 client should probably just go away (opengl will give us the features we need long term) My thoughts: As the writer and user of the gtk2 client, I'm biased, but keeping the gtk2 clients seems fine to me. I know there are complaints about it, as well as bugs, but having 3 supported clients I don't think really helps things much (it becomes too easy to just not make improvements or fix bugs and keep using the gtk1 client). It may also be that a completely new client should be written (see point below) so that the gtk2 client goes away. But whatever is done, I think going forward, it certainly makes the most sense to only officially support one client (people could unofficially continue to support the x11 client, but in that case, the developers making changes to the protocol or official client wouldn't have to update it, just like the unofficial clients out there now) Better UI interface == Improve client UI This is often discussed, but I hear few concrete suggestions. I'll be the first to admit I'm not wholly satisfied with the gtk2 client. Yet at the same time, I'm not exactly sure what I'd change to make it better. Here are various thoughts and some suggestions I think people presented: - Pop up window for inventory handling (one gets so many items in crossfire, that the normal scrolled area really isn't sufficient) - Maybe use themes to make the appearance more that of a game and less that of an application (font size, background colors, etc) - Figure out what information is important to display, and what isn't. In particular, I'm thinking of the stats pane here - most often I use the exp pane to see where I am at relative to leveling, less so the resistances, and seldom use the overall stats one, since stats don't change very often. Could we maybe use icons instead of string names, and scrollbars instead of numbers to represent progress? Add popup hints so if you hover over the value, you get the full info? - Improved help - I don't think the help in the client has much useful content - I think a lot of the information currently in various places could make it to the client so it has a real help system. === Thoughts/comments? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Food consumption
Kevin R. Bulgrien wrote: I am running an x86_64 test server with an Opteron processor. Food consumption seems unreal. Does anyone know what factors determine the rate of food loss? Speed is 0.90 (3.03). The character is a halfling. Food seems to click down a notch every second. On metalforge, food ticks down about 1 notch per 3 seconds with speed being up like 3.0+ (?) - not wearing any sustenance items. It wouldn't happen to be based on some platform dependent thingamabobber would it? Kevin I never played Gaea before... That's what's doing it. Regeneration +2... Man, I need to carry a refrigerator around with me... :-) A separate discussion could perhaps be change food consumption rate. High food consumption just means you carry around lots of food - not much other affect. The food consumption probably dates all the way to back when crossfire was more of a gauntlet clone (old arcane game). Most adventure games tend to have fairly low food needs (some games don't even have good). Another thing that affects food consumption - each time you regenerate an HP or SP, you lose a food point. Thus, if you are decent level and have high regen, you're food can go down really fast. If you are fully healed, a high regen rate doesn't affect food consumption that much I think. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buffer flooding
Alex Schultz wrote: To my understanding, buffer flooding occurs on the server side, not the client side. One simple fix could be done client side however; One could make the client ignore key-repeats, getting rid of the command buffer issues caused by holding the key down. When using crossfire, I can't think of a time I actually make use of key repeating (using running for example doesn't rely on key repeating, just on holding the run key down) That could be reasonable. OTOH, I'm not sure if new players, before they realize about the run feature, may hold down direction keys. Also, IMHO the command buffer needs some redoing anyways: Paralysis is currently implemented simply as not processing the command buffer, with which I believe there are a few issues. For one, I believe it would make sense for some types of commands such as communication commands, possibly other than say, to ignore paralysis. Also, it might be a good idea to instead of buffer actions while paralyzed, to just ignore them. Yes, the command handling on the server could be redone. In the ideal case, it works something like this: 1) Read all pending commands from the client. Commands that are considered free can be executed (free commands could be administrative stuff, like maps, player communication commands, so forth). One such free command could be 'cancel all commands before this' type of thing. 2) The commands read are stored into a pending command buffer (maybe a linked list). If the player does not have time to execute non free commands, nothing more is done. 3) If the player does have time to execute commands, run the first command on the list, remove it, and repeat 4) Possible enhancement: Add some form of priority tagging to commands (number? Just a single flag?) In this way, that 'drink healing potion' command could be a priority command, which is run before the other pending commands, no matter where it shows up. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] useful macros in crossfire
Alex Schultz wrote:
Often when looking through code, I notice that that many code snippets
are repeated in many places, often with variations on how to do the same
task. The best example is iterating through stacks of objects, because
loops for that are implemented in many different places, with quite a
few needless variations. Another example is if ob-head ob=ob-head;
while not complex, might be more readable as something like ob =
GET_HEAD(ob);. I propose that we add the following macros or similar to
the crossfire code to make things cleaner:
Generally speaking, just because the code is repeated, it isn't necessarily
bad if the the expanded code isn't very long, is clear to understand, and is
unlikely to need global replacement because of some other change in the the
code.
OTOH, I'm pretty use to the code, so when I see most of those operations, it
is pretty clear to me what it is doing.
I'm more inclined to accept the GET_.. ones than the TRANSVERSE ones. They
seem cleaner - maybe it is just me, but having something like:
TRANSVERSE_INV() {
}
seem a bit more confusing to me, as it is actually hiding the operation from
you, which may be relevant depending on what you do in that inner loop. That
could perhaps be improved by calling them something like FOREACH, which better
describes what it is doing.
But also, I think that several of the TRANSVERSE macros as is will have
problems, as I know there is code like:
for (tmp=ob-inv; tmp next; tmp=next ) {
next = tmp-below
}
Because depending on operations, you can't rely on tmp-below to be accurate
after doing remove_ob or insert_ob calls. This is true for both inventory and
map loops. So that now needs another set of macros to take that third object
pointer.
To me, going through the code and updating all those code snippets would be
near the bottom of the list of things to do, given the fairly long TODO list
that there currently is (and given that the this doesn't effectively change the
operation of any of the code, it just changes how it looks). But making the
macros available and used in new code may not be a bad thing.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] msg/endmsg in maps/objects
Kevin R. Bulgrien wrote: Mark Wedel wrote: On a broader scale, there is a problem with most of the msg/endmsg in maps/objects. They are pre-formatted for a certain width. If your text window is wider, it isn't terrible - it just doesn't use the full width. If your window is a bit smaller, it gets really ugly, as it will display a full line, then perhaps 1 word, then another full line, etc. Ideally, I think most of the newlines from the msg/endmsg structures should be removed - the client is plenty smart enough to do proper wrapping. There are also a few messages which should have the '[fixed]' tag added, since they are maps or diagrams, and just don't look right when printed with the proportional font. I have been wondering about this for some time. I agree the formatting needs to go in general. The formatting is not consistent and so one never knows how to format or reformat content. It is good to know that it is okay to string the paragraphs on the same line. Most newlines is right, considering that some should be left in order to separate paragraphs and/or allow certain lines of text to be rendered on a line by itself. I'd ask also for some clarification of whether there is a common practice to follow with respect to whitespace between sentences. There is a variation in that one space is used much of the time, but two spaces also exists. I'd be tempted to say that for simplicity, we use whatever is most prevalent right now. So if the most prevalent is 1 space after the period, that is what we should use. I'm not sure if it is worth it to go through all the maps and update just for that. But if doing it as part of a newline conversion, etc it could make sense to fix those. And a lot of these changes also need to be made in the server, in terms of the messages it prints. In cases where there are several draw_infos() strung together, in many cases I've been changing that to just one draw_info on the basis to let the client wrap the text. In some cases, this doesn't work because there is specific formatting, but not that often. How about blank lines? Is this discouraged in order to consume less vertical space, or is it seen to be acceptable for improving readability for longer multi-paragraph output? I'd say they should be there for readability. Without a blank line, it can be very difficult to really see where the paragraph breaks are. In addition, this really only comes up with NPC messages - generally, I'd say those are a relatively small portion of the total text output (things like attack messages being much more prevalant), and I can't imagine a couple extra newlines being that big a deal. Is there an advantage to using leading whitespace acceptable to inset example text? I think so, but wonder what others might think. Depends on what you mean by example text. Also, look at the server/doc/mediaTags file - it supports a limited number of HTML like tags. What this really means is that within a message itself, you can change various attributes (like make the text italic, or change the color, use fixed width fonts, etc). Using those tags is probably better than using indentation. Is there a document anywhere that might be used to help map editors know how to write these messages? If not, a wiki page might be in order. These topics are of special interest to me since I have an interest in working on grammatical, spelling, and conversation improvements on maps as I play them. I don't think there is a document on indentation, punctuation, etc. So one should probably be written. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] draw_ext_info/message update/redo
Andrew Fuchs wrote: On 9/24/06, Mark Wedel [EMAIL PROTECTED] wrote: ... The main advantages I see of the drawextinfo is this: - Support for the media tags (bold text, different fonts, etc). I'd expect these to be infrequently used, as in general the global tag/attribute should be used. But I think use in NPC messages giving clues what can be discussed with them by doing bold or underline would be very good (we should probalby decide what the form for that syntax highlighting it is, so that it is consistent accross all the maps/NPCs) Or we could make a new tag like [triggerword]. The server then could decide on it's formatting. Also, if it is passed to the client, the client could make the hilighted phrase clickable. That could be reasonable. However, I think that should just get passed to the client, and the client decides what to do with it, not the server. My general philosophy is to try to offload those decisions/that work to the client - in a sense, we should try not to hold preferences on the server unless they are a per character type of issue. And if passed to the client, it could of course make it clickable (just generated the appropriate say command). A possible interesting extension could be something like [img=sword.111] or the like. The image itself being one of the images in the arch directory. Then you actually could have pictures of monsters with the scroll that describes them, etc. And from a more complex level, you could actually have real maps to places, not the ascii maps. The map would have to be put in the arch tree, and a the images collected, but that is certainly better than anything we have now. - Instead of the server telling the client the color to use and the client blindly following it, the client now knows the type of messages. So with some extra logic, I could decide that I want the level gain message to be in a specific font in bright green, even though the server says those should be in red. It would also allow for easier filtering (if chat/say/shout have their own types, easier to have a conversation pane, etc). Very useful in my opinion. I really like the colors that me chats: uses. Though that could be considered a bug. To me, the filter/font is less desirable than the filtering. With this change, it will now be possible to really have a tab just for chat related messages, etc. I think to actually be able to set colors/fonts, we may need to trim down the number of subtypes, and/or make some common values. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN notes/thoughts
Been a few days since we moved to SVN. With the transition, there are some changes that can be made. One point is automatically rebuilding the archetypes when the arch tree changes. My thought here is that lib/Makefile can run svnversion and puts that in a state file (.collect.svn.new). Then, the process compares that file with the old one (.collect.svn) - if different, it runs the collect and moves the file over. If the same, it just doesn't do anything. In this way, a collect would automatically be done whenever the archetypes are updated. One minor issues is that svnversion reports the version the respective tree is updated to. Given that all of crossfire is in the same crossfire repository, you do get the case where the number of svnversion can be different, but for the actual component, there haven't been any changes made. This is because svnversion returns the version that the tree is at, relative to last update. Real life example below: [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (591) % svnversion . 4963 [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (592) % svn update At revision 4969. [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (593) % svnversion . As you can see, there were no changes in the arch tree relative to the versions, yet svnversion returns a different value. What this really means is that such a method would result in archetypes being recollected more often than strictly necessary. OTOH, unless you update the arch tree, this isn't an issue. I think similar logic could also be used to embed the version number into the client and server binaries. That way, when someone reports a bug, it is very clear what version they are running. By using a state file, it means we don't need to recompile and relink everytime (if we just used svnversion to blindly write a .c/.h file, then everytime it would recompile and relink that component). In both of these cases, we also need to handle the case for the official releases, where there will not be any SVN information in the downloaded source code, and the user may not even have svn tools installed. Configure can easily enough be updated to look for svnversion to cover that case. In the case of lacking the svn data itself, I'd think the makefiles could just check for .svn files - I'd rather not have to reconstruct the makefiles for the official versions. In terms of the version string, I think the file that inclues it would have to be part of the distributed version so that it is there for the compiled in. Including the SVN version in officially released distributions shouldn't cause any problems IMO. thoughts/comments? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects.
Alex Schultz wrote: Andrew Fuchs wrote: There are several instances in the maps, where custom objects where copied and pasted from other maps. An example to this is the guidebooks in the post offices. Recently the guide books in Scorn's post office where modified, but not the ones in other post offices. This lead me to think about what requirements have to be met for it to become practical to replace duplicated custom objects with new archetypes. Seems like a good idea to me. I'm thinking that having two or more of similar objects that appear on separate maps would be enough warrant a new archetype. I don't think that's good criteria, for one, what about floors set to no_magic? IMHO that isn't worth making new archetypes for. (However perhaps the editor should give an option to automatically set no_magic when placing floors? but that's another matter.). We would need to define how different the archetype would need to be from it's original arch, to trigger the map check warning. IMHO some good criteria would be highly similar objects being used on two or more maps, and at these criteria scoring at least 5: Score Criteria 4 Objects have the same message, which is over 10 characters long and different than the archetype. 2 Objects have same name, which is different than the archetype. 1 Objects have the same in some other attribute, different than the archetype Or perhaps something similar to that table. In any case it seems we would need some sort of scoring system for how similar objects are, and how different from the archetype they are. I agree it gets complicated. Keep in mind in many cases, what probably happens is someone puts a modified object on a map - the first version of that object. In that case, it should pretty clearly not be an archetype. Then someone else decides to copy it. At that point, it may make sense to become an archetype, maybe not. My general thought was always that archetypes should be somewhat generic objects - in other words, objects that map makers would likely find use for in all sorts of maps. Thus, even a highly complex object (that scored really high in the above criteria) probably shouldn't be an archetype if there is very limited places they would be used. I'd think the criteria for something being an archetype would perhaps mean 5 instances of such objects in the maps - that starts to suggest that there is some general value for those objects. 2 instances may not suggest much. How complex the object is is certainly somewhat reasonable - very complex objects would have more reason to be archetypes than simple objects (the no magic floor example). If we do have scripts to find equivalent objects in maps, I wonder if instead making archetypes that could/should be put in the map directory (tools directory or something), and thus could be used to find such duplicates. So we don't necessarily need them to be archetypes, we just need to be able to easily find them. Making this archetypes could have unintended consequences. Map maker A designs the object in just such a way for various reason (maybe for slaying fields, maybe to kill a specific monster in the dungeon, whatever). If that is turned into an archetype, and at some point people go through and start adjusting balance of objects, you now get the danger of that object changing and thus not meeting its designed purpose anymore (maybe people say 'instead of attacktype A, it should have B', not realizing that the original instance had attacktype A becuase that would kill the monster in the dungeon, etc). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] stat loss and highly specialized players
Various quick notes: The target release varies depending on the change. For exp tables, I'd say that it can be put in 1.x as a commented out value, and if desirable, make it the default in 2.0 One thing to keep in mind in all these discussions is the relation of this lost with permanent exp. I think right now, whatever permanent exp you have earned does not affect the loss - it just means you can never have less than your permanent value. But if you die several ties relatively quickly, you can get down to that value pretty quickly. One change in this area could be to to base the experience loss based on the difference between current exp and permanent exp. Thus, for practical purposes, it would be very difficult to ever get all the way down to your permanent exp. But then I'm not sure if that would make any real difference (what could be interesting is having different permanent exp ratios for different skills). I think there will always be some issues with skill inequalities. Lets presume that under a revised system, you basically loose 1 level in each skill. That is certainly a lot better than it is now, but if you are level 80 in one handed fighting and level 10 in literacy, loosing that level in literacy will seem much harsher (in terms of actual character power/importance, level 79 vs 80 in fighting won't have a huge impact (in terms of percentage of actual level less, 9 vs 10 is bigger than 79 vs 80). Not sure how to fix that. One thing to keep in mind for the original tables is that they were done before we had 64 bit experience values. This put the limit at around 2 billion, which is why the hard table has that as the max exp. When the level array was increased to 115 with 64 exp values, the last 5 levels had a lot steeper curve because it could be done and to make it hard for people to max out their character. The old values were not changed for compatibility reasons. Because of that, as far as I can see, as long as the new exp total for level 115 is above that of the old value, there doesn't really need to be a big change in the curve for the final levels. I think under a revised system, you'll actually see fewer people at max levels, since it will be just as hard to get that much exp, so you are more likely to see characters sprinkled out amongst several levels when 100+ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: Mark Wedel wrote: Current status: CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. I've also made 1.x branches of the arch, client, maps, and server (at such time it becomes relevant, it could be done for jxclient and sounds). There are as arch/branches/1.x, client/branches/1.x, etc. snip So as of now, should we be committing to SVN as opposed to CVS, and using the 1.x branch and trunk as has been planned? :) Yes. In fact, I don't think anyone will be able to commit to CVS, as I've revoked everyones CVS access (seems only real way to prevent accidental checkins, etc) Btw, one thought is it would probably be good to make some sort of clear documentation for the usage of the 1.x branch and trunk and the branching plan. You mean like: http://wiki.metalforge.net/doku.php/crossfire_release_cycle That should probably be put someplace more prominently. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Current status: CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. I've also made 1.x branches of the arch, client, maps, and server (at such time it becomes relevant, it could be done for jxclient and sounds). There are as arch/branches/1.x, client/branches/1.x, etc. Things that I still have yet to do, and will do tomorrow night: Use svn propset to make some virtual entries (link to gridarta for the edit, a link in server/lib/arch to link to archetypes), support for $Id$ in files. Also, should make some 'virtual' directories with links to all he relevant pieces. Eg, have a 'complete' or 'latest' directory which can get all the */trunk entries, so easy to get all those. Likewise, probably have a stable directory which links to the 1.x entries. That said, there is nothing preventing developers from checking out the SVN and actively using it - the things left to do above should not affect that. Mark Wedel wrote: Just a note/reminder of this change: Crossfire will switch from CVS to SVN this onday, Sept 18. What will happen: - Current CVS repository will remain available for read-only access, but no future changes will be made to that repository. The CVS repository will purely be for historical reasons (want to see what 1.6 looked like, etc.) Developer permissions will be updated to remove CVS write permissions. The crossfire page on sourceforge will also be updated so that CVS info will not appear. - The SVN repository will only import the head trunk, and not the tags or branches of the CVS repository. Future tags and branches will be made of course. - Only actively developed portions from CVS will be moved over. - Instead of having a copy of the editor in crossfire, we will link to the Gridarta project. - Some amount of cleanup in the repositories will be done - mainly, this means that some automatically generated files will not be included (flex files, collected archetypes/images/etc). The autoconf/automake files will stay in the repository, as it is general practice that code can be downloaded and then a simple configure run. - The server portion will be renamed from 'crossfire' to 'server' to more accurately describe what portion it is. - The organization will be server/trunk, client/trunk, client/branches, etc. After the fact: - The server and client will need some updating to get the version number so they can print that out as a build revision (instead of showing revision of each file). - Branches for 1.x will be made for the different components. - Likely some other cleanup will be necessary. ___ 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
Re: [crossfire] stat loss and highly specialized players
Andrew Fuchs wrote: As what i could skim off of I440r__'s rant on IRC, players that are highly specialized (high level) in only a few skills can loose an unreasonable amount levels in skills that they are trying to develop from low levels. His general point was that it should take longer to gain levels, but players should lose less when they die. Now, does the limit on experience lost from the death penalty apply to individual skills? If it doesn't, does anyone see any issues related to l440r__'s rant? Should the death penalty apply to individual skills? It should apply to skills as well as overall levels. So under normal circumstances, I think that means no more than 3 levels lost from any skill and overall level. However, you could lose 3 levels from several different skills - for example, pyromancy, one handed weapons, praying, so it could seem like you are lose 12 levels (3 skilsl * 3 + 3 for overall level) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] New crossfire todo list
I've taken a bit of time to go through and make a new todo list of most things that need to be done: http://wiki.metalforge.net/doku.php/dev_todo_new There is still more stuff to add. It's unclear at what complexity level something should be there, vs a bug on the tracker or just go and do it, but I'll think more about that later. I also see that as becoming the definitive TODO list, replacing the one in the server directory which is always out of date, and doesn't really provide much in the way of tracking. I've added comments to a fair number of the items there. In no way does that mean that is the definitive, or even correct, way of doing it. I was mostly just trying to gather the useful bits from past mails, etc, and put it there vs sitting in my mailbox. I'd also suggest that it is generally better to actually pull out the useful bits of the conversation and put them in the wiki vs referring to the mailing list - too often, it may be a thread of 50 messages, with most not providing much useful info - its a bit more handy to just be able to see the main points. A few notes/questions. In looking through the TODO list in the server, some questions about these points: If a shop is placed in a random map (special map), the objects below the shop wall stick around - normally not much a problem, unless it is placed in a glory hole (treasure level), in which case coins are now beneath the wall. (I seem to recall seeing a recent commit that may have fixed this?) Change code so that if a player kills another player, he gets no exp (I recall seeing discussions about this, but don't see anything in the settings to suggest that this has been done?) Allow possibility of one players magic not harming another player (isn't this what the friendly fire option does, so this should be removed?) Ability for stores to set different prices for goods (The shopitems code only affects how much you can sell stuff for, not buy stuff, correct? If so, this is still valid) - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New crossfire todo list
Alex Schultz wrote: Mark Wedel wrote: - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) Yes. When inscribing spell scrolls, one needs to do something along the lines of mark scroll-to-inscribe-over; cast meteor swarm; use_skill inscription. The change suggested there would make it so one would use something like mark scroll-to-inscribe-over; use_skill inscription meteor swarm instead. This should probably be taken to the next step, with the client providing some nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client would then present list of possible items (based on client type attribute) and list of spells, and player chooses. Of course, the client still has to send the actual request to the server, and the server would still have to validate if it works. Thinking about this, the logic for this on the server side could actually do most of the work with very little changes. Eg, client does something like: C-S: inscribe scroll tag spell name/identifier The server side command for that could find the object of scroll tag, save away current marked object, mark the scroll object, store away current ready spell, ready new spell, call inscribe code, and then put back the marked object and ready spell. OTOH, would probably be better for the inscribe code to take the inscribe to object and spell object and just go from that, as that would be cleaner. I am really thinking, however, that having the client handle most of the presentation of this is the better way to go. - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) Personally I don't think we want to go that route, however the suggested code re-orgs such as what I proposed a while back in the mailing list, would as a side affect make splitting the 'rules' and 'engine' easier, if at any point we decided we wanted to. IMHO we should do the code re-orgs and decide if we want to split the 'rules' and 'engine' after. And I'm not sure how much reason there is to split the rules and engine in any case. But if it is easy to do that, that could help in the testing actions perhaps. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] current plugins with python 2.2?
Nicolas Weeger (Laposte) wrote:
1) require newer version of python (as with python 2.2, it clear seems
broken) 2) Look at python 2.2 doc and figure out if code can be modified to
work with it.
Hello.
Here's a patch that may fix the issue (I haven't checked the docs, but that's
an obvious thing to test ;p)
That fixed the problem. I take it there is no bad effect of doing this for
newer versions of python, so it should probably be committed by someone?
Nicolas
? python.diff
Index: cfpython.c
===
RCS file: /cvsroot/crossfire/crossfire/plugins/cfpython/cfpython.c,v
retrieving revision 1.37
diff -u -r1.37 cfpython.c
--- cfpython.c27 Aug 2006 14:11:34 - 1.37
+++ cfpython.c29 Aug 2006 20:42:42 -
@@ -840,8 +840,11 @@
int value;
} CFConstant;
+static PyMethodDef CFConstantsMethods[] = { { NULL, NULL, 0 } };
+
static void addConstants(PyObject* module, const char* name, CFConstant*
constants)
{
+
int i = 0;
char tmp[1024];
PyObject* new;
@@ -850,7 +853,7 @@
strncpy(tmp, Crossfire_, 1024);
strncat(tmp, name, 1024 - strlen(tmp));
-new = Py_InitModule(tmp, NULL);
+new = Py_InitModule(tmp, CFConstantsMethods);
dict = PyDict_New();
while ( constants[i].name != NULL)
___
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
Re: [crossfire] CVS - SVN conversion
Nicolas Weeger (Laposte) wrote: flex files that generate .c (loader.c) - not a big space user, yet at the same time, pretty trivial for most people to generate (probably any system that has gcc can pretty easily install flex if not already there). The flex files do not change very often. The one question might be windows (can they easily be regenerated there?). Given these are small files, I'm sort of mixed on these. The version of flex used to generate these files really doesn't have any impact on performance - I don't think we've ever had an issue where someone had a bad version of flex installed that caused problems. Windows users can generate loader.c with flex, already done that. Just need to ensure the right flags are used (iirc case-insensitivity, for instance). Ok - so maybe leave out the flex generated files then. rebuilt lib files (Archetypes, images, etc): These are the files I'm most inclined to leave out of SVN. The images tend to be quite big (slowing down updates). Plus, the updates are rather inconsistent - they are not updated after every change is made to an arch, but rather when someone remembers to or is some critical need. Within SVN, we can set up lib/arch to point to the actual arch tree, so an update of the server also gets updated arches. Plus, we already have all the tools in place to collect them (the collect.pl script), so this doesn't add any additional software dependencies. If anything, this may actually help people use the updated archs. The only issue with that is that archs would now be part of the whole crossfire module. Thus changing an arch will make a new server version. Unless i'm wrong? If my understanding correct, the revision number will be unique for each of the different modules (arch, client, etc). Even if it isn't, that really isn't much different than if we have the collected ones - then when you collect the archetypes and check them in, that is updating the revision number, even though nothing in the server really changed. Right now, the archetypes file is not updated every time and arch file is updated, but in theory it could be. If anything, not having the collected files in the server tree would mean less server revisions. Maybe 1 out of 10 (or 20) commits to the server is just a recollection of the archetypes, etc, and those wouldn't be needed anymore BTW, while we're at messing with stuff, shouldn't crossfire be renamed to server? There is really two issues here: 1) What is the module called within SVN. In this case, I agree we should rename it server. 2) What is the executable that module makes is called. This is really independent of the point above. It should be renamed crossfire-server of cf-server of the like, but that is a change that should be made in the main head branch for the 2.0 release. As a note, for any files that we automatically generate that are not normally in SVN (if we so decide) yet are in the distributions we ship out, I'd expect they would be in the release branch of the SVN repository for that release (so you can go to the 1.10 branch and see what the archetypes file had, or see what the makefile looked like, etc). Although, maybe even that is useless - could always just download the old releases. As a remark, I'd say to automate stuff as much as possible in that case. That is make a nice script building everything, collecting archetypes, generating tarballs, all this stuff. Even if it only takes 15m to do by hand, that becomes a pain fast :) (talking from Windows experience, where i should definitely automate things!) The makefiles will already recollect archetypes and build the flex files as needed. So in a sense, the only extra work is to add those files in the repository. But that part can certainly be in a script. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. Actually, it isn't the default, but easy enough to do it that way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Mark Wedel wrote: It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. Actually, it isn't the default, but easy enough to do it that way. Except I can't see a way to do it in sourceforge. To do it, you would need multiple repositories. However, best I can tell, with sourceforge, 1 project == 1 repository. So to do this on sourceforge would entail having multiple projects, which gets into other administrative issues (each project would have its own developer lists with permissions, etc). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
A copy of the crossfire data is now in svn.
Note: This is only a test copy for experimentation, and will be blown away on
Monday Sept 18. Do not commit any real changes - still put those in CVS.
to check it out:
svn co
https://svn.sourceforge.net/svnroot/crossfire/trunk/{client|arch|crossfire, etc}
edit files. To commit:
svn commit
I had some issues getting the commit to work, but now that it is working, it
seems to cache the data.
I think the issue may be that while the developer permissions within
sourceforge show that everyone has SVN access (everyone that is a developer),
things started working better when I unchecked that for myself, updated it,
then
checked it again, and updated. Probably a matter of it having to put some
files
in the svn tree.
I haven't gone through and updated everyones permissions for that - it'd be
curious if this is the real fix, or in my mucking of other things, I fixed the
problem.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Christian Hujer wrote: On Tuesday 12 September 2006 07:35 Mark Wedel wrote: Actually, from what I gather, it seems unlikely someone would do a svn checkout at the top of the repository. The reason being is that if you do that, you'll also get all the branches, which would amount to a pretty huge amount of data. I doubt people would even checkout out all the trunks, but maybe wrong on that. So that probably isn't as much an issue. Did you already think about how to organize the repository? The main question is: Do you want to apply ttb to maps, client, server etc. independently or one for all? Module-Individual ttb: /modulename/trunk /modulename/tags /modulename/branches Global ttb: /trunk/modulename /tags/modulename /branches/modulename Technically, I'd usually prefer the Module-individual ttb. If so, it would be a good idea to provide a virtual module named complete (or something better, I'll just assume the name complete for this example), probably with trunk only, where trunk has svn:externals set to include the trunks of the other modules: cd complete; svn propset svn:externals maps https://subversion.sourceforge.net/svnroot/crossfire/maps/trunk client https://subversion.sourceforge.net/svnroot/crossfire/client/trunk; etc.. It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. This also matches the current CVS setup - there are different top level entries that can be checked out. SVN does present some more options, since external references can be done, etc. I'm not sure how much use an ability to check out all the main trunks would get used - maybe for the home hacker. But I imagine for most public servers, they probably don't want the editor or client, etc. But I suppose there is no real harm to add something like that, whether or not people use it or not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Christian Hujer wrote: Hi all, Am Montag, 11. September 2006 01:11 schrieb Mark Wedel: 1) They don't have a conversion utility, but rather directions (using cvs2svn) to make the change. Well, they used to have a conversion utility: https://sourceforge.net/project/admin/svn_migration.php?group_id=nn (Replace nn with the project id of crossfire) Instructions: https://sourceforge.net/docs/E09#import But actually I never got that migration tool working, it always failed for me. That's what I used, but it doesn't do the conversion for you - running cvs2svn still has to be done by the end user, etc. Given that, whatever files we care about can be removed from the copy of the CVS data before it being converted, so we can clear out any data we want to. If this was 100% automatic, we wouldn't really be able to do that. 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. It does. It only has to be switched on for each file individually. It's done via svn propset svn:keywords Id filename For instance: cd sandbox ; find -type f -print0 | xargs -0 svn propset svn:keywords Id or if it's not that many files, especially none with whitespace in their name cd sandbox ; svn propset svn:keywords Id $(find -type f) Ah - very good. Looking at the docs, I see that SVN uses the global version number in the $Id$ strings, which is fine. What I'm not sure of is if there is some way to have a file that automatically gets updated with the latest version string. For example, it would be nice for the version.h file to get updated on every commit that is done, so that it always contains the latest commit ID. If that was done, there really isn't any need to have the $Id$ in each file - just print that global number. sure, there can be the odd cases of a person updating only portions of the tree and getting out of sync revision numbers. But if someone does that, they are really asking for broken behaviour anyways (who is to say that there isn't some interaction related to this - a file that isn't updated needs to be updated to properly work with other files) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: Well, that's assuming that developers do a checkout of the maps, client, server, archetypes, etc. in one checkout, as opposed to checking each out separately (though SVN doesn't have modules, one can always check out the server directory without the map directory) Actually, from what I gather, it seems unlikely someone would do a svn checkout at the top of the repository. The reason being is that if you do that, you'll also get all the branches, which would amount to a pretty huge amount of data. I doubt people would even checkout out all the trunks, but maybe wrong on that. So that probably isn't as much an issue. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Proposal: Alchemy spell changes
Alex Schultz wrote: The alchemy spell has so long as I can remember been a rather useless spell, and since the shop system change has become increasingly so after the shop system change. I propose that gold nuggets be changed to count as a gem, and hence give their true value in shops just like diamonds, and then reduce the amount of nuggets the alchemy spell makes, from 9/10 of the value, to range from 1/2 to 9/10 value depending on the casting level of alchemy (only getting to 9/10 at level 115 or so). This would make nuggets from the alchemy spell give a way to get decent money for items while not having to look around for the best place to sell as much, but give worse value than what one could get if one searches around, and if one gets very high level sorcery one could get close to the best store value by creating nuggets and selling them. That seems reasonable to me. And it shouldn't be that hard to make. One of the current issues with alchemy may be at moderate to high levels, the weight of the nuggets created is also too much to reasonably carry. I wonder if it may be worthwhile to make different nugget types (platinum nuggets?) Having a higher denomination nugget doesn't help out if the weight is also higher, which is why going to a different material is needed. OTOH, perhaps the weight of the nuggets should be seen as a way of limiting amount of wealth removed from dungeons ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] CVS - SVN conversion
As noted in anothe e-mail, SVN won the vote for the source code system for use on crossfire. Next step is to actually switch over. Looking on sourceforge docs, I notice a few things: 1) They don't have a conversion utility, but rather directions (using cvs2svn) to make the change. 2) The CVS respository does not appear it will go away, so after the conversion, both SVN and CVS access will be available. However, only updates should be done to SVN, so CVS will go out of date (but is still probably useful as a reference for older releases). Given this, these are my thoughts: 1) A date for the switchover needs to be chosen. My personal inclination is sooner vs later, yet at the same time, want to give enough time in case people have work in progress that is almost ready to commit (so they don't have to resync/copy into SVN). The flip side of this is that if this is too far away, this could delay people starting working (don't want to be halfway done and then have to sync up again). I'm thinking maybe 9/18 (monday) as the date to switch over? Give people a week to commit their changes, etc. 2) Since CVS will remain on-line, I think the safest thing to do there is revoke everyones read/write access to CVS at said date, since there shouldn't be any reason for anyone to do commits. 3) Since we can decide what files to import or not import, it may be a reasonable time to clean up some of the directories in the CVS root tree right now (eg, not move them to SVN), particularly: alternate_images: These have been merged into the main arch tree long ago. cfclient_sdl: I don't think has been updated in many years - I have a feeling daimonin probably has a more up to date version that should be examined if we're serious about this. client/gnome: hasn't been supported in a long time iso_arch: Like cfclient_sdl above - really not used since daimonin. maps: Been replaced by maps-bigworld. All of these will remain in the Read-only cvs repository, so won't be lost. It just doesn't seem like there is any active development on these, so no reason to have them in SVN. 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. I thik there may be modules that support it, but sourceforge is very particular in what modules they support (short list being ones that provide e-mail notification, and another that checkes file names for reasonable compliance). There may be client side scripts that could be used, but then that seems a little more problematic (some developers forget to use/install them, so their commits are not updated, etc). Does it just make sense to pull the $Id strings out of the files then? 5) I might try uploading a converted repository before the 9/18 date to find any issues - in this case, it could be used for testing, but would be blown away on 9/18 when actual conversion is done. I think that is it - anyone have any other issues/comments? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: Mark Wedel wrote: 2) The CVS respository does not appear it will go away, so after the conversion, both SVN and CVS access will be available. However, only updates should be done to SVN, so CVS will go out of date (but is still probably useful as a reference for older releases). IMHO it's not worth doing, but in theory it would be possible to use a tool like tailor to incrementally update the CVS copy every so often. I don't think it would be awfully useful, however just pointing this out in case someone does think something like that would be useful. Not sure about tailor, but IIRC, one of the issues with most of these conversion tools is they do not deal with branches very well (probably because the branch methods vary wildly - in the case of SVN, branches are basically new copies of the repository). I forgot to mention in my previous e-mail, one of the first things I'll do once we move to SVN is to make a branch for the 1.x releases (with the main/head branch being for 2.x). snip 3) Since we can decide what files to import or not import, it may be a reasonable time to clean up some of the directories in the CVS root tree right now (eg, not move them to SVN), particularly: alternate_images: These have been merged into the main arch tree long ago. cfclient_sdl: I don't think has been updated in many years - I have a feeling daimonin probably has a more up to date version that should be examined if we're serious about this. client/gnome: hasn't been supported in a long time iso_arch: Like cfclient_sdl above - really not used since daimonin. maps: Been replaced by maps-bigworld. snip This seems like a good idea to me. Also, perhaps we shouldn't move CFJavaEditor, and instead use 'svn:externals' (See http://svnbook.red-bean.com/en/1.0/ch07s03.html) to link to Gridarta's copy of CFJavaEditor in their SVN repository. To do so would be something along the lines of this inside of a new empty CFJavaEditor svn repository: svn propset svn:externals 'https://svn.sourceforge.net/svnroot/gridarta/trunk/crossfire' . Which would effectively redirect svn clients to that url to download it if they would try something like a svn checkout https://svn.sourceforge.net/svnroot/crossfire/CFJavaeditor;. This makes sense to me because active CFJavaEditor development is happening in the Gridarta project, and if the old history is needed for historical reasons we have the cvs repository of it around. could do that. But then I wonder if that makes sense, or if whatever docs should just be updated to point to the gridarta repository. One reason here is developer permissions - if it is in the crossfire SVN root, people may expect that since they have crossfire SVN write permissions, they should be able to make updates to it - however, if it is a link, they won't. All that said, if CFJavaEditor has been superseded by gridarta, then it doesn't make sense to have a copy in the crossfire tree - so the question more becomes should a redirection be done, or just nothing at all? 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. I thik there may be modules that support it, but sourceforge is very particular in what modules they support (short list being ones that provide e-mail notification, and another that checkes file names for reasonable compliance). There may be client side scripts that could be used, but then that seems a little more problematic (some developers forget to use/install them, so their commits are not updated, etc). Does it just make sense to pull the $Id strings out of the files then? Well, the $Id strings have never seemed terribly useful to me (it was often more convenient for me to just check the timestamp of the build and/or source directory if I wanted to know when in CVS it was built from), however if anyone has any use for them, probably wouldn't be difficult to make a script to generate a .h file containing macros of that data, and put that in as part of the build system. The client had been modified at one point to provide that information, just to be more helpful in bug reports. That said, I agree that the header in each file probably isn't necessary. It might be nice to include the svn commit number in a header file, so that could be displayed, eg, the client could say something like: Crossfire Client 1.10 build 8963 Such that if a user reports a bug, we can easily check that global revision number and see if the bug may have been fixed, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills
Alex Schultz wrote: Mark Wedel wrote: Andrew Fuchs wrote: I came up with an idea that would add significance to a player's choice of class, and be an other way to tweak experience. What if skills associated with a class give the player more experience when they are used? snip IMO, it is a good idea. The previous discussion actually had it more general, in that there maybe multiple levels of skill gain. Best way to handle this is by using a field in the skill itself to denote extra gain/penalty (as a percentage). In this way, there could also be special questions, etc, that perhaps give you a better version of the skill, etc. This seems like a good idea to me too, and Mark's proposed method of implementation also makes sense to me. Also, one might want to consider giving small negative bonuses for certain skills to certain classes. For example, perhaps give warlocks a small negative bonus to one/two-handed-weapons skills, and barbarians a small negative bonus to literacy and/or spellcasting when they obtain those skills. But that gets messy, as how do you know what race/class coincide with what skills for bonuses? the best way would be to have a file someplace that dictates it - you really don't want to have to try and hardcode those. However, IMO, the better way would be to do it in-game. First, different classes start with different skills - some better than others. Spellcasters would generally have 'good' versions of the spellcasting skills, and poor versions of the combat skills. Some of the classes may have mediocre versions of all the skills. Of course, characters don't start with all the skills in the game, so there are still skill scrolls to find. Random skill scrolls you find in dungeons/shops would generally be 'poor' in that you don't get a lot of exp when using the skills. Very rarely, you may find a mediocre one. I'd actually say that you should never be able to find good ones (as good as the best starting one for a class). Perhaps there could be quest tie-ins, but the problem is then at some point, everyone goes on the quest and get the good one. A better method would be prerequisite + a quest. Eg, to get a good version in 1-handed weapon for a mage, they need to be level 40 in the skill and do a quest - if they have put that much effort into the skill, could give them something for it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] And the winner is:
And the winner is: SVN The vote was fairly close, but pretty much for any counting method used, the results where basically, SVN, CVS, Mercurial. I'll give a few days for these results to be digested before making the switch to SVN, just in case there are errors. I'll send out a separate e-mail about that change. Voters Votes: Names Developer BZR CVS Darcs MercSVN Other Mark Wedel/mwedel F 5 3 4 1 2 Rednaxela/qal21 F 5 3 4 1 2 Ryo/Nicolas Weeger F 5 2 4 3 1 David Delbecq/tchizeF 5 2 5 5 1 Gros/Yan Chackhoff I 2 4 5 1 3 Raphael Quinet I 4 1 3 6 2 5 (SVK) Andrew Fuchs/techolous I 2 1 4 5 3 laloI 1 6 3 2 5 4 (GIT) Andreas Kirschbaum I 3 2 5 4 1 Christian Hujer (cher) RO 4 3 2 5 1 kbulgrien, Rayvin RO 3 1 4 2 5 Rick Tanner/leafRO 2 1 4 5 3 Note - in many cases, I condensed the names so they would fit in the table - if anyone has questions on names, let me know and I can go back and send out full names Developer types: F = Frequent (average more than once a week) committer I = Infrequent committer (at least once a year, but less than 4/month) RO = Read only access (keep server/client up to date, etc) To use the votengine software that someone pointed out, the above table had to be converted to a ranked choice table. I wrote a quick script to do that - here is that table you can feed to votengine if you want: -cands BZR CVS Darcs MercSVN Other # Frequent devs MercSVN CVS Darcs BZR MercSVN CVS Darcs BZR SVN CVS MercDarcs BZR SVN CVS # Start of infrequent devs MercBZR SVN CVS Darcs CVS SVN Darcs BZR Other Merc CVS BZR SVN Darcs Merc BZR MercDarcs Other SVN CVS SVN CVS BZR MercDarcs # start of read only access SVN Darcs CVS BZR Merc CVS MercBZR Darcs SVN CVS BZR SVN Darcs Merc ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] The Kirby project: Valkyrie, goddess of war
Lalo Martins wrote: On Wed, 06 Sep 2006 22:49:54 -0700, Mark Wedel wrote: Lalo Martins wrote: The slaying thing will only affect enchanted weapons, and she gives them rather frequently (as weapons are sacred to her). Does she give arrows out a lot? That could help give these character some form of range attack. I could do that. Enchanted arrows? I think normal arrows are about easy enough to find already. I was thinking that if you could get magical arrows of slaying, or even better, arrows of assassinating, those could be really nice. And would perhaps make using a bow more interesting. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] The Kirby project: Valkyrie, goddess of war
Lalo Martins wrote: The slaying thing will only affect enchanted weapons, and she gives them rather frequently (as weapons are sacred to her). Does she give arrows out a lot? That could help give these character some form of range attack. One alternative idea is to change the flesh code to fill the exp field of flesh objects with the exp of the originating monster; would that have any unexpected side-effects? Then of course the altar wouldn't give the whole exp, just a fraction depending on some factors yet to be defined. I'm not sure if there would be any side effects of filling in the exp field. I doubt it, but I'm not 100% sure that exp isn't overloaded with some extra meaning. (On an unrelated note, if I do change the flesh code, I'd like to add the archetype of the original monster in the other_arch field, for the purpose of a spell I'm thinking about; any problem with that?) probably not. The issue may be that the archetype may not be entirely useful - custom monsters on high level maps vary quite a bit from the archetype, so you'd have to be careful what fields you use and what you use them for. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels
Raphaël Quinet wrote: On Sun, 03 Sep 2006 15:27:20 -0700, Mark Wedel [EMAIL PROTECTED] wrote: Raphaël Quinet wrote: But again, that would be the wrong way to limit the number of levels lost: if a server admin does not want players to lose more than 1 level per death, then the admin should modify the exp curve or lower the death_penalty_percentage. But it seems like you are deciding server policy for server admins, who may not agree with that policy. I agree with Alex here - keeping that option around doesn't do any harm - it can be set to a high value such that it effectively does nothing. But if a server admin does want to set it, who are we really to say that you can't? I don't want to prevent server admins from limiting the number of levels that are lost when a player dies. I just want to be sure that it is done in the right way. In other words, I don't want to decide server policy, I just want to have a better way to implement that policy. I agree that the exp table should be updated, and other changes should be made. I just don't see a really compelling reason for the death level loss limit to go away - it is currently in the code, and currently works fine. Sure, using it may mask broken behaviour elsewhere, and different/better tables should be used. But there are potentially many options within the settings file which change balance or could cause breakage - maybe some should be removed, maybe not. But the point is that we provide the option for server admins to use them. I suppose some of this is depend on what release this is target at. If 2.0, less an issue. However, if it is targetted at the 1.9 cycle, then I really think this option must remain - I'd expect most servers are not going to change the exp table mid stride, and at the same time, don't want to change the death loss mid stride either - after all, its not really fair for newer players to play with different rules than the older players. Side note: encouraging a more careful playing style would also require updating some maps. Several areas can trap the player without warning (especially some no spells areas as I mentioned a few weeks ago) or they contain some warnings but do not mention how hard the area will be and do not indicate that there is no way back (e.g., lake country's burial ground or dark angel Hanuk). Even a careful player will probably want to explore a bit and will eventually fall into one of these traps and die. The warnings for these areas should be a bit more explicit. I agree on those points - places that trap the player are generally poor design. And the difficulty of some places is another issue. Now some of this could perhaps be helped out if the game play is slower - if it takes 10 seconds to be killed by a monster, that is still enough time to cast word of recall and get out. The problem is some places, death is in a matter of seconds, which isn't enough time. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills
Andrew Fuchs wrote: I came up with an idea that would add significance to a player's choice of class, and be an other way to tweak experience. What if skills associated with a class give the player more experience when they are used? This could also be taken in the other direction by limiting the experience players gain with skills not associated with their class. For example, an evoker will level up more quickly if they use evocation, than if they used sorcery, bows, or melee attacks. This has been discussed before. IMO, it is a good idea. The previous discussion actually had it more general, in that there maybe multiple levels of skill gain. Best way to handle this is by using a field in the skill itself to denote extra gain/penalty (as a percentage). In this way, there could also be special questions, etc, that perhaps give you a better version of the skill, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels
Raphaël Quinet wrote: Proposed solution: - Get rid of death_penalty_levels. This option hides the real problem instead of solving it. I'm personally more inclined to leave the death_penalty_levels option, but set it's default to unlimited, so server admins could do things such as make their server do something like a 1 level per death max if they wanted to. But again, that would be the wrong way to limit the number of levels lost: if a server admin does not want players to lose more than 1 level per death, then the admin should modify the exp curve or lower the death_penalty_percentage. But it seems like you are deciding server policy for server admins, who may not agree with that policy. I agree with Alex here - keeping that option around doesn't do any harm - it can be set to a high value such that it effectively does nothing. But if a server admin does want to set it, who are we really to say that you can't? IIRC, the reason that was added was that at high levels, a characters death could amount to losing quite a few levels. Sure, at high levels it may not be hard to regain them, but the point was that losing a whole bunch was considered excessive. I have a feeling that removing it may cause several complaints, as a character that dies loses more than they expect. (another issue related to this is overall level, which dictates items you can wear, etc). But this actually has more issues related to death. If the death penalty is not very high (in terms of whatever penalty, be it exp or stat loss, etc), then players are more likely to play aggressively. If a death costs me 15 minutes, but agressive playing more than makes up for it because of faster exp gain, you play agressive. OTOH, if death penalty is very high, players would play much more cautiously, because a death may mean several hours of lost work. In this case, playing slower/safer may make up for it, even with the slower exp gain. I'm not sure what the perfect balance is, but that is just some food for thought. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Rebalancing, difficulty curve -- simple ideas
Raphaël Quinet wrote: The current exp_table (with its flaws) was obviously designed for the combat skills and for the total experience. But it does not work as well for the mental/craft skills. Awarding more exp points for using these skills successfully would not be a good solution because these should not contribute as much to the total exp. But on the other hand, it would be nice if it was possible to reach level 100+ in literacy or other skills. I think there is more an issue of just monsters - for the combat skills, you can basically find tougher and tougher monsters, that give lots more exp. For most of the mental skills, the complication of things gets cut off. Readables above level 10 are pretty darn rare. I'm not sure about find/detect traps, and the item identification skills are another issue all together. I don't think multiple exp tables is really the way to go. Why? Because I think you may really need 6-7 tables for things to be fair for all the skills. And given that the exp table is currently a config file that can be customized, having lots of tables one has to adjust would seem to be really complicated for servers. I do think the correct approach is this: 1) re-adjust exp rewards for non combat skills so that level can go up in a reasonable fashion. For readables, it could mean that 10 readables at your current skill level amounts to a level for example, for lockpick, 30 doors, etc. 2) Adjust the non combat skills so they contribute less exp to the total - that can be done right now - make it 20% or something. However, this second point can be an issue - lots of people say that it should be reasonable to play non combat characters. Overall level doesn't mean a whole bunch - it is just hp. A level 100 character with no combat skills will still fair poorly in battles ` ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Rebalancing, difficulty curve -- simple ideas
Wim Villerius wrote: The main problem i've observed when playing was that once you can kill a certain mob, you can continue killing it until you 'die' out of boredom. That means: hit - say - lvl 40 and start killing demon lords until you're lvl 110. A method that works perfectly. (and in case you get bored on demons, go dragons or angels, they work more or less the same) My suggestion is to adjust the amount of exp gained by killing a certain mob by at least hte following factors: 1) the number of that mob you have already killed 2) mob lvl / player lvl in that skill One problem here is that at higher levels specifically, the number of reasonable monsters go down. How many monsters are there really for characters at level 50+ to fight? If there are not a lot, you're effectively limiting exp gain because there is nothing left to kill. I'm not sure if that is a really good approach. There used to be code that would adjust exp based on creature level and player level. But that had several problems and was removed - notably it becomes really difficult to try to find correct exp values when you have many variables (exp table increases at some rate, amount you get for killing it at a different rate, etc). And then you start getting abuses, like I'll weaken it with my highest level skill, then kill it with a lower level skill to get more exp, etc. IMO, there are basically 2 ways to do this: 1) Make the exp table harder at higher levels - in this way, at level 60, you need to kill more of the creatures than at level 40 to gain a level. We don't need to further adjust that by level comparison - the exp table itself should be adjusted. 2) Make the exp table linear, make most monsters the same exp, but adjust reward based on level difference. The problem is that if a character, especially at lower levels, is able to kill a higher level creature, they get lots more exp (15/10 = 1.5 reward, where as 70/60 = 1.17 reward). With certain items/spells that are really effective against certain creatures, this means fast exp gain. It seems like the goal here is to make it so you have to kill more monsters at higher level. That is currently the case with the exp table, but it sounds like the exp table needs to be re-adjusted. This 1) stops players reaching demigod status fast - it will take them long, and a lot of different mobs as well. No more efficient TC-training 2) doesn't necessarily recuire a new exp curve 3) most important: makes sense. killing ants at lvl 110 should not give exp. that's rediculous :) Point #3 isn't much a point. Sure, the player gets some exp when killing an ant, but at level 100, probably needs to kill a million ants to gain a level - if he wants to do so, fine. I think one of the general problems is things like the training center and random dungeons (and even non random dungeons) where monsters are just stacked high. The fact players can basically find monsters to fight as fast as they can reasonable fight them is a bit of an issue. In the vast majority of games, that really isn't the case - there is some amount of exploring to do, etc. Even in nethack, which hack and slash, most rooms only had a single monster and only half a dozen rooms per level - you probably are spending as much time moving room to room as you are fighting. Recording number of kills of each monster the player does is interesting, if nothing else than for record keeping purposes. I think it was ularn which would provide stats of what you kill, as well as more info about the monster itself the more times you kill it. But as said, I'm not sure that adjusting exp is really the way to go. And the problem with all formulas is finding the right one. The current exp tables were not designed to be bad tables - the best table at the time was done. The same is true with formulas - while putting them out here sounds good, it may be after months of testing, we find the formula in fact isn't good (too easy/too hard). I'm most inclined to do exp table adjustments, because that is the easiest thing to adjust. If during play testing you find 'I got to level 28 way too easily - it should take 3 times longer', it is pretty clear that the exp table gets adjusted upwards accordingly by a factor of 3. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Reminder: Vote: Crossfire source code control system.
Reminder that there is less than a week of voting left. For every vote I receive, I reply confirming I received the vote - if you've voted but not received a confirmation, send mail again, and if still don't get a confirmation, try to find my on irc. As any readers of the mailing list know, there has been much discussion on what source code control system should be used for crossfire (stick with CVS, or switch to something else, and if we do switch, what to switch to). This is your chance to vote. Ballot is below. Send these back to me ([EMAIL PROTECTED]) to reduce traffic on the mailing list. Voting ends ~September 8. I don't know precisely what time I will tabulate the ballots, and I'll include any I receive up to the the time I start tabulating. If you want to make sure your vote is in, send it before then. I'll then send out results, including what everyone voted for. Please use the ballot below and keep to that form, so it will be easier to process the data with scripts. One ballot per person. The exact method of tallying is yet to be decided - most precisely potential different weight based on peoples current usage. Hopefully, no matter what method is used, the votes will be sufficiently clear cut that there will not be any issues, but I can perhaps forsee some discussion after all the votes are in and tallied. To make things easier, please only include the ballot portion in the e-mail. Ballot Starts Here - Crossfire user names (irc, sourceforge accounts, other names you be be known as): Please check what best describes your use of the current source code control system (current system being the CVS repository): _ Frequent (average more than once a week) committer _ Infrequent committer (at least once a year, but less than 4/month) _ Read only access (keep server/client up to date, etc) _ Do not currently use CVS access Please rank in order of preference which system should be used, with 1 being the system you would most like to use, 5 being least desirable. If you select the other line, then rank 6 choices): _ BZR _ CVS _ Darcs _ Mercurial _ SVN _ Other (specify: ) - Ballot Ends Here - Sample ballot example (before anyone reads anything too much into the list of preferences below, I randomly generated those): Sample Ballot Starts Here Crossfire user names (irc, sourceforge accounts, other names you be be known as): Joe User, juser, bigjoe Please check what best describes your use of the current source code control system (current system being the CVS repository): _ Frequent (average more than once a week) committer X Infrequent committer (at least once a year, but less than 4/month) _ Read only access (keep server/client up to date, etc) _ Do not currently use CVS access Please rank in order of preference which system should be used, with 1 being the system you would most like to use, 5 being least desirable): 3 BZR 2 CVS 4 Darcs 5 Mercurial 1 SVN _ Other (specify: ) - Sample Ballot Ends Here - ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] extended info markup language
while on this topic: The tags (and for that matter, gtk1 client) have the idea of different fonts - from the mediatags file: [fixed] set the font to fixed width [arcane]set the font to a magical one [hand] set the font to hand writing [strange] set the font to 'strange unknown language' [print] set the font to the client default one A few questions/notes: for the 'strange' font, is it meant to be literal/readable? For example, if I have '[strange]this is a short message', with the ideal strange font, should a person be able to read that and understand it, or should it appear basically as gibberish? If the later, is the assumption then that the text using it should also be gibberish, eg, '[strange]adsf kj23 adf la zxdv 12' type of thing? It gets sort of odd, because if the user doesn't have a strange font installed, things will fall back to normal font, and thus be in standard roman characters. Second question related to that - the gtk1 client has a list of a bunch of different fonts to use for arcane, hand, and strange. At least on my system (fedora core 5), I don't have any of those fonts, so I'll just get the normal fonts. Are their pointers where users can get those fonts? If the fonts are GPL, would it make sense to have a crossfire-fonts package to have the different fonts? The idea of these different fonts is nice, but if no one has them, and no one knows where to get them, doesn't do much good. With x/gnome, adding fonts I think is a bit of a pain (really want to put the fonts where the system expects them - hard to load them up from some custom directory). For the gtk2 client, I'm letting pango do the work, so just need to provide the font family. Lastly, I wonder if it worthwhile to add tags for any of the following: font size - there is bold and italics, but nothing to increase size. If this is done, I think the size would have to be relative to the base font size, eg: [fontsize=+2] - increase font size 2 points over base size [fontsize=0] - set font size to base size [fontsize=-2] - set font size smaller than base size When I say base size, I suppose meaning that the client is running with 14 point fonts, and adjust from that. underline: is supported - would it make sense? You can look at: http://developer.gnome.org/doc/API/2.0/gtk/GtkTextTag.html scroll down a few lines to the Properties box - those are properties we could easily set, but I don't think there are many others that make sense. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] insert_ob_in_map question
Nicolas Weeger (Laposte) wrote: Hello. Debugging the weather system, I found some weirdness I'm not sure how to fix. When laoding an overlay, insert_ob_in_map gets in some circumstances as flags INS_MAP_LOAD and INS_ABOVE_FLOOR_ONLY The trouble is that sometimes leads to inserting the item *below* another floor. So we have puddles below the ground :) Any idea on how to fix that? I'd think that the correct behaviour for INS_ABOVE_FLOOR_ONLY should insert the object above the topmost first, not the first floor. I'm not sure if the code currently does that. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] crossfire source code control systems
Lalo Martins wrote: A few days ago a friend was describing the Australian system to me. He (she?) probably didn't describe it very precisely, and I probably didn't understand it perfectly, but it goes more or less like this: You vote for a number of options in order: your favourite, your second choice, and so on. I think you're supposed to cast 5 votes and you're allowed to cast less. You basically described the instant run off system, which is sometimes called the australian system. More info: http://en.wikipedia.org/wiki/Instant-runoff_voting It is probably a good method to use, because I doubt any system will get a majority on the first vote, and it avoids run-offs. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] crossfire source code control systems
It's been a couple weeks. So doing a quick scoring (using http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable as the reference): CVS SVN Hg BZR DARCS Key Requirements (7)7 7 6¹ 7 6¹ Top Features (6)3 3 5.5 4 4 Nice to Haves (7) 2 6 6.5 7 7 TOTAL (20) 12 16 18 18 17 TOTAL2² (30)20.524.526.727 25 ¹missing known free hosting service ²weighted so that key features are times 2, top features times 1.5 so BZR would seem to be the winner, but except for CVS, all score pretty closely. What throws off the results some is the ability of a hosting service. If someone added mercurial or a darcs hosting service tomorrow, that changes the results. OTOH, that can be said for most features - the next release of SVN could add new features, changing some nos to a yes, etc, so one can't really plan on what may happen. (as an aside, I asked sourceforge support about using web space for mercurial hosting, and the short answer was use SVN or CVS, and given the web space on SF isn't enough for crossfire, we couldn't use that for either Hg or Darcs even unofficially). So quick thoughts: CVS: path of least resistance, since that is what we are currently using. To continue using it doesn't preclude us from changing in the future. SVN: Only reason to switch to this is because sourceforge supports it - it clearly isn't the best choice in set of features, but is better than CVS. Still, probably not worth the effort of changing. Mercurial: If a good hosting service is available, this may be the best option. But hosting here is tricky - commits, at current time, seem to need ssh access (may change to https in the future). Free web hosting services may work, but only if unlimited bandwidth is provided and a common user account can be used (unique user accounts/user would probably be a pretty big security risk, as most likely anyone else with an account on the server could muck with the repository also). The one advantage of distributed SCM's is that the central repository isn't quite as key (eg, if it went away for some reason, the copy developers have is completely and could be used to make a new master repository, where as with SVN/CVS, the data just isn't there in the local repository) BZR: The two things it is missing to get a perfect score is efficient use of resources and support for symbolic tagging. As far as I can tell, BZR has no support for any form of tagging, so using 'branch' tagging would be necessary. The other issue is that it needs to make a new http connection for each file to pull. This may not be that big an issue for the server component (where there are not a lot of files), but this could make things really slow for arch or maps updates. That said, BZR is the most feasible solution right now (OTOH, launchpad.net web site has been down for maintenance for the past hour, so not sure how much better they are from a reliability standpoint over sourceforge) Darcs: Has the same lack of hosting as mercurial, and otherwise isn't really better in any regard, so don't see a very compelling reason to look into darcs. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] About a feature request
Just a note/thought: the reasoning for cursed spellbooks harming lowlevel players more is probably true for cursed objects in general. I doubt a mid/high level character is ever really hurt with cursed objects - they will detect curse/identify the objects. And even if they did apply one, easy enough for them to get a remove curse spell. But this then almost leads to the question - should cursed objects just in general be removed then? I think it adds something to the game, so I'd probably say it shouldn't be, but then by that same logic, it should get extended to more objects. One thought would be a setting for this - right now, some fixed percentage of objects are made as cursed objects. Instead of having that be hard coded, make it a settable parameters. Servers that want to be easy on players could set that to 0, so cursed objects never show up (except on maps designed for it). Servers that want things really difficult could set it higher. Some servers could set it to a very low non zero number (1%? .1%?) I think that setting is more interesting - cursed objects in general would be so rare you might not check for them, and thus get hit by them once in a while. Other random thoughts: If you are not sufficient level to learn a spell from a spellbook, it does not identify it for you - thus, you have no clue what it is. In order to be affected by a cursed spellbook, you must be sufficient level to learn the spell - a low level mage can't be hit by a cursed 20th level spellbook. If loss of spell is done, then the spell that is lost has to be less than equal to the level of the cursed spellbook (you can't lose a level 5 spell on a cursed level 1 spellbook). Or if you want to be more kind, it only removes the spell it is a cursed version of (a cursed burning hands would only remove a burning hands spell if you know it - if you don't, maybe confuses you for a while or some other effect). If the percentage of spellbooks that are cursed are low enough, this may not be a big deal - odds being that if you found a cursed spellbook of some spell, you probably found 10 uncursed versions, so even if you lose the spell, not the end of the world. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
