Re: [crossfire] Smooth movement
Basically, it consists on accepting input (whether it's actual input from the user, or a decision from the monster AI code) at a point in time half a tick before when the object actually gets its tick. Think of that as neural impulse delay. Does that make sense? It does. But I think that's just the first issue of the whole problem, and not the most complex one to solve, unfortunately. The first issue is with the protocol itself. Currently, the server basically sends the client a gird of objects that are strictly square-positioned. What about the transitioning objects (those who are in the middle of a move, at a position like (X+0.3;Y)) ? Two solutions: - Either you do not strictly synchronize the client with the server. You just send the same messages that are currently sent (thus no transitioning marker of any sort), let the client compute the supposed position of the character and backtrack if necessary when the server sends the next map update. You'll have to face synchronization problems at some point, obviously. - Or you include synchronization messages in the protocol - but then, you'll have to make drastic changes to it, which will require a complete redo on the redrawing side of the client. The second issue that's not really adressed is about what I call the square conflict problem. Suppose that your character attempts to move on a square S, but that a monster attempts exactly the same thing. With the current square-by-square gaming system, there's no problem: the faster one is moved on the square. Now, with a smooth move system, it means that you'll see one character being suddenly stopped at the edge of S, while the other is moving into it. It could lead to the rather strange situation of a character being hit by a monster that's not even right against you. I think that the question of knowing where the character is on the map while transitioning is a rather simple one; I see the major issues more in the client/server sync and with the current communication protocol, which doesn't seem to be easily adaptable to handle a smooth moves situation. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unban me from #crossfire
Women's Rights Delenda Est. Translation for people who don't speak latin or are too lazy to google: Women's Rights must be destroyed. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire Plugin System v2.0
The small rewrite of the Crossfire Plugin subsystem is nearing completion - finally. I think that a couple of explanations are necessary. Why ? - The main reason to answer the why a rewrite is that the older way of managing plugins was simply too complex and obscure. Using the CFParm structure to pass arguments between the server and the plugins initially seemed a good idea - but it came at the price of an heavy-to-write, heavy-to-use system. Having to fill in a table of CFParms and to ready a return CFParm structure is counterintuitive to what most C programmers usually do. What will change and how ? -- 1. Code Internals. The rewrite somewhat simplifies the code writing. Basically, most server functions are now exposed with the following prototype: void* cfapi_funct(int* type, ...) type indicates the type of the return value, as defined by constants in include/plugins.h. The arguments are now transmitted using the more conventional va_args mechanism. There is obviously a drawback in that the server now assumes that the correct parameter values are passed by the plugin - but expecting that the plugin developper passes a correct parameter type isn't too much asking IMHO. Moreover, a group of common server function wrappers has been written. When a new plugin is being developed, the coder should include those common wrappers in its compilation process. Those ensure that (1) the plugin coder doesn't need to directly call the server callback function pointers and (2) limits the possibility of passing wrong argument types. So for example, instead of having to use the void* cfapi_map_create_path(int* type, ...) callback and taking the risk of passing wrong argument types and having to manually manage typecasts and callback bindings, the plugin coder can call the common wrapper char* cf_get_maps_directory(char* str) and use it without worrying on how the plugin-server communication works. On the server-side, the code is also somewhat simpler, because the CFParm wrapping doesn't exist anymore - calling a plugin event now takes one or two lines, to compare with the dozen (or more) before. 2. Event hooks The second important change is how the events are bound to objects. Previously, plugins used various event_xxx fields in the object to bind. It has a rather annoying drawback: you couldn't bind more than one action to one event (chains of events weren't possible). The new system uses a new archetype type EVENT; the map-maker now wraps the binding in an event_xxx *object* that is stored in the inventory of the bound object. It allows to bind several plugins to a single event in a single object. It also removes the need for supplementary fields and makes the event subsystem more consistent with the everything is an object motto. 3. Compatibility with v1.0 of the plugin system The v1.0 plugins (there are currently 3) are *not* compatible, even at source level, with the v2.0 interface. There is also no effort made to ensure compatibility with objects bound with the 1.0 event_xxx tags, so map-makers will have to adapt them accordingly. Note that it isn't a lot of work - it isn't as if there were thousands of objects to convert. I could have assured compatibility, but it the work and code complexity it introduced seemed much greater than the work needed to convert the few objects that were using the old system. A potential problem may arise with players owning scripted objects, as those will cease to work. But unless there are *lots* of such cases (which is doubtful), simple manual exchange with newer versions of the objects from the DMs should suffice. What about the current plugins ? 1. CFPython The CFPython plugin has been rewritten to match the new interface. The occasion to rewrite it has been used to make the CFPython interface cleaner and (hopefully) easier from a Python-coder point-of-view. The most important change is the introduction of Python object types wrapping Crossfire entities (Crossfire Objects, Maps, and Players). Available functions are mostly the same (only those rendered obsolete by the new plugin infrastructure were removed), but they are now properties and methods of Python objects. Examples CFPython.AcquireSpell(target, spell) now becomes target.AcquireSpell(spell). CFPython.GetStrength(who) now becomes who.Str. CFPython.SetStrength(who,val) now becomes who.str = val. The conversion process is rather straightforward and shouldn't cause trouble - it took me an afternoon to convert all scripts supplied in maps-bigworld/python and I'm no Python specialist. 2. The Animator The Animator is currently being rewritten to work with the new plugin interface. Apart from the event-binding procedure, there should be no other change in the way it works. Work on it isn't finished, but shouldn't take years to complete, unlike CFPython :). 3. The Logger The Logger is outdated
Re: [crossfire] More server speed reducing the objects number
Alberto Sáez Lodeiros wrote: (Before that, sorry for my english, I'm from Spain, and there are some expressions i don't know very well) I was thinking that the MetalForge server can goes faster (or simply save RAM?) reducing the objects in the world. I refer to reduce the number the objects, not monsters. One way to do this is making corpses-containers, as some CF players disscuss at #crossfire IRC channel. For those who weren't there at October 15, the questions is this: When a player kill a monster, this monster drops it's loot to the floor, creating on this way some more object. So the idea is that instead the killed monster drop all the loot, only appear it's corpse, and then, when the player apply the corpse, this opens like a briefcase or chest, containing all the monster's loot. We have disscussed the way to do this, and like we talk about, the best way is: 1.- Spawn 2.- Create random Loot 3.- Die 4.- Create container 5.- Move loot to container 6.- Put container in monster Well, the idea is reduce the objects over the map/s And this is all. I think this is a good idea.. :) This might be a good idea, however ram usage would actually increase slightly not decrease, though it may have a minor positive performance impact. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
Ok yes, i refer to reduce the visible objects... Also U can made when a player dies, he leaves a gravestone-container with his items in the inventory. This will made players more carefull before try to kill stronger enemyes... This is only a gameplay idea, but the important i think is the corpses-containers. -- -- Powered by Fedora Core 4 Linux -- -- AMD Duron 1.3 GHz -- -- 512 Mb RAM DDR 400 MHz -- -- HDD 80 Gb 7200 RPM -- -- GeForce 2 MX 400 -- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
On 10/15/05, Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: We have disscussed the way to do this, and like we talk about, the best way is: 1.- Spawn 2.- Create random Loot 3.- Die 4.- Create container 5.- Move loot to container 6.- Put container in monster What would you do to the container (cadaver?) after a player 'opens' it? Destroy the container, or leave it there, empty? If the corpses were to remain, then using the dead bodies for storing different equipment could be interesting. I can certainly envision storing large numbers of axes in a goblin. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Houses system for guilds
Alberto Sáez Lodeiros wrote: Hi again!!! I have in CF a party with some more players, but we treat this party as a guild. This is, we have rules, a tribute, ranks, and so on. So we need a place to store all party/guild treasure. I was thinking that U can create a guilds' city. This is not a new city exactly. This is a (initially) blank map, where each guild can BUY a headcuartee. This city, can be accesible from a magic portal (teleport) in scorn or navar city. The guildmaster must pay to a map developer the amount estimated, and the the developer will create a new house in this blank map. Also can be a requisite to be at least 5 members in the guild to build this house. Another way to do this is to create a hall, and here, to set a magic portal to a guild appartament, but this appartament will be the same for each member of the guild. The requisites to enter the hall, can be the same with the blank map idea. Personally, i like more the blank map idea, because in this way, we can create our own city I am working on buildable land plots, which allow players to build in many/most/all (differing ideas there) in bigworld. Much of this could be done by players via that. (see buildable land plots thread in the mailing list archives) Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Houses system for guilds
On 10/15/05, Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: Personally, i like more the blank map idea, because in this way, we can create our own city. have a read of the thread from this post: http://shadowknight.real-time.com/pipermail/crossfire/2005-September/009238.html ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Plugin System v2.0
While we're at it :) * could we use names more explicit that EVENT_GDEATH and EVENT_GKILL? I'd say EVENT_PLAYER_DEATH and EVENT_KILL, less confusing * EVENT_GKILL takes *two* parameters (what was killed and by who), only one is used in plugin. And parameters should be inverted imo, first what was killed, then by who (seems logical to always send affected item first, then what object affects it imo) Ryo ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
If one's server is lagging because of items then one is running his server on a 286 PS/2 system (if that is even possible). This is a non-problem. --- Brendan Lally [EMAIL PROTECTED] wrote: On 10/15/05, Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: We have disscussed the way to do this, and like we talk about, the best way is: 1.- Spawn 2.- Create random Loot 3.- Die 4.- Create container 5.- Move loot to container 6.- Put container in monster What would you do to the container (cadaver?) after a player 'opens' it? Destroy the container, or leave it there, empty? If the corpses were to remain, then using the dead bodies for storing different equipment could be interesting. I can certainly envision storing large numbers of axes in a goblin. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
It remains the empty corpse. But you can set any kind of timer wich makes corpse-container dissapear after a concrete time, for example 5 minutes -- -- Powered by Fedora Core 4 Linux -- -- AMD Duron 1.3 GHz -- -- 512 Mb RAM DDR 400 MHz -- -- HDD 80 Gb 7200 RPM -- -- GeForce 2 MX 400 -- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: Houses system for guilds
The idea seems neat, BUT, I have to wonder if you are aware of the existing guild system in Crossfire. From the sounds of it, the existing guilds solve your problem well enough. 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.exoweb.net/ mailto:[EMAIL PROTECTED] GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Houses system for guilds
I know guilds of Crossfire, but i saw that all the altars are already taken... I refer to the altar in the Guilds House at Scorn. -- -- Powered by Fedora Core 4 Linux -- -- AMD Duron 1.3 GHz -- -- 512 Mb RAM DDR 400 MHz -- -- HDD 80 Gb 7200 RPM -- -- GeForce 2 MX 400 -- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
On 10/15/05, Mitch Obrian [EMAIL PROTECTED] wrote: If one's server is lagging because of items then one is running his server on a 286 PS/2 system (if that is even possible). This is a non-problem. Well, to be fair, on the occasions where servers do slow down, it tends to be from spell objects (normally coupled with directors). This is lagging 'because of items'. However I would agree that treasure drops from monsters aren't normally an issue in this case. Any benefit there would be would be to bandwidth usage, not server memory usage. However, even there, unless/until the number of faces visible per square is increased, the difference is likely to be minor (2 objects instead of 3, if there are multiple items dropped, and if there were nothing on the floor already) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Houses system for guilds
Perhapse the solution it to add more guilds? We could make the new ones python guilds (rather then redoing the current guilds). Perhapse these new ones should have their guild buy house in navar or brest? --- Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: I know guilds of Crossfire, but i saw that all the altars are already taken... I refer to the altar in the Guilds House at Scorn. -- -- Powered by Fedora Core 4 Linux -- -- AMD Duron 1.3 GHz -- -- 512 Mb RAM DDR 400 MHz -- -- HDD 80 Gb 7200 RPM -- -- GeForce 2 MX 400 -- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
