Re: [crossfire] Weather usability was: [Idea] Spells inmediate effects
It has some new bugs where things become blocking on reload too. Thus I flush my saved weather overlays every so often. This bug came after the new movement types. Oh I'd like to beable to set it so arrows, bolts, and shooting spells can traverse water. Could we have new movement types: arrow(or projectile) etc. projectile probably would be fine. I tried to do it my self hoping that the movement code used key value... :( --- Alex Schultz [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: Weather code is usable. I use it, albit on level 4 now. However there are still some bugs such as disappearing things, and in many ways the results are too extreme and granular. I am not sure, but for this, I blame extreme elevation values (which happen to be a little corrupted across bigworld, but too extreme anyways). In addition, the weather code is not usable in anything other than bigworld, as in, not usable for temperature and such in smaller maps. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Treasurelist idea
Well using set as a prefix would allow you to put whatever in the arch, thus one wouldn't need to edit the code every time a new variable is created since set just passes it into the archtype in memory. --- Alex Schultz [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: I was thinking (perhapse this is allready doable): treasure bla arch sword chance 20 magic 4 set damned 1 set wc -2 set msg set this is a great sword sed endmsg end If the code sees set then that which comes after it will be applied to the dropped thing Hmm, not sure it's the best way to approach the issue (i.e. do we even need to prepend set?), but that would in some ways be a good idea. Also, please don't use the reply button to start a completely new topic, it messes up those using thread view (I am anyways, and that's how people on the web archives often view it) Alex Schultz __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player-owner shop proof of concept
Player-owned, shortened form P-owned :) I think you should beable to set the buying price if you own the shop. --- Nicolas Weeger [EMAIL PROTECTED] wrote: But i'm afraid what happens when high lvl players sell quest items for very few platinums, and so soon many low level players maybe run around with those stuff... Or high level players sell stat potions very cheap so low level players have full stats very soon. Well, right now you can simply give a weapon to a player, so it's not that different :) Also, don't forget there is the item level, which should prevent low level players from using too powerful equipment. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] first bug discovered by unit test
Yay. There should be added some security unit tests aswell. --- tchize [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While am still preparing check framework for crossfire, i found a bug in common/shstr.c where query_refcount was returning wrong value. Fixed and commited. I hope unit testing will discover more of those still undetected bugs :) Tchize -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFFfEHHGOa1Q2wXwRAh24AKCAnbCQIhV7s8lHc/rWQWsiQ05DpwCg8a+l j9lkYAgdM+qrmtGnFsNUsVM= =/d7V -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ice Castle up for grabs.
(continued) Also I see you have alot of dirs in there, how are they to be? maps/onefang/(1.4,TEMP,AntFarm) maps/python/stuff arch/ ? --- David Seikel [EMAIL PROTECTED] wrote: On Fri, 6 Jan 2006 21:58:29 +1000 David Seikel [EMAIL PROTECTED] wrote: I really should have done this a long time ago. I vaguely recall announcing that my life was too busy to do any Crossfire work some time ago. The situation is the same, and I haven't even had time to patch up the Ice Castle and hand it to someone. So I've dumped it to a server, and who ever wants it can take over ownership of it. If no one wants it, feel free to steal stuff from it, as there are some interesting things in it. There is an IceCastle.txt file with some notes about what needs fixing and stuff. http://matrix-rad.net/IceCastle.tar.bz2 Although people have downloaded the file, there has been no feedback about it. Could be that everybody got distracted by recent threads. I'll pull it off my server at the end of the month as I have limited space and bandwidth on it. -- Stuff I have no control over could be added after this line. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] transports committed. (diffs?)
Does cvs provide diffs for this? I'm interested in this but don't want to also have to have that patch that was just applied that removes features. --- Mark Wedel [EMAIL PROTECTED] wrote: I've just committed the code to handle transports. Detailed information can be found in the doc/Developers/object under Transports, so I won't reproduce that here, but some quick notes: 1) I added a new movement type - MOVE_BOAT. This isn't directly related to transports, but using boats as a test transport type seemed most interesting to me and would test most of the features. The only terrain right now that allows boat movement is normal sea and deep sea. Shallow sea does not allow it. 2) Tranports should be fully functional as described in the objects file. However, several things were mentioned in the discussion which may not be there yet. 3) I added a couple boats to Scorn that acts as transports for testing. Since boats can't move to shallow water, and there is a patch of shallow water between scorn and the main oceans, this effectively limits the range of these boats. This is fine for testing. If that patch of water is changed, these transports should be removed, since being able to sail to most anyplace open up some areas too easily. 4) There is no form of ownership on transports. If you park your boat, someone else could go and take it and sail away. Much like real life. 5) Currently, no control on who boards your transport, and no way right now to evict them. 6) It is possible, especially with boats, for players to be stranded in the middle of the ocean - on the bright side, there is no drowning. The most sure fire way this can happen is that if you are on board a ship and you exit the ship and the ship sails away, leaving you behind. Going forward: More transport objects are needed. This should be easy to do, and some could re-use existing movement (a pegasus to fly on?). Graphics are also needed - the code does support the idea of different graphics based on if the transport have people on it or not (horse being a very obvious case). Some thought needs to be given on movement types for objects - we don't really want to end up with 20 movement types. Off the top of my head, quick suggestions: MOVE_WHEEL - for wheeled objects (carts, wagons, cars, whatever). These should be blocked from a fair number of objects (staircases, mountains, jungles, perhaps even hills and forest). MOVE_HOOF (MOVE_4LEG?) horses, mules, etc lesser limit of the above, but probably not allowed on staircases. MOVE_SWIM - already there. Probably shoudl be allowed in shallow sea, but IMO some special code is needed for this - chance of drowning, etc. Not that interesting enough, right now with the way transport code is, it is not possible to apply objects on the map while on a transport. Thus, transports are effectively prohibited from shops. The said, exits or other move_on objects should work OK. This actually works out pretty well when one thinks about it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] transports committed.
NM, the removals were only in the client tree. --- Mark Wedel [EMAIL PROTECTED] wrote: I've just committed the code to handle transports. Detailed information can be found in the doc/Developers/object under Transports, so I won't reproduce that here, but some quick notes: 1) I added a new movement type - MOVE_BOAT. This isn't directly related to transports, but using boats as a test transport type seemed most interesting to me and would test most of the features. The only terrain right now that allows boat movement is normal sea and deep sea. Shallow sea does not allow it. 2) Tranports should be fully functional as described in the objects file. However, several things were mentioned in the discussion which may not be there yet. 3) I added a couple boats to Scorn that acts as transports for testing. Since boats can't move to shallow water, and there is a patch of shallow water between scorn and the main oceans, this effectively limits the range of these boats. This is fine for testing. If that patch of water is changed, these transports should be removed, since being able to sail to most anyplace open up some areas too easily. 4) There is no form of ownership on transports. If you park your boat, someone else could go and take it and sail away. Much like real life. 5) Currently, no control on who boards your transport, and no way right now to evict them. 6) It is possible, especially with boats, for players to be stranded in the middle of the ocean - on the bright side, there is no drowning. The most sure fire way this can happen is that if you are on board a ship and you exit the ship and the ship sails away, leaving you behind. Going forward: More transport objects are needed. This should be easy to do, and some could re-use existing movement (a pegasus to fly on?). Graphics are also needed - the code does support the idea of different graphics based on if the transport have people on it or not (horse being a very obvious case). Some thought needs to be given on movement types for objects - we don't really want to end up with 20 movement types. Off the top of my head, quick suggestions: MOVE_WHEEL - for wheeled objects (carts, wagons, cars, whatever). These should be blocked from a fair number of objects (staircases, mountains, jungles, perhaps even hills and forest). MOVE_HOOF (MOVE_4LEG?) horses, mules, etc lesser limit of the above, but probably not allowed on staircases. MOVE_SWIM - already there. Probably shoudl be allowed in shallow sea, but IMO some special code is needed for this - chance of drowning, etc. Not that interesting enough, right now with the way transport code is, it is not possible to apply objects on the map while on a transport. Thus, transports are effectively prohibited from shops. The said, exits or other move_on objects should work OK. This actually works out pretty well when one thinks about it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9)
Why have you banned my CVS access, and why do you hate mlab? I just finished mlabhell and I want mlab in for 1.9. It's better to have it in non-dirified format for 1.9 then not in at all. Also I am offended at lauwernmark and errac's plot to change mlab's culture. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
I use the keybinding interface very often. I imagine others do too. --- Mark Wedel [EMAIL PROTECTED] wrote: Yann Chachkoff wrote: Briefly discussed on irc, but also related to other discussions, is perhaps what client(s) to use going forward. To me, at some level, keeping the gtk(v1) client about may not make a lot of sense. I'm not sure about that, at least not on the short term. The gtkv2 is far from complete IMHO. On the longer term, it is probably correct that the gtkv1 would get superceded at some point, though. But what at the main features that are missing? IMO, there is a lot of stuff in gtkv1 client that I'm not sure people use. One being the keybinding interface - do people use that very much, or do people just use command line. It doesn't make sense to add features that no one needs. Especially if we start going down the path of new character creation and other widgets - I don't look forward to trying to write those for the gtkv1 client. I know a lot of people still use the gtkv1 client. Well, I think it is actually more accurate to say that it is the most used one :). Yes, numbers back you up - from metalforge: GTK Unix Client 6 GTK Unix Client 1.5.03 GTK Unix Client 1.7.01 GTK Unix Client 1.7.17 GTK Unix Client 1.8.0 22 GTK Win32 Client 1.7.0 1 GTK Win32 Client 1.7.1 2 GTK Win32 Client 1.8.0 7 GTK Win32 Client 1.8.0 snapshot 19 GTK2 Unix Client 1.8.0 6 Perl Bot 1 X11 Unix Client 4 X11 Unix Client 1.7.02 X11 Unix Client 1.8.0 11 These numbers are correlated with client and ip address - this likely isn't 100% accurate (there is a delay between the client connecting and player logging in, thus getting IP address), but probably gives an OK estimate. The number could also be skewed - people playing that connect via DHCP will be counted numerous times, compared to those on static IPs. My most important complain is already well known: gtkv2 requires a 1280x1024 screen resolution, which is not available (or comfortable) on many screens. The resolution currently considered as standard is 1024x768 (a lot of laptops are limited to it, while a lot of 17''CRT monitors can only display 1280x1024 at rather low frequencies). Although I understand that people that got bigger screens would want a client best suited for them, let's not forget all those who cannot properly display such a big client: they'll have no other choice but quit playing, or deal with ugly things like virtual scrolling. I think that the problem comes down to the impossibility to reconfigure the client interface to suit your needs - not everybody needs/wants a 25x25 map display, for example; others may want to get bigger tiles instead of getting more. Before scrapping gtkv1, I think that the v2 must provide the same level of display configuration. I'll look into this. Note it really comes down to the map display area - if the map area is made say ~550x550 pixels (instead of the 800x800 right now), that you could either get 17x17 display with full sized images, or 25x25 with images resized to be 22x22, or something in between. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I don't want those abilities removed. Why shouldn't I beable to make a magic monster that can reflect spells or arrows that? Just remove the ability from the knights and gaurds and remove the reflecting amulet from circulation. I hate all this talk of removing everything from the game. Maybe crossfire should fork to crossfire-intact and crossfire-not-intact? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
Sea battles shouldn't go to a pocket reality, they should duke it out on bigworld seas and only if they get right next to eachother should the inside map(s (multiple levels on big ships)) of the other ship be tiled to the 1st ships maps. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I think a better solution would be to, rather then show every attack message, only show one every 1 second or so. Friendly fire is setable in the settings file and can be set low to compensate. --- Mark Wedel [EMAIL PROTECTED] wrote: But this is also tied to player speed. Unless you make attack speeds really slow, but that doesn't work will with current movement code - really, attack speed I don't think has much effect if it is slower than the players normal speed. So I think without some significant changes, hard to slow it down to the point you can read it out without some major restructuring. If we say the player speed is 0.5, that is still 4 attacks/second. I think to be at a 'readable' pace, it would need to be closer to about 1 attack/second. But you still want to move at a reasonable pace. So to do that 'slow' attack, you'd need some code restructuring - basically, you'd have to have a separate 'weapon_speed_left' variable or the like - if you try to move onto a monster, if your weapon_speed_left is less than zero, you just can't move there (right now, you'd attack the monster). I had suggested a long time ago adding something like 'damage factor' as a setting, which divides/multiplies damage done/received. This provides a convenient way to make adjustments without having to change all the archetypes and the like If we're going to start adjusting HP of creatures/players, I'd state a primary goal to be that monsters and players have more similar HP. One of the problems right now is monsters have so many more hp than players that targeting spells at other players become almost instant death. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Bigworld-ized pupland status?
What's the status on bigworldized pupland (IE: when is it going in?). /me awaits the glorious addittion. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I think we should have plots and reputation system in for 2.0. And a setting to show (by default) 1 attack message per second or so (rather then char punches once, and again, and SUPRISE again!). It would also be good if the int for hp, maxhp, sp, and maxsp (used for alters) was raised to int 32 (it's int 16 now, right?). I don't think we should mess with the amount of hp clients or monsters get nor the weap attributes. We may want to explore the use of regents or something for spells as talked about before (you need this before you can cast uber powerfull spell). More spells... such as circular spells (not 'nova spells', orbiting spells: ring of fireball, etc etc) might be nice too. Transports would be good too. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
Perhaps both the player and the transport should be damaged? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
One can't put unpaied stuff in a box and steal them, same would go for transports I'd assume. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities (compression)
A server variable could be set that turns on/off compression. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] move_allow attribute
I like this idea very much (though I would caution against giving players themselves a pass wall spell), I creates a granular permissions system that is appealing. --- Mark Wedel [EMAIL PROTECTED] wrote: Thinking a little little about transportation objects (boats, horses, etc) and came to the realization that at some level, a move_allow field is needed. The basic idea is that move_allow would override any move_block. The case I'm thinking about here is boats - players normally can't move on the water. While the move_block of the water spaces for boats in harbor could be changed so you could get on the boat, this doesn't work so well if you anchor your boat at some island. The code to handle this would actually be fairly trivial - basically, in the update position, move_block = ~move_allow This also allows for some other interesting things. For example, one could imagine creating a 'bridge' spell that goes over water - basically, it just acts like a wall spell, but has move_allow WALK on it. Passwall (letting you put holes in walls) would be another case. One question would be on how to handle slow_move attributes - should those get blanked out also. I'm sort of thinking yes - then you could also have a 'create road' spell to get through the jungle quickly. Thoughts? Questions? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] move_allow attribute
move_allow * would just add some more control over movement permissions so that one can more easily set what cannot and what can pass over the tile; more granularity. Theoretically, after this is added, spells can be created (such as build bridge, which could set move_allow walk on the affected water tiles and then spawn brige arches forward (if spells were allowed on said tiles ofcourse) that can use modify permissions. I would suggest, however, that (specifically) a passwall spell not be given to players (could be used in fire-walls for some things though etc). --- Alex Schultz [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: (though I would caution against giving players themselves a pass wall spell) As I understand it, with what Mark is saying, walls would have to explicitly be set to allow passwall. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I think you need to fork off crossfire and make your own project where you can do whatever you want. Perhapse crossfire-awsome.sf.net? --- Yann Chachkoff [EMAIL PROTECTED] wrote: I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). How about not removing things from the game, a novel idea, no? How about proposing an alternative to let's keep everything unchanged forever - a novel idea for you, wouldn't it ? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries
Check the CVS logs. I have stopped committing about a week ago. If you remove crossedit I will not restart. --- Mark Wedel [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I seem to see this ultimatum almost once a week now (do this or I leave) This carries no weight for me. I'm not going to program and make changes based on what one person demands to be done. Maybe you are the one that needs to fork off crossfire for your own use so you can do whatever you want with it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries
Lol. --- todd [EMAIL PROTECTED] wrote: I suppose this would be a nice perk and a big incentive to remove crossedit, but you've quit so many times before that it just isn't a reliable enough promise to base a decision like this on ;) Miguel Ghobangieno wrote: Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I think you need to fork off crossfire and make your own project where you can do whatever you want. Perhapse crossfire-awsome.sf.net? --- Yann Chachkoff [EMAIL PROTECTED] wrote: ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
One of the things we should do for 2.0 (note: we are not yet at 1.9) is try to decrease bandwith usage. For instance, some animations are cylical, and the server knows which ones these are currently IIRC. The server shouldn't have to send a update for every tile every time for cylical animations, the client should beable to work this feat IMHO. Also if we can make some commands that are 4 bytes long (north south etc) or other longish commands shorter that might be good too. (We should keep backwards compat here maybe thought, so if a client says it's not 2.0+ it gets to use the old, easier to parse, stuff). Plots should go in at 1.9 I guess. Crossedit could be gtkized for 2.0. or after. (I'm not against updating crossedit, I am against removing it). Maybe some new spells too? Circular spells ect (kinda like a circle of protection of fireballs spining around you etc). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Brace is used, as Leaf said before, to make it easier to swich deities without being pushed off the alter... this was allready discussed! We shouldn't do things that increase bandwidth usage... /me watches the bandwith usage skyrocket just to spite him. --- Mark Wedel [EMAIL PROTECTED] wrote: Brendan Lally wrote: I would suggest then, in no particular order: * client side display of parties (so that they can present an interface more like gcfclient2 has for the metaserver, removing the need for using the rather complex party commands directly). Yes - that sounds like a good idea. * adding more stats, including a number that could be considered as settings, so that clients can have a configure menu for them (imagine having a 'server' tab next to the general, map, and keybindings tabs in gcfclient) In order to do that, I think you would need to send output-sync short (byte?) output-countbyte I'd suggest the output-* stuff on the server should go away. That was put in before the client/server split IIRC. I think any collapsing/discarding of messages should just be done on the client. Granted, doing it on the server does save some bandwidth, but I can't see that as much an issue on current connections. bowmode byte mapped to associated requestinfo applymode byte mapped to associated requestinfo listen levelbyte is listen level really used much? I'd almost suggest this go away also, but right now, harder for the client to deal with it, since it isn't getting message levels. petmode byte mapped to associated requestinfo usekeys byte mapped to associated requestinfo Yes, all the rest makes sense, and wouldn't be hard to do at all. * I'd also want to consider removing brace altogether, or at least making it a flag in the stats so that it can be displayed client side (hitting brace by accident and not being able to move can be confusing). Brace could probably go away now. I believe there are other ways to get the same effect (ready melee weapon skill, and just fire in that direction) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Well Leaf said that it was so that if someone really wanted to recant their diety that they could, but they would have to mean it (not by accident, or by mere trifiling whim) and thus brace. A question I have is does brace have any ill effects. EX: if you are on a mover, and brace, does that stop you from being moved. If so then... well that's not supposed to happen and brace seems like it needs work, if not then nm. --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/29/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Brace is used, as Leaf said before, to make it easier to swich deities without being pushed off the alter... this was allready discussed! But since being pushed off the square is an intended effect, being able to brace to avoid that is probably a bug rather than an intended feature. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
I am not opposed to porting crossedit to gtk however. But if my favorite editor is removed outright... java is not an option. However crossedit works great (IMHO) now, so there really is no reason to change it. All this constant talk of removing things is displeasurable, thus my retirement for a time. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I am also waiting on some new features aswell. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. How about not removing things from the game, a novel idea, no? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
If crossedit dissappears then I dissapear. I guess that is what you all want though. Should CF fork? --- Mark Wedel [EMAIL PROTECTED] wrote: Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Negative Luck for pk
Hi, I've asked for just that configuration option before. I'll forward this mail to the mailing list so the other devs may see that this is a wanted feature. --- Logan Tygart [EMAIL PROTECTED] wrote: Hey Man, I enjoy the hell out of your server. I have a couple of characters there. (Funyuns and Cugel) but when ever you pk your luck goes down. Since the server has no rules, is there anyway to turn off that feature? The last couple of days, we have been having a pk fest on a character named killah. Logan -- Nam et ipsa scientia potestas est -- Sir Francis Bacon Registered Linux User: 277727 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
MWedel just talked about a complete redesign in his latest post. Things that are redesigned tend to be broken for 1 or 2 years. I could be dead in 1 or 2 years, so could any of us. I'd rather not wait around. --- Yann Chachkoff [EMAIL PROTECTED] wrote: I don't think it would be wise to remove the hacks, the hacks make things work as they should. Hacks are what the name imply: dirty fixes. By removing hacks, it simply means replacing them by something cleaner that does the same job. Which benefits from code clarity, ease of debugging, and probably performances as well. We already removed some in the past, so that's simply a restatement that the efforts in that should continue. If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. It is the exact place where to discuss about what we want to do with Crossfire, being maintaining it in its current state, expanding it or making it more generic. See the description of the list: This list is used for general discussion and questions, answers, and latest changes and updates. This is general discussion around the game, so that discussion is perfectly in sync with that definition. If you don't like it, don't answer to it - simple as that. Crossfire is a game in it's own right, I never said the contrary. we should be concerned with our game, not some theoretical developers who might want to make their own game. I'm not speaking about theoretical developers - I'm speaking about those who (hopefully) will still play with crossfire and its code long after we don't. I'm thinking about all the ideas that could get implemented much more easily on a cleaner base than on a patchwork of code. No, I don't suggest working towards a cleaner and more generic code just for the sake of a handful of theoretical developers. I'm suggesting it to make *our* own developments easier and faster, to have a workbasis that we can expand further than what can be achieved now. We have wonderful game mechanisms in most cases, that can rival or even outclass those of a lot of commercial (successful games). I think that adding a new spell or a new object type to Crossfire should be as simple as writing a new map, so that new gaming mechanisms can get quickly implemented and tested - I don't see this as the benefit of a few coders, but a benefit for all players, who wouldn't have to wait for ages to get bugs solved or new, interesting ideas implemented. Maybe you're satisfied with the rythm at which your proposals are tested and implemented. I am not, and I believe a good structure would speed the process up a bit. We have media, we are beyond framework. Nonsense. Just because we have code doesn't mean that its structure is of good quality, or that staying forever with it is satisfying. Given that you never had to add stuff in the Crossfire code, I suggest that you first try to do so, and *then* speak about your experience, as I really don't think you have any knowledge of the difficulties involved with the current codebase. Finally, I'd suggest not to introduce notions you obviously don't understand. By framework in this case, I was speaking about a structure supporting a style of game; or, if you prefer that term, a generic, structured core of functions. The Media/Framework model has *nothing* to do with that. I don't think there can be any sane debate if you don't even understand the terms used. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
I don't think it would be wise to remove the hacks, the hacks make things work as they should. If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. Crossfire is a game in it's own right, we should be concerned with our game, not some theoretical developers who might want to make their own game. We have media, we are beyond framework. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
We want to cross module boundries and there is no reason for us to want 3rd party module additions (unless one is pro-proprietary). Modules would do 2 things: disallow use of code across module boundries (as they aren't loaded yet), let proproprietary addons be created and work over more then 1 release cycle. Both are bad. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Yes, spagetti code, if that's what you wish to call it. Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). Modules would disallow this (bad) as they are not loaded untill they are called. Call it what you will but this is why subroutienes were invented (subroutines, in assembly, are basically gotos... :) ) so you didn't have to paste the same code everywhere. Oh and I just got a yamaha midi guitar (EZ-AG) :) (I now have a midi keyboard and a midi guitar :D, the keyboard is recognised by linux through USB and rosebud4, I still have yet to get a midi-cable-usb adapter which the geeetar needs). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Polymorph etc
Could add some circular spells like in diablo... the object to make that possible was added a few months ago. --- Anton Oussik [EMAIL PROTECTED] wrote: On 19/01/06, Mark Wedel [EMAIL PROTECTED] wrote: Anton Oussik wrote: On the note of adding/fixing spells, could some high level spells be added into CF, which need higher levels (like 40, 60, 80, 100) in a skill to be able to cast them? At the moment there is little point in levelling things like sourcery beyond level 15, when you can cast town portal. Either re-shuffling spells about or adding some more spells to fill the gaps would be needed for that. Reshuffling of spells may make sense. The current spell levels where set back in the days when I believe max level was much lower. I'd be a bit concerned about adding new spells that are even more powerful - a fair number of the spells are already pretty powerful at high levels, and adding more powerful spells doesn't necessarily seem like it would help things out much. And I think most spells already have pretty large areas of effect - making even bigger fireballs/cones are likely to get to the point where one spell covers the entier map. I did not necessarily mean more powerful spells. Some existing spells can get moved up the chain, and intermediate interesting spells can be added to fill the gaps, so a player always has a new spell just within reach. Either that, or spell could be made to not get more powerful with level, and then players could learn more powerful versions of a spell they already know, which would exist every 5-10 levels. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Polymorph etc
One could add new spells... like circular spells. --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/19/06, Anton Oussik [EMAIL PROTECTED] wrote: I did not necessarily mean more powerful spells. Some existing spells can get moved up the chain, and intermediate interesting spells can be added to fill the gaps, so a player always has a new spell just within reach. Either that, or spell could be made to not get more powerful with level, and then players could learn more powerful versions of a spell they already know, which would exist every 5-10 levels. The problem with that is that skills already scale with level, icestorm is one of the best cold spells at any level, because of how well its damage and range scale, so unless you want to nerf the scaling of all the low level spells, they are going to remain the best option, especially if the base level of the supposedly 'better' spells is increased, because then they will have fewer levels to scale over. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: Re: Re: [crossfire] Moving server towards a modularized system?
Well enjoy raping the server. I'm retiring from CF untill a certain unnamed feature I was promised 1/2 a year ago (no not plots) is in. See you soon or never. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Except that you are not working on one section of the code, you are restructuring the whole server into diffrent modules. This means that if you develop in cvs there will be breakage with any and everyone else as you sweeping edits touch every facet of the glory that is crossfire. Well, the required editing is, for the most part, moving existing code rather than change it. Algorithms will stay the same, execution paths as well, etc. What will change is the way various functions are called - so for example, calling apply(this_object) would become this_object-manual_apply(this_object) (This is only an illustration :)). Only in a few cases will new code be needed - mostly to bind the modules content to the code. So basically, you'd expect problems in: - The module loading/unloading (a clearly separate, specific piece of code); - Improperly converted calls (which can be avoided if we're careful enough). So no heavy breakage is expected. The C in CVS may mean concurrent but it doesn't mean perfect. I never said the contrary. It just means that no, even a refactoring of that scale wouldn't block the whole project for months, that's all. If you want to make the sweeping changes on your own system; enjoy. But please, before committing to cvs do extensive bugtesting so that it 1) doesn't make the code any slower, 2) doesn't break anything, and 3) maybe makes MS less of a hog? I think all Crossfire coders perform quite some tests before committing to CVS - nobody would want to be responsible of severely damaging the server. Simply understand that coders are not perfect, and that they cannot think about all possible cases. To take a recent example, there was a library-related bug in the new plugin code that I didn't spot on time; was that because I didn't test that bit of code ? Of course not - but on the architecture I was trying it on, it simply didn't exist. Also, let's not forget that the CVS codebase wasn't meant to be used on production servers: the CVS is (theorically) the repository in which the work in progress server code is stored. Stable versions are distributed in the various packages available on the SF website. Now, it is true that if some big changes are to be done, it would probably be a good idea to release a new stable version first, so that server administrators like you can get all the recent features without having to struggle through the possibly stability-threatening changes. Regarding possible performance issues, I think that there are ways to ensure that nothing noticeable happens. Most of the time lost would probably get when the plugin/module gets initialized and loaded - and that's unimportant for the running speed of the server. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
How about not modularizing and thus not having to make a trade off. How about not screwing up the server for months just because you are itchting for busy work. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Nothing currently prevents a plugin to modify the data it has access to directly - but of course, that's unsafe access, so if the plugin makes a bad modification to the data, or forgets to notify the server of it if necessary, then it will probably crash the server. Accessing data directly or through wrappers is basically a tradeoff between performances and security. In the case of modularization of the existing code, I'd say that direct access wherever possible should be kept - accessors for such data modifications would probably be used only for debugging purposes (as a wrapper can check if the data modification is legal or not, and thus can help detecting a whole range of errors). -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Did you not read my post. If you are screwing around with the code structure of the server then other programmers do have to wait untill you are done as they do not want their code to suddenly break when it intersects with your massive changes. You must not be at all experianced in these matters (as you indicated before in fingering crossfire for the sin of you having to grep through it). This will hold up usefull game development for months all because you and friends believe that you are above grep. --- David Delbecq [EMAIL PROTECTED] wrote: Le Mardi 17 Janvier 2006 02:51, Miguel Ghobangieno a écrit : I suggest you not implement a huge worthless code change that is nothing but busy work. I reject your assertion that cave's analogy is flawed as it is not. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. Why would other coders have to wait? Nobody did mention freezing the CVS at anytime. If you don't want to work on modularization, nobody forces you to do so, work on implementing new features. It's the sole responsability of the one modularizing a feature to ensure there is no conflict when he commits. When the commit is done, it's the responsability of other code to take into account this change. That's how CVS based development work. Crossfire had deep changes in code in the past (object based skills is one of the most recent). This has never prevented other people to do their change. That's the magic of teamworking. -- David Delbecq Royal Meteorological Institute of Belgium ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Why oh why do you want to do this useless crap? We have a real game, we don't have to make an engine. How about adding some new features rather then ripping the things apart. This is why I hate CF devel, rather then improving the game most suggestions are oh let's fuck shit up or delete this or drop that. How about adding things? It's fun, people don't get angry at you as you aren't breaking or throwing out what they've made aswell. tchize can you modulize the server? no? so how about not suggesting screwing it up for every other developer? Ryo? no aswell? This is busy work, it is useless, and it slows down game improvements. --- tchize [EMAIL PROTECTED] wrote: Le Mardi 17 Janvier 2006 06:12, Alex Schultz a écrit : Indeed. On this example, IMHO random maps are not optional, as they are essential to some quests, and also soon would be used by land plots (though land plots would in my opinion be a relatively good thing to implement as an optional-but-defaultly-on C plugin) IMHO they are optional, they are mandatory to use the current map set, that is true, but that just mean a random maps module is a requirement for using bigworld maps. I my opinion, those are optional, even if they may appear mandatory to run current maps. Imho it should even be possible to pickup the crossfire core and create a brand new world out of it. - communication protocol (should be interchangeable, it can be driven by object modification events in server, this also would help dissociate rules from socket events, it would make also easy to put several protocol modules, eg, one for bots or another one for a scorn webcam) - weather system (it's main architecture is, on a regular time do calculations and update world maps) - python scripting (is a requirement to run big world, but not to run server) - random maps, in a more general point, map loading / saving, this would give the possibility to have other means of generating maps and saving maps. We could think of separate modules for random maps, user specific permanent maps, underworld? (it has been suggested the underworld could be based on what exist on upper world) The fact is, a server would be able to start without map loading, without scripts, without communication protocol. It would just have a bunch of rules and nothing to do. But that also mean we could start it with only communication protocol plugged in and a dummy map loading module, this only in the purpose of testing protocol behaviour, maybe in an automated way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Current idea? I must have missed something, I didn't know you decided, above all the objections, to go ahead and rip apart the server anyway. I will be waiting for my 3 thousand dollar cheque in the mail (along with everyone else who would like to add new stuff to CF but will have to wait untill you tire of ripping apart the server and revert the CVS tree). Why should all work have to stop because YOU want to restructure the server.. because you can't figure out grep... --- tchize [EMAIL PROTECTED] wrote: Le Mardi 17 Janvier 2006 18:15, Brendan Lally a écrit : On 1/17/06, Mark Wedel [EMAIL PROTECTED] wrote: True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. Things written in other languages then C should always be considered as optionnal. This is the case of python scripts. They are usefull but not all platform do support them very well. In all cases, things like writting a plugin in C++ or Fortran or ADA or anything else should require prior discussion on ML. It's too early for a discussion about languages in which plugins are written. I understood the current idea is to move C code to plugin still in C (just structural reorganisation). -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient options deathlist
Yes, it would be best to remove that option from the menu IMHO. Could we also make quit ask the person if they really want to delete their character (and then ask again for confirmation)? (server side). --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/17/06, Rick Tanner [EMAIL PROTECTED] wrote: Would it be OT or out of scope to ask for the File - Quit Character option in the menu to be renamed to File - Delete Character ? Well, it wouldn't be if you instead suggested that the menu entry be removed altogether. I'm inclined to think that the better option, it isn't as though the quit command should be used particularly often. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
I have to do the same thing when I am adding things to my perl rpg (which is not smaller in lines of code then crossfire). It's not a big hassle, and how else will the code know what's going on? Use grep. --- tchize [EMAIL PROTECTED] wrote: Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit : Throwing in my two pennies: In general modularisiation of the code will improve maintainability, That's also my opinion. On the other hand modularising the code will result in many changes, may introduce new bugs into the code, and is in general a lot of work whilst the benefits are questionable (this will only be useful if core is really small and most things are out in modules which can be configured at configure stage). If someone has a desire to do all that they are welcome to (it is an open source project :-) ), but in my opinion implementing new features would be more beneficial to the project. Speaking of my experience with crossfire code. I have developped a few add-ons to crossfire in the past (don't remember the list). From my point of view, adding new features in the code is currently a pain in the ass. I have dropped features add-ons which took me lots of time simply because it has become nearly impossible to find something in the code. If you add a new arch type, you have to register it in a define list, register it in the movement function if it is active, register it in the attack code if it can attack player, maybe register it with weather system if it can interact with it, register it to spell casting system if, for example, it represents a spell modifier. Can you imagine today creating an item which has as characteristic 'owner can walk over water' without modifying piece of code everywhere? In a modularized system, you could have something like that (it's just an idea, it still has obvious flaws in aglorithms) when trying to move object from squareX to squareY, you trigger a move_request event on squareX listeners, on squareY listeners and on object listeners. Each listener can respond with NEUTRAL(0), ALLOW(1), REJECT(-1) if there is an allow, then allow movement else if there are no reject then allow movement else refuse movement water would be REJECT non swimming obj, your item, registered in player when applied) would allow on every square with water. The exact same idea can be used to create complex check_inv, confusion spells, director, no_movement traps . You just 'plugs' in the movement code. Also this system can improve server performances. Currently, one of the main 'lag' problem of server is meteor swarm in the open areas. thousands of fire elements are checking the object list on a given square (that is other fire elements) at a given tick, and this until fire dies a few seconds later. Now imagine this. create a 'fire' arch at square X. When inserted, arch code register a move_event for the square and also analyse immediatly content of square. when new things are added to the square, the fire can check immediatly if this item can burn. Most of the time, there is nothing to burn. when the fire element gets activated avery X ticks, it does not have to explore a list of 100 other fire object to know there is nothing burnable where it belongs. Saying it's more important to add new features than modularize the code is simply a short term view. Since am part of this projects, i saw new features coming on a regular basis. Today the code, imho, is far less maintanable then it was 5 years ago. And if we continue to focus on features without architecture the code will be a blotted piece of unmaintanable code in a few years. If i remember well, Mark Wedel already had in the past to request from developper they spend more time on fixing the server code then add new features. There are tons of features in code map maker simply don't know about. Moreover there are tons of security issues in the code. They could be isolated and identified far more easily during a reorganisation process. I hope we will ge to an agreement on this subject. If you are going to go ahead with it, before you do anything to the code you will need to define what goes out to what modules, and what depends on what. Since CF was not designed to be modular you may also find recursive dependancies which will need resolving first. But I suspect you knew this already... ___ 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around
Re: [crossfire] Moving server towards a modularized system?
That is what the hurd project thought at the begining, the reality is diffrent. --- tchize [EMAIL PROTECTED] wrote: You forgot the other important point, modularity reduces speed of development, sometimes catastroptically, you only need to look at GNU Hurd for an example of that. i see the exact opposite of behaviour at work. Project initiated in a modular way, or migrated to a modular approach are easier to manage for the following reasons 1) You don't need to have knowledge of how the whole code works to be able to work on parts of it 2) You can isolate changes in only a part of the code It strikes me that crossfire is (still) not yet mature enough to have a fixed interface to all the modules that would be used, only a couple of months ago all the python scripts were broken by a plugin change, and I know I for one wouldn't want to attempt to fix the weather 'module' the next time the interface to it was broken. Architecture must be handled from the very beginning and currently there is no architecture design on crossfire project. A way to structure things here is suggested. This may not be the best approach, but it's far better then what we currently have. And nobody in the last year did propose anything to fix architecture problems in crossfire. And in modularized projects, the interfaces between modules are not always clear, they are not fixed and would probably never been. Some code migrate from one module to another after experience show it is needed nearer to the core, or on the opposite, it get further from the core because it is not as multipurpose as we may have thought in the begin. Some modules sometimes get gathered as a unique module. Some other gets splitted in sub modules. That's the lifecycle of a project. It works, and well. Yes sometimes there are clash, sometimes a very big change in a module is a pain in the ass for all people using the modules. But considering the gain, in development speed, in code learning curve and bugs hunting, it is clearly worth it. You argue a change in 'core' could interfer with 'weather' and you don't want to fix weather if it gets broken by that change in core? Well i claim, with current organisation of code, a change *anywhere* in code (not only what we could define as core) can break the weather. (Or potentially break anything else). That is something a modularized approach tends to prevent as much as possible. And am not speaking of compilation here. Compilation problems are easy to solve. You could argue, currently, you can't make a change in core that would make weather uncompilable, which with a plugin system could be possible. But, this is not a difficult fix, the most difficult bugs to fix are those which let the code compilable but with subtle invalid logic. And the last one happends a lot in crossfire. regards ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Try not to dismiss things solely because they disagree with your opinion. Modularizing the server would create a ton of problems, breakage, and solve nothing and add even less: it is busy work. If you must be busy be busy on some new feature rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Things you can help add: plots (with red). drunkeness. work on regional fiat currencies. pilotable boats (new arch in addition to the exit boats we have), horses, etc. perl plugin? --- Yann Chachkoff [EMAIL PROTECTED] wrote: Le Lundi 16 Janvier 2006 18:47, Miguel Ghobangieno a écrit : That is what the hurd project thought at the begining, the reality is diffrent. The Hurd project thought a microkernel architecture was interesting for reasons other than maintainability. It is also a stalling project for reasons unrelated to the concept of modularization itself. If you're to use examples to illustrate your thoughts, try to use one you really know and have an in-depth understanding of. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Polymorph etc
About polymorph, I'd like that spell to be fixed/redone rather then removed. Would this be possible? (I suggest doing it the nethack way, the users doesn't have controll of what he morphs into and he morphs into a few things during the course of the spell). I also see no point in making working things plugins, it will make things slow, break things (and then it will be like most servers (IE: not MF) don't use this, it's broken, let's chuck it). If Ryo etc want to work on something, as it seems he's itching to do, how about add a alchaholpercent variable and add the ability to get drunk? Or perhapse fix earthwall and the invisiblity spell ( tracker)? Better to fix what's broken then fix what's working (rather then break it and slow the server down). If someone want's to write plugin stuff how about add perl to the list of CF scripting languages? Any of these things would be a much more usefull waste of time, rather then breaking the server and slowing it down. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
It is not half broken as far as I can tell. Yes it's not running on MF, that doesn't mean it's broken. It gives few problems on Cat2. This whole thing is about slowly dumping whatever MF doesn't use. Open your eyes, the 2nd biggest server runs weather code at it's most extreme, in terms of players that's not a few. (Sure most servers don't run weather, but most servers are at 0 players also). --- Nicolas Weeger [EMAIL PROTECTED] wrote: I personally don't see much reason to rewrite existing code that is working fine as a plugin. There are just enough things that could be/should be done than rewriting working code doesn't make sense. As Yann said, i was not really mentioning rewriting stuff - apologies for the confusion. Weather system, for instance, could be put in a plugin, and still retain its functionnality - talking about it because it's currently half broken, and not always enabled, depending on servers. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
I suggest you not implement a huge worthless code change that is nothing but busy work. I reject your assertion that cave's analogy is flawed as it is not. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. --- Yann Chachkoff [EMAIL PROTECTED] wrote: Try not to dismiss things solely because they disagree with your opinion. I dismissed a flawed analogy, based on wrong technical assumptions. It is not an opinion point, but rather the rebuttal of an out-of-topic flambait. Modularizing the server would create a ton of problems, Tons ? Name them, then, and we'll have something to debate. breakage, Just as there is with *each* code change. Are you suggesting that we stop changing the code ? and solve nothing As I (and others) argumented, it eases a couple of development issues. It could be a flawed view - but then, demonstrate it, and suggest other solutions. Note that those points weren't based on air, but on significant experience in other projects, not on taste or other egocentric or sentimental feelings. and add even less: it is busy work. If you must be busy be busy on some new feature Given that you are not a coder, you have no right to decide for me what I should work on (Note that I usually don't follow such a philosophy - but since you expressed the exact same reasoning not so long ago, I find it appropriate to provide the same kind of answer now). rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Why ? I see a rant based on a pure sentimental feeling from somebody who has little knowledge of the Crossfire code, or of C coding in general. Provide technical arguments, and we'll have a serious discussion. If you cannot, then stop spamming the list. Just as a side note, scrapping the whole code has never been the intend. Next time, try to understand the emails you read before flaming their content. Things you can help add: Out-of-topic - we're discussing the pros/cons of modularization, not about your personal wishes about the code. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Polymorph etc
When you break the server with this plugin idea besure to send us all 3 thousand dollars. :) (sarcastic smiley face). If it's going to be like that it goes both ways. --- Nicolas Weeger [EMAIL PROTECTED] wrote: If Ryo etc want to work on something, as it seems he's itching to do, how about add a alchaholpercent variable and add the ability to get drunk? Or perhapse fix earthwall and the invisiblity spell ( tracker)? Better to fix what's broken then fix what's working (rather then break it and slow the server down). If someone want's to write plugin stuff how about add perl to the list of CF scripting languages? Any of these things would be a much more usefull waste of time, rather then breaking the server and slowing it down. Sure, i'll do it - lemme just confirm the money has correctly been transferred from your account to mine :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient options deathlist
Update about cached images, if we have checksumming (not sure if we do) that will update the cached image if said image is out of date, then cached images should be set to on as that will decrease bandwith usage. --- Brendan Lally [EMAIL PROTECTED] wrote: I have been poking around gcfclient recently, and found a lot of options that seem to be at best of limited use, and possibly never used by anyone, so what I have done, is created a list of the options in gcfclient's settings menus which I believe are unused, or always set to the same value. I am going to list the option, as well as what I think it should be set to. If anyone wishes an option listed here kept, they can reply claiming their use/need of it. If after 2 weeks, no one has 'claimed' an option, then I argue that it can be assumed to be safe to remove. As long as each change is made as a seperate CVS commit, it is still going to be relatively easy to revert any such changes made, should someone wish to have a setting return: The list; Automatically re-applies a container when you use apply to close it. If off, when you use apply to close the container, it stays unapplied - set to always be on Colored Inventory Lists - set to always on. Colored Information Text - set to always on Options on how to display resistances: - remove all options, set to Display all resistances in a single column, will use a single scrollbar. Print Grid Overlay (SDL only, Slow, useful for debugging/development) - set to off Cache Images - set to on Split Information Window (Takes effect next run) - set to on ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient options deathlist
Yes, it would be best to remove that option from the menu IMHO. Could we also make quit ask the person if they really want to delete their character (and then ask again for confirmation)? (server side). --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/17/06, Rick Tanner [EMAIL PROTECTED] wrote: Would it be OT or out of scope to ask for the File - Quit Character option in the menu to be renamed to File - Delete Character ? Well, it wouldn't be if you instead suggested that the menu entry be removed altogether. I'm inclined to think that the better option, it isn't as though the quit command should be used particularly often. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] (Python) script distribution
Assume everyone will want them. If a person spazes out for downloading 2kB of extra stuff ... who cares? Not I, nor should you. --- Nicolas Weeger [EMAIL PROTECTED] wrote: Hello. There are a few (Python) scripts i'd like to write, to extend Crossfire. Merely thinking something like a visit card system (to let other players know your level or skill), or something to autorejoin party at login time. So I'm wondering where to put those scripts. Should I put them in the python subdirectory in maps, and assume everyone will want them? Should we create a new subdirectory with optional scripts? Should I put'em on some web page and let interested people download? Note that this can in some ways apply to existing scripts (occidental stuff scripts, for instance). I'd say either put in python subdir, or create a new subdirectory - it's the simplest way to distribute things imo. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Why? That's just extra useless busy work. You could code in drunkenness (see previous post) if you're itching for something to do. --- Nicolas Weeger [EMAIL PROTECTED] wrote: Hello. I'm wondering about moving some parts of the code to plugins. IMO things like weather system (excluding darkness-related things) could be moved to a plugin, and just hook to server core. Random maps generation too could imo be moved. (particularly weather, as it's really optional, setting for that). Actually, shouldn't the server be just a core with basic rules, and everything else moved to plugins? Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Does crossfire now support partial tranparancy of PNG?
I noticed that the edges of the puddles archen were alpha blended (THOUSANDS OF EXCLAIMATION POINTS AND ONES). It displayed correctly in the GTK-Too(?) client on my box. I wish to make the puddles more transparent so you can see the floor better (as it is a puddle..). Does CF support partal alpha now? __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire nolonger compiles
(Random map crash bug) Resolution: Works For Me Ragnor may have fixed it, I heard he was working on it. The details are there are 3 random maps that exit to the same map. When you go into a 4th random map the server crashes, I know it's a server crash because when I went back on other players shouted Mike!! :P. Why use 3 random maps? Because there are a few bugs in the generator so that sometimes the path gets blocked (key not given for a door etc). I use 3 paths to important areas so the likelyhood of the player getting stuck is diminished. --- Andreas Kirschbaum [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: [...] Filed bug report at http://sourceforge.net/tracker/index.php?func=detailaid=1399546group_id=13833atid=113833 Also crossfire server crashes if a player enters four random maps in quick succession. http://sourceforge.net/tracker/index.php?func=detailaid=1398239group_id=13833atid=113833 Please do not duplicate these bug reports here. It is not useful because developers automatically receive a mail whenever a tracker item was added or modified. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire nolonger compiles
ranlib .libs/cfanim.a creating cfanim.la (cd .libs rm -f cfanim.la ln -s ../cfanim.la cfanim.la) make[2]: Leaving directory `/home/cfserver/cvs/crossfire/plugins/cfanim' make[2]: Entering directory `/home/cfserver/cvs/crossfire/plugins' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/cfserver/cvs/crossfire/plugins' make[1]: Leaving directory `/home/cfserver/cvs/crossfire/plugins' Making all in devel make[1]: Entering directory `/home/cfserver/cvs/crossfire/devel' gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -DDATADIR=\/home/cfserver/cfservernew/share/crossfire\ -DCONFDIR=\/home/cfserver/cfservernew/etc/crossfire\ -DLIBDIR=\/home/cfserver/cfservernew/lib/crossfire\ -DLOCALDIR=\/home/cfserver/cfservernew/var/crossfire\ -DPLUGIN_SUFFIX=\.so\ -g -O2 -c devel.c /bin/sh ../libtool --mode=link gcc -g -O2 -o crossfire-config devel.o -lcrypt -lm -lnsl mkdir .libs gcc -g -O2 -o crossfire-config devel.o -lcrypt -lm -lnsl make[1]: Leaving directory `/home/cfserver/cvs/crossfire/devel' Making all in crossedit make[1]: Entering directory `/home/cfserver/cvs/crossfire/crossedit' Making all in include make[2]: Entering directory `/home/cfserver/cvs/crossfire/crossedit/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/cfserver/cvs/crossfire/crossedit/include' Making all in Cnv make[2]: Entering directory `/home/cfserver/cvs/crossfire/crossedit/Cnv' gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvUtil.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvBrowse.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvNotify.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvMenu.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvFiles.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvPath.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvPrompt.c CnvPrompt.c: In function `CnvPromptCb': CnvPrompt.c:37: parse error before `char' CnvPrompt.c:38: `t' undeclared (first use in this function) CnvPrompt.c:38: (Each undeclared identifier is reported only once CnvPrompt.c:38: for each function it appears in.) make[2]: *** [CnvPrompt.o] Error 1 make[2]: Leaving directory `/home/cfserver/cvs/crossfire/crossedit/Cnv' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cfserver/cvs/crossfire/crossedit' make: *** [all-recursive] Error 1 Filed bug report at http://sourceforge.net/tracker/index.php?func=detailaid=1399546group_id=13833atid=113833 Also crossfire server crashes if a player enters four random maps in quick succession. http://sourceforge.net/tracker/index.php?func=detailaid=1398239group_id=13833atid=113833 __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] ...shouldn't one get drunk from wine and booze in CF?
...shouldn't one get drunk from wine and booze in CF? mikee1988098048 (perhapse a intoxication var which can be 0 - 200 (ie: proof), .. or 0 - 100 (percentage of alcahol(sp), then you could use int8 and save some bytes) Rednaxela I think drunkeness would be a neat addition to crossfire =P mikee1988098048 I'd like if it would slur your speech depending on how drunk you were mikee1988098048 like when you did mikee1988098048 say mikee1988098048 or shout mikee1988098048 or tell mikee1988098048 etc mikee1988098048 it would make it sound drunk mikee1988098048 and if you got really drunk you would walk like you were confused mikee1988098048 (and throw up) Rednaxela Yeah XD Rednaxela drunkenness could be implimented as a non-contagious disease that one can't gain immunity to mikee1988098048 yes mikee1988098048 but that's alittle hacky Rednaxela True, but it would work mikee1988098048 since you shouldn't get it after 1 wine or beer mikee1988098048 should only get it after a few mikee1988098048 (and more then a few if your food is full (full stomach)) Rednaxela It might be possible to make only a certain precent of the bottles have the disease, but that wouldn't simulate the cumlative effect mikee1988098048 couldn't the key-value thing be used for the intoxication var Rednaxela So yeah, as it's own feature would probably work nicer mikee1988098048 or maybe it should be called alchpercent mikee1988098048 alchaholpercent rather, as alch could be confused with alchemy Rednaxela it could __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Lalo's Bigworld pupland :D
I strongly prefer keeping the poles as is. As they are now they are at poles on the map. If you're going to add to the magnetic north of the contenet(spelling error) could you also add water to the west so we keep having a square map. Having parts of pupland cold doesn't bother me much... what you could do is shift the important parts magnetic east. There are beach/vacation resorts in new jersy for some reason, even though it gets cold sometimes. Also could you test to make sure weather 5 works well etc (including the generated pictures). It may need a little revamp to recognise the new stuff. Crossfire's world, if it even is round, has it's axis at 45 degrees but it's magnetic north at 0 degrees. The old empire relied heavily on compasses, a technology first imported from the conqured region of Navar (navar was an outlying province then... they broke away since... like most areas). Magnetic north came to be known as simply north. People usually don't venture into the strange super cold regions of the world, and take little note of true north. --- Lalo Martins [EMAIL PROTECTED] wrote: And so says Miguel Ghobangieno on 06/01/06 13:25... Pupland won't fit on the worldmap, which, IMHO, is fine as I've always thought of it as another contenent. It is in another continent, and it is in the worldmap. There is a reason why the worldmap starts at 100_100 :-) if you read the info in maps/Info, you'll see mwedel's idea of how big the world could potentially be. Right now, my Pupland is in tiles world_075_023 to world_104_032, so, northwest of the Scorn continent. (In the previous thread we had about geography, I think we agreed that the Scorn continent is in the southern hemisphere, so this one is in the north.) So there is weather, but, hmm, :-) I put it on northwest because I thought the poles were on NE and SW, so this wouldn't affect the weather on the other continent too bad. But it turns out, seemingly, the poles are on NW and SE instead, which puts Lone Town pretty near one of them. This is not what I intended. I could move it to the NE, but then that would break the antarctic. So I see two options: 1. leave it where I put it; this will make things in the NW of the existing continent warmer than they are now, and things in the SE colder - notably Navar. Lone Town will be a very cold place. Well, that may explain why it's so Lone :-P I'm running the scripts from cfmaps.schmorp.de as I write this, when I have a browsable version of the old continent, I'll post the url here. The reason I don't like this one so much, is because the Rainbow Islands are supposed to be tropical, or at least warm temperate - they are a beach/vacation resort after all. 2. change the weather code to put the poles somewhere more reasonable. We could be very revolutionary and put it, oh, I don't know, in the north and south? Or follow Exalted, rule that one direction (S or E?) is cold, another (N or W?) is warm, and the world is really flat, or even cylindrical. Or, my personal favorite, a reverse-discworld approach - the world is flat (rectangular or discoid) or even cylindrical, the outer edges are cold, the middle is warm. Any of these would require small changes to the weather system; not only to change the poles, but also (and almost more importantly), to know exactly how big the world is, and fill any tiles it has no map for with deep ocean. I believe I could do that without breaking the code too much. (Alternatively, just generate actual maps filled with deep ocean, this gives us the bonus of having more varied elevation.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
Oh that sounds good. I'd also like to have valued_as gold18k, gold14k, and gold10k (nuggets are not pure gold by weight as it is (good idea IMHO, makes sence), so we need those aswell). gold18k etc should be computed by gold/(whatever it's ratio is). --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/4/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: this would be looked up and the value computed. That way you could have flucuation gold etc values. if you add a valued_as then value should be ignored completely. But if you combined the two, it would be useful for many more items. Whilst a gold bar or gold dust would probably have value zero, a cursed gold ring should have that gold value minus an amount representing the badness of the curse - and making it worth melting down - of course the melting process shouldn't be entirely efficiant either That would allow both the price of gold bars to vary and the price of gold items to vary too ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
Yes I know, it's a buyers market right now :). Silver is, however, getting rarer. It is believed to be only 2 or 4x as abundant as gold now as the silver is used up as a rapid pace in industrial processes. If you want we could up silver to 2:10 or maybe even 4:10 rather then the 1:10 it is now and put copper at 1:10. Your thoughts? If you want to do this I'll be happy to change the archtypes. Someone will need to change the bank exchange tables though (I'll do mlab). So should we keep it at 1:10. Put it at 2:10 or 4:10 ? (or 3:10 ? (odd numbers are unfun at division though)) --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/2/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Changing the value of the metal coins isn't doable as silver has a set weight to value ratio... Well, today silver has about 1/80th of the weight to value ratio of gold. So changing the relative prices is certainly possible. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
gold and silver coins are not fiate currencies, their value can't be just inflated. You need paper money for that (or money who's value is more then the value of the material). I won't support inflating gold and silver etc. I will support creating paralell fiat currencies, and yes they did exist in the ancient world. --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/3/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: So should we keep it at 1:10. Put it at 2:10 or 4:10 ? (or 3:10 ? (odd numbers are unfun at division though)) I'm inclined to think that if this is going to be done, then their would need to be a currency system independent of the values of the individual coins. Instead of using gold, silver and platinum, define a unit and one or two subunits, give them absolute values, and then make gold, silver and platinum coins worth some value relative to that. (maybe even a sliding value) so, if we take something like the old spanish system, where there is the dollar/peso, (or 'pieces of eight' as they were called), each being worth 8 reals, which in turn is worth 85 maravedíes (depending on /which/ real you are refering to, but you only need to pick one). In that case then, value 1 would be a maravedies, prices would be given in terms of dollars, reals, and maravedies, and silver gold and platinum would have values that floated about that, with a whole slew of other coins as well. To extend this line of reasoning further, if these were tied to areas of the game world, it would allow macro-economic effects, as various currancies became debased due to economic pressure (something that happened quite frequently in the past - the real was originally 3 maravedies). This would also lead to a somewhat evil way to control wealth acquisition, just hyper-inflate the coinage or commodities most of the wealth is being stored in. (not that anyone would do that of course.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
It would be nice to beable to set in for instance: Object goldbar name goldbar weight 1 value gold Object goldcoin name goldcoin weight 10 (or whatever it is) value gold that way the value will be * by the current value to weight ration (in thiscase 1/1) --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/3/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: gold and silver coins are not fiate currencies, their value can't be just inflated. You need paper money for that (or money who's value is more then the value of the material). I won't support inflating gold and silver etc. I will support creating paralell fiat currencies, and yes they did exist in the ancient world. Ah, but now you have to consider what is actually fluctuating. Is it that the value of gold is dropping, or the value of the currency is increasing. In recent history, it has tended to be the case that fluctuations in the prices of gold/silver etc, have overwhelmingly /not/ taken other prices with them. Just because the US dollar weakens against gold (or if you prefer that gold strengthens against the dollar) doesn't mean that the price of bread alters. Certainly it is fair to say that gold has traditionally been quite consistent with reference to other commodities but silver-backed currencies (and especially silver-backed currencies with a debased coinage, which is what I am describing here, rather than fiat currencies) have fluctuated over time with respect to the price of gold. Whether you make the 'value' field relative to a fixed commodity, or a currency, is really an irrelevant point, once you have the same relationship between them being expressed, however, if we take the consumer's-eye view of the economy, prices are significant relative to wages, which are fixed in a currency, not to a commodity that few of them will ever trade in (plus it involves modifying fewer object values). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
:( The value of a gold bar shouldn't be it's setvalue and gold spot combination. It should only be the gold spot. That won't work. Also we shouldn't use the materials thing for value. --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/3/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: It would be nice to beable to set in for instance: Object goldbar name goldbar weight 1 value gold Object goldcoin name goldcoin weight 10 (or whatever it is) value gold that way the value will be * by the current value to weight ration (in thiscase 1/1) This is an interesting idea, and one I hadn't thought of before. Probably for ease of parsing however, it would need to be a new property 'valued_as'? maybe that should be in addition to the value field? For example, a gold necklace might have a fixed value based on the workmanship of the necklace, plus an inherent value based on the weight of the gold. The final value then would be the combination of the two. This would also scale nicely to enchanted weapons and the like. For example a sword could be valued_as steel, with a value of 20 (say) but a sword +1 might have a value of 1000, and a sword -1 a value of -500 (this would require negative values, but allow in principle that a player could make money by melting down cursed items, and reforming them. The questions then become, is it better to hijack the 'material' value for that, and what effect would that have on the things that material is currently used for? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
Changing the value of the metal coins isn't doable as silver has a set weight to value ratio... Perhapse it is best to forget about copper coins. --- Mark Wedel [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: I suggest an addum to the mappers handbook don't put jade and amber coins in you duengons as rewards. Then will come the question why have them then! Well then why have most of the things we have in CF? We could probably chuck most of our archtypes.. why even have CF? CF isn't needed in the world etc. Updating the map guide could be done. I just wonder how many people read it :). That said, the map check scripts could be modified to look for unauthorized arches also - some cases may be acceptable, but noting that jade coin appears in map xyz coudl still be useful. I'd also like copper coins, this will require value to have decemal points. Could we do that? IMO, no. There will always need to be a minimum value, and keeping that minimum 1 to me makes perfect sense. Adding decimalization adds a fair amount of complication, and as is, a value 1 object really isn't worth anything. I'd much rather go the approach of revalueing the existing money. Make the new copper coin worth 1. Make silver coins worth 5. If gold (10) and platinum (50) coins keep the same value, such a change in valuation isn't likely to affect things very much (unless players make huge piles of silver to anticipate that change). Or perhaps one that seems like more a hack but wouldn't have that problem - create 'new' coin - new copper, new silver, new gold, new platinum, etc coins as new archetypes. Put whatever valuation you want in them. Update treasure lists (and perhaps maps, but I'm not sure how many maps actually have coins piled on them) Maybe change the existing coins to be 'old' coins or 'ancient' coins. Thus, all new coinage that shows up should be these new coins with new valuation. However, those old coins still exist and can still be used with no inflation in value, so a player that has stockpiled piles of them doesn't get anything more from them (and if they find them in maps or something, not a big deal - old coins sitting in a dungeon wouldn't be that odd). I say all this because, as I've said before, at some level, you need a minimum value on objects. You can't use floats to store value because the precision for high/low values isn't there, and you'll get into all sorts of errors. So the only way to do this is what Brendan (I think it was) described, which is to multiply and divide internally. But even then, you are still stuck with some minimum, based on the multiply/divide values that are set up (if for example it is 100, then your minimum value is .01 - anything less is lost). But really, it comes down to the fact (to me) that a value 1 object is pretty nearly worthless, and I can't see need to have stuff worth less than that. So this really becomes a matter of a new coin standard, and that can be done with just archetype changes, which to me seems like the much better way to go. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
The regional coins shouldn't be made of valuable materials such as gold then. Copper would be better. --- Lalo Martins [EMAIL PROTECTED] wrote: And so says Miguel Ghobangieno on 01/01/06 01:50... The regional currencies should be paper money rather then coins. I don't think paper money would make sense in the CF world... it's too recent a concept. What I'm talking about is coins as opposed to pieces - a gold coin is a small disc of gold with some image, number and words stamped in it, and is official money issued by a country. It's supposed to be worth more or less the intrinsic value of the gold in weight, but not always. On the other hand a gold piece, often used in fantasy worlds and ancient real world, is what we have now; a small disc of gold, not coined. It's only worth its intrinsic value - by weight. While regional currencies exchange values could change depending on factors that are not in the game yet the silver, plat, gold, jade, and amberonium coins should keep their absolute value forever. If they are pieces rather than coins, yes. Whether they are accepted in shops or you have to sell them at a bank, is more or less what we're discussing. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] shops and stealing
hv: remeber, each server has diffrent rules. PKing and abusive behavior is 100% happy-good on Cat2 while it is outlawed on MF. Hardcoding jail for such things would be bad. --- [EMAIL PROTECTED] wrote: Mark Wedel [EMAIL PROTECTED] wrote: : For a long time, the thief skill stealing has been available, but the only use :was the limited ability to steal from monsters. : : With the addition of new fields in the map header for shops, it'd seem like it :would not be possible to extend stealing to shops. Not that the current headers :are really in any way useful, but in a sense, because they sort of give an :example of extending the shop attributes. : : What I'd suggest then is fields like: : :steal_adjustment: Represents how hard/easy it is to steal from this shop. A :positive value denotes it is easy, negative value means it is hard. : :max_steal_value: Maximum value of an object that can be stolen from this store. : Thus, if someone drops a 10,000 pp item in a shop easy to steal from (which :normally has junky stuff), one wouldn't be able to steal it, because this value :for the shop may be something like 10 pp. Maybe shops should refuse to buy such expensive items from players if they don't have the facilities to display them securely, or they should buy and immediately sell on to the nearest shop that does. :jail_map: If the theif is caught, map where they are sent. At least scorn has :a jail if I recall - not sure if other maps. But basically, get caught :stealing, have to sit around for 5 (or more) minutes. Easier shops would :probably sentence you to less time. This could be in the form of [EMAIL PROTECTED],y :to denote coordinates to put the player into. I don't like the idea of automatic jail time - keep that for things that you *don't* want players to do, like pking and abusive behaviour. For game balance, I think it'd be enough to ban a thief from the local shops for a period of time (maybe around constant * (1 + log_2(item_value)) ticks). If more is needed, the shop keeper should call the guards - no loot, no exp, and guaranteed to be higher level than you. But I don't think it is needed. The rest sounds good to me. Hugo ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
Who said jade and amberonium coins would be in any duengons? I am not putting them as treasures in my maps atleast (and does anyone else map anymore besides me?). As for we have gems/this/that which can be used instead it's nice to have multiple ways to do things. The role of jade etc IMHO, since I'm not going to put them in my duengons as treasure (and hopefully others won't either) is to beable to have 10,000 dollar notes kindof thing. All apprasals etc should be in silver, gold, plat and never jade and amber. I suggest an addum to the mappers handbook don't put jade and amber coins in you duengons as rewards. Then will come the question why have them then! Well then why have most of the things we have in CF? We could probably chuck most of our archtypes.. why even have CF? CF isn't needed in the world etc. I'd also like copper coins, this will require value to have decemal points. Could we do that? --- Rick Tanner [EMAIL PROTECTED] wrote: Post on behalf of Todd Mitchell (Avion): The Imperial Banking system was not intended to be a modern bank, more of an old fashioned type bank. The Imperial Note is not money, it is a credit note. Basically it was to allow players to carry and transfer large amounts of wealth between cities or as a way to pay for large ticket items (such as guilds) while avoiding inflation of value that large coins would bring. The coin system is based on weight and this is a good thing that limits the amount of treasure folks can carry. Because they are low weight and easy to carry, the Imperial notes are not supposed to be worth anything intrinsically and cannot be used as money, but can be used to transfer large sums of money (and always for a convenience fee). All this talk of large denomination coins seems to be to me misplaced since the point of the coins is to limit what can be hauled out of dungeons easily and limit wealth accumulation. Large coins will lead to inflation as they allow players to carry more cash on hand. As for 'credit cards' and other stuff to pay for big purchases? - why bother when you can easily make special altars (or use scripting) for expensive things that accept Imperial notes. They are already credit notes. Allowing their use as *money* however would simply make them into large coins and defeat their purpose. Also the bank code was designed to allow for alternate credit institutions and easily changable service fees. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
Checkbook arch committed. There is also a bankcard arch. --- Rick Tanner [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ERACC wrote: That is why I suggested a bank card that debits the bank account rather than a credit card. I don't think CF should implement a credit system. I see ways to exploit /that/ right now. Hmm.. I thought the discussion all along was for some sort of debit/check/cheque card that automatically deducts the money from your bank account *assuming* you have enough cash in there to cover the purchase. Otherwise you see some sort of message showing how much more money you need to make the purchase. I agree, I think it's a bad idea for a credit card or making purchases without cold hard cash to back it up. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsbmDhHyvgBp+vH4RAqqqAKDNYdG9Psbcuw2XfLmwSujwwRon/wCg7O68 Y0Soiyofjh3eTWQ1wdnhcZ0= =zXPP -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [Crossfire-devel] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
I agree with Eracc, this is something I've wanted too. Could you also make hp and maxhp a 32 bit int aswell? --- Mark Wedel [EMAIL PROTECTED] wrote: ERACC wrote: While you guys are looking at stuff like this could you please adjust the payment altars to accept more than 32767? I wanted to use a 5 diamond altar in my Lone Town apartment map (for the various alchemy benches in the basement) but could not due to this limitation. The problem is that converters use sp and food as the number to use/create, and these values are 16 bit right now. It's simple enough to change the type to be 32 bit - I'm just not sure what other side effects that might cause. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
the coin money will still exist, right? --- Brendan Lally [EMAIL PROTECTED] wrote: On 12/31/05, Mark Wedel [EMAIL PROTECTED] wrote: Not until relative recent history did paper money really become popular. That said, if currency is changed, I'd suggest unique graphics (that are clearly distinguishable) are probably desired - having bunches of coins in my inventory that all look the same would be confusing/annoying, and remove some of the reason for doing this, which is to add character. This would also have to affect character generation, currently players that are generated get an amount of money when they choose a class, and before they exit the nexus. If the two destinations from the nexus have differing currencies, then the player could get the 'wrong' type. Moving the acquisition of money to the teleporters which the player stepped on might work, but since dead players return there until they get another savebed, this might be hard to guarentee to not be exploitable (at the least, every existing player who didn't set a savebed, would get some money next time they died). Making those teleporters damned could work, indeed, if they pointed to a relatively 'safe' place (scorn town hall maybe?) it might be considered a good thing anyway. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
I think you should have to go to the bank to convert coins to other currencies etc. If people don't want to bother with money they can use the checkbook and have to put up with the small % fees. --- Mark Wedel [EMAIL PROTECTED] wrote: My point about dropping money in the shop is more a convenience thing, not realism (using the 'r' word with crossfire is never a good idea). But my general thought is that if a bankkeeper is willing to accept usage of the check card (or whatever its called), it just makes it easier for players so they don't have to run to the bank every time they want to get rid of their coins. That's not one of the things I really like in real life, so could do without it in a game. As far as check books, various thoughts: 1) the bank itself could charge some fee (fixed percentage) of the money being deposited. After all, they are taking all those coins and storing them away. Number should probably be relatively low. 2) Shops could add some surcharge if using such a card. Perhaps make this a map property. Arguably, the bigger the purchase, the smaller (percentage wise) this charge would be. If you're buying something for 4 gp, its a bit of a bother for the shopkeeper to take that check and get the money. If you're spending 50,000 pp, the shop keeper would probably prefer that money get transferred directly to their bank account - they don't want 5 tons of platinum. If one was going to be more realistic, there really should be regional banks (scorn bank, navar city bank, etc), and you'd need to use the appropriate check book in the appropriate city (or the shops should demand a lot more money for using accounts of a foreign nature). Or perhaps the at the bank itself, you could transfer money, but with a fairly hefty fee (have to use magic after all to really confirm there is the money in that remote account, etc). But that really just makes things more a bother for the player. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] shops and stealing
Could exponetially vs linerally be settable in the server config file. --- ERACC [EMAIL PROTECTED] wrote: On Saturday 31 December 2005 12:02 am Mark Wedel wrote: [...] With the addition of new fields in the map header for shops, it'd seem like it would not be possible to extend stealing to shops. [...] Good ideas there. I would add that a player's luck score should have a lot of influence on ability to steal from a shop. So, a player that wants to PK /and/ steal is truly out of luck and will have a much more difficult time stealing from a shop. A 'luck 0' score would mean luck has no affect on the percentage chance of getting caught. A luck score of +1 or greater means the player has an exponentially greater chance of stealing successfully. A luck score of -1 or lower greatly increases the player's chance of being caught exponentially as the score goes down. So, someone with 2 PKs (luck -2) would have a much harder time stealing than someone with a luck of 0. Gene -- Mandriva Linux release 2006.0 (Official) for i586 18:27:34 up 16 days, 1:34, 10 users, load average: 0.20, 0.08, 0.02 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer UnixWare resellers ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
If we are to do this it should be in addition to the current (blank) coins. --- Brendan Lally [EMAIL PROTECTED] wrote: On 12/31/05, Miguel Ghobangieno [EMAIL PROTECTED] wrote: While regional currencies exchange values could change depending on factors that are not in the game yet the silver, plat, gold, jade, and amberonium coins should keep their absolute value forever. Actually, something I think might be interesting would be to have major and minor currencies. Consider the (pre-decimalisation) British Currency. Prices were given in pounds, shillings and pence, 12 p made one shilling, and 20 shillings one pound There was a one penny coin, a one shilling coin, and a one pound note. In principle it was possible to use these, and only these, for purchasing items. However, there were a number of other coins of intermediate values which were extensively used to make up intermediate values, without prices being quoted in them. (note that I am referencing old British currancy, simply because there were so many coins of arbitrary values that were issued - http://en.wikipedia.org/wiki/British_coinage#Denominations_of_pre-decimal_coins_and_their_years_of_production looks to be a fairly good list). Now, what I am wondering, is if the coins with which shops make change couldn't be the thing that varied, so that money would be taken from one of 12 or so different types of coins, and change given in a similar manner (to take an example from the above list, an item which would require 50 shillings (gold) change might cause it to be given in the form of two unites and a half unite in one place, but one two guinea coin and two double florins somewhere else. These could all be legal tender everywhere, whilst causing a player who would travel in certain areas of the world to have different types of coins to someone else elsewhere. A modern form of this can be seen to a lesser extent with the euro coins and notes, whilst they lack the amusingly contradictory values, they have different designs on the reverse depending on which country they are from, so that a coin with a design from a country relatively far away is a mild curiosity on the occasions they are encountered. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
I'll commit the large denomination coins (unless objections are raised), I'd like to edit the amber coin to look more ambery (any objections) (currently it looks kinda like copper rather then a solidified transparent liquid... it's a shame CF doesn't support PNG semi-transparency)? For the map aspect I don't think the scorn bank change with amber and jade coin converter tables should be added to CVS. I think for the code aspect there should be a list of regions where amber and jade coins may be given as change. If on a shopmap the region matches one of these then amber and jade may be given. I think this list should include azamuindo... but not much else. All shops should accept amber and jade. (Also, as errac noted, they should probably accept imperials, also I have committed the bank card arch so work can be done on that too :D). Thoughts? __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
I think it should be made clear that these denomination notes are ankin to 10,000 USD and 1000,000 USD notes, respectivly. This should be put in the mappers hand book. I will be careful to not inflate my prices. Another thing I would like to have is the value variable as a double. That way we could have copper coins. Then we can make copper the new silver and deflate the economy (by editing the random wealth arch treasure list and the low and mid level monsters lists and putting in copper where silver is and silver where gold is and gold where plat is (and rarely a plat). This way money will have value again. Also conversion tables in banks for these new denominations, as they sound like something that would come from the east, shouldn't be in scorn or navar or brest. I think the conversion tables should only be in azamuindo, maybe (or maybe not) darcap (it may have stumbled upon some). All shops should accept them ofcourse but not give them as change (unless perhapse the shop has a given region set (azamuindo(sp)? darcap?). (Note: I'm opposed to the money as stat idea, I guess that was just a point being raised though for contrast). --- Mark Wedel [EMAIL PROTECTED] wrote: Anton Oussik wrote: On 24/12/05, Mark Wedel [EMAIL PROTECTED] wrote: At some level, it becomes a question of why not just make money a 'stat'. Instead of gold pieces, silver, platinum, etc, floating in your inventory, something just says you have 123456 gold pieces. All this starts to get away from the discussion at hand, but is food for thought No, it is very much on topic - the main issue here is to avoid the need to have large piles of money lying about in apartments and having to carry more than your own weight in platinum in order to go outside to the shop (perhaps the subject is misnamed though ;-) ). Your idea seems more sensible. Perhaps make all players carry a special wallet/money pouch item, which is a container into which money automatically go and become weightless (or near enough so), which will say you have foo gold when clicked, and from which you can drop money? This could also be implemented as a property and interfaced by adding new server commands and adding a UI pouch... but that is for version 2 of CrossFire. As said, this wouldn't be really hard. Add a uint64 field to the player object. Modify the pickup code to check item type being picked up. if type == MONEY, add it to that stat, a don't insert it (this could actually be done in the insert_ob_in_ob for that matter to make sure all cases are caught). For new clients, add a mechanism for server to tell client this value - probably via stats command makes the most sense. For these new clients, it is then up to them how they should display that (could just be next to exp or something). For older clients, or maybe all clients until altars and the like are somehow fixed up, the server would fake inventory items for the coins. For simplicity, probably only fake gold pieces (I don't think anything actually requires silver or platinum, and faking only 1 object instead of 3, makes sense). When player tries to drop some gold, the server would catch it is a fake object, and convert the objects into a pile of gold and insert it into the map. Covers those altars, tables, etc. Also, allows players to trade gold easily. For these fake objects, the draw_look function of previous/next object in large stacks could be used - basically set the high bit on the object tag, and drop and examine would catch this special tag and do the right thing. It actually isn't that hard to do, and probably a good thing to do. The biggest issue is making sure it works - having a bug and wiping out peoples gold would be a pain. the only real oddity is the weight values - that 'stat' of gold would basically be weightless (or presumably a much lower weight than currently in place). That said, it would seem an easy fix right now is just change the current weight of coins - the weight is currently 10 - it could be reduced to 1, and increase carrying capacity tenfold. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [patch] Large-denomination coins
Exactly. I'd like the value var to be a double so we can add copper coins ... --- Lalo Martins [EMAIL PROTECTED] wrote: And so says Mark Wedel on 25/12/05 14:27... I think the other potential problem is map makers seeing this high valued coins and start to place these in maps instead of the lower value coins currently there, so therefor, you get an inflation of available money. oooh, people would whack this map maker VERY seriously upside the head :-P I feel the general sentiment in this list and IRC is to *reduce* available money rather than increasing... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
Please do not implement this. Gold is gold, silver is silver, plat is plat; elements, metals, useful in their own right. If you want a money pouch then what you want is a checkbook in addition to using what we have now. Mark was making a point in his post, saying basically 'this will make money as if it is nothing', contrast that thought with having a physical gold coin in you hand... gold coins are real not thin air. You want a checkbook. I can make the archtype face pic and perhapse cave can do the code, however real gold etc must not be mangled. --- Anton Oussik [EMAIL PROTECTED] wrote: On 24/12/05, Mark Wedel [EMAIL PROTECTED] wrote: At some level, it becomes a question of why not just make money a 'stat'. Instead of gold pieces, silver, platinum, etc, floating in your inventory, something just says you have 123456 gold pieces. All this starts to get away from the discussion at hand, but is food for thought No, it is very much on topic - the main issue here is to avoid the need to have large piles of money lying about in apartments and having to carry more than your own weight in platinum in order to go outside to the shop (perhaps the subject is misnamed though ;-) ). Your idea seems more sensible. Perhaps make all players carry a special wallet/money pouch item, which is a container into which money automatically go and become weightless (or near enough so), which will say you have foo gold when clicked, and from which you can drop money? This could also be implemented as a property and interfaced by adding new server commands and adding a UI pouch... but that is for version 2 of CrossFire. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system NO MONEY STAT, Use a checkbook if you want that.
PLLLEASE DO NOT change the weight of gold etc. Please DO NOT MAKE MONEY A STAT. GOLD CANNOT change into silver like magic etc. Do not do this please. If you want something like this then make a checkbook tied to the banking system. If gold coins, silver, etc are made into a stat I cannot work on this project anylonger. I have invested considerable effort in bullion arches etc. PLEASE DO NOT SCREW WITH GOLD, SILVER, AND PLAT coins! PLEASE DO NOT DO THIS. You want a checkbook, it can be made, I can make the checkbook face. PLEASE DO NOT SCREW WITH THE COINS. (Ps none of the players I spoke with want this change either, so the players are against it too). If you want a crossfire-simple mode then code that in as an option or fork off to a crossfire-simple project. Gold has a weight to value ration, PLEASE DO NOT FSCK WITH THIS!. If you are so concerned with the weight of the coins then make paper money for each region (in _addition_ to the bullion). Imperials should remain the international banking note, however. Damn.. every month there is a let's remove stuff iniative. GOLD IS NOT SILVER they ARE diffrent elements. THEY HAVE EXACT WEIGHT TO VALUE IN CROSSFIRE which I have based all my bullion and other metals on. DO NOT DO THIS. --- Anton Oussik [EMAIL PROTECTED] wrote: On 25/12/05, Mark Wedel [EMAIL PROTECTED] wrote: Anton Oussik wrote: On 24/12/05, Mark Wedel [EMAIL PROTECTED] wrote: At some level, it becomes a question of why not just make money a 'stat'. As said, this wouldn't be really hard. Add a uint64 field to the player object. I suspect this would also fix the client bug when the client crashes when it steps on a tile where something has nrof 2^32. The biggest issue is making sure it works - having a bug and wiping out peoples gold would be a pain. I agree, it would need a lot of testing before being put into production use. That said, it would seem an easy fix right now is just change the current weight of coins - the weight is currently 10 - it could be reduced to 1, and increase carrying capacity tenfold. Yes, one can do that, but then it would only be a workaround, and one that would not fix all money carrying related problems. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
PLEASE don't implement this (gold, plat, silver as a stat). What you want is a check book. If the player has the checkbook applied the $$ will be deducted or added to his account. Please don't alter the gold weight/value ration (nor the silver etc). Please don't make money a stat. I will make a checkbook arch face. uint64 is good. value as a double (so we can add copper coins) would be good too. Please keep the coins as they are though. Please no money stat. (Also when is the jade etc coins going in? I think they should exist and be acceppted but not given as change except if region = azamuindo (perhapse another? darcap? maybe just azamuindo). --- Brendan Lally [EMAIL PROTECTED] wrote: On 12/25/05, Anton Oussik [EMAIL PROTECTED] wrote: On 25/12/05, Mark Wedel [EMAIL PROTECTED] wrote: Anton Oussik wrote: On 24/12/05, Mark Wedel [EMAIL PROTECTED] wrote: At some level, it becomes a question of why not just make money a 'stat'. As said, this wouldn't be really hard. Add a uint64 field to the player object. I suspect this would also fix the client bug when the client crashes when it steps on a tile where something has nrof 2^32. Wouldn't stepping on non-money items which have a sufficiantly high nrof also trigger such a crash? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [patch] Large-denomination coins
so the value in the arch might read 0.33 the server code will remove the . when reading it and put it at 33 internally? --- Brendan Lally [EMAIL PROTECTED] wrote: On 12/25/05, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Exactly. I'd like the value var to be a double so we can add copper coins ... That could lead to all sorts of fun rounding errors. Probably it would be best to use a 64bit int, and store value*1 or so - that way you could have 4 values after the decimal point, and still not have errors due to floating point maths. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding
Well in that case the center needs to update it's archtypes :). --- ERACC [EMAIL PROTECTED] wrote: On Saturday 24 December 2005 12:41 am [EMAIL PROTECTED] wrote: metalforge isn't the center of the universe Yes. It is. :-p ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [patch] Large-denomination coins
Very cool :D. I suppose I should update my server code soon then :). --- Lalo Martins [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just submitted a patch to the tracker. It adds two high-denomination coins: jade (after Chinese history and many Chinese-themed RPGs such as Exalted) and amberium (a Zelazny reference, although this material doesn't exist on his books). One jade coin = 100 plat; one amb = 100 jade. Incidentally, thanks to implementation details of shop.c, this raises the largest possible item value by a factor of 1 - it used to be 2^32 plat, now it's 2^32 amb. Also included is a patch for the Scorn bank; other banks and the guilds are left as exercise for the reader (or I may do it if a dev asks nicely). http://sourceforge.net/tracker/index.php?func=detailaid=1389033group_id=13833atid=313833 best, Lalo Martins - -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - -- http://www.laranja.org/ mailto:[EMAIL PROTECTED] GNU: never give up freedom http://www.gnu.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDrEQhc+NusBpPPUkRAhGUAKCfUVoqgIbqu/Dq51GXH+8LZvg2AQCfavfo bM0LTXKXc3TJtUGu/v3T/wk= =kd/I -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
