[crossfire] Transports
Below is my propose implementation for tranports (boats, horses, wagons, etc). Look it over and let me know any questions/improvements, etc. Tranports are objects that help the player move. These should not be confused with EXITS, which instaneously transport a player from one map to another. Instead, tranports may let the player move faster, give them move types they don't have, etc. A simple example of this would a horse. It doesn't let the player move anyplace he normally couldn't go, but lets him get there faster. Ships would be another case - the player normally can't move accross water, but with a ship, he can. Meaning of various object attributes (KV means the value is stored in the key/value list, and thus the get_ob_key_value() and set_ob_key_value() routines need to be used. move_type The move type this object has. move_allow Normal meanings - useful for things like boats so people can actually get on the boat. speed How fast the object moves weight_limitHow much this object can carry. weight_speed_ratio (KV) This value is taken as a percentage which is multiplied against against the weight this object is carrying (the player) - this is then divided by weight_limit to determine the effective loading to determine effective object speed, eg: speed = base_speed - (base_speed * pl-weight * weight_speed_ratio) / (weight_limit * 100) Thus, if weight_factor is 0, this object will move the same speed no matter how loaded it is. If it is 100, then if the transport is fully loaded, it moves at a crawl. In a sense, this somewhat mimics the player movement speed. Large transports, like boats, should likely be largely unaffected by weight (maybe have this value at 10), where something like a horse would have a relatively high value. base_speed(KV) This is only needed if weight_speed_ratio is set - it is used to know what the base speed to use in the calculation (since speed is getting clobbered). If this is not set and weight_speed_ratio is set, the archetypes speed will be used. passenger_limit(KV) How many players this transport can hold. Thus, boats can transport a party (this being set to 6) while horses could only transport a single person. If this is not set, a default of 1 will be used. face_full It may be desirable to have different faces to denote what the tranport looks like if someone is on it vs not (mounted horse vs just a horse). This is used to denote what it will look like when loaded. If the tranport becomes empty, it will fall back to the archetype face. anim_full Like face_full above, but for animated objects. Usage/implementation details: To activate a transport, the player will stop onto it and 'board' it. When this is done, the transports op-contr will point to the player, and a pl-transport pointer will be set up. An 'unboard' command will be needed to leave the transport (thoughts on a better way to deal with this?) I don't think apply will work because that will be needed to get stuff in/out of it like a container. For transports that hold multiple people, the first person to apply the transport becomes the captain. It is this person that decides where the transport goes. Transports to some extent will appear as containers - thus you could load stuff onto(into) the transport without having to be able to carry it all - imagine wagons that carry 10,000. When aboard a transport, the player will be in the inventory of the transport. Thus, the players movement/speed doesn't play any role. In this implementation, transports don't attack or defend, and thus don't take damage. If something damages items on the space (say spikes), it will damage the player(s) and not the transport. Thus, transports can't be used to avoid traps and the like. Thoughts/questions? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] On moving the Lone Town apartment [bigworldized pupland]
And so says ERACC on 21/01/06 00:46... Lalo? Are you there? I would like to know how this is progressing and when you think you will have it done. I'm sorry, I was off-net when this discussion happened. Continental Pupland is about halfway there, if you want to help, poke me on IRC. The islands will wait till after mainland is merged. Personally, I don't have a problem with the Lone Town apartments. The war hasn't been going on for long - and if there was a property this size in the town, they would probably find a way to sell/rent it to a rich foreigner to raise money for the cause. You could rename it, if you wish. Private villa or something. But I don't see a reason to move it. 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
Re: [crossfire] Transports
On 31/01/06, Mark Wedel [EMAIL PROTECTED] wrote: When aboard a transport, the player will be in the inventory of the transport. I would say that transport should also point to a map containing the inside of the transport. Therefore two actions are requared as regards to a transport: enter it, and drive it. Only the owner should be able to drive the transport, but anyone in the same party should be able to enter it. This way a transport ship or a cart will be able to transport people and goods. This would not make much sense for a horse or a dragon though, which would not be able to carry goods, but be only used to transport the owner. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
Mark Wedel wrote: Below is my propose implementation for tranports (boats, horses, wagons, etc). Look it over and let me know any questions/improvements, etc. snipped Thoughts/questions? Well, for it to be more useful, it would be good if it could go through exits (scorn gatehouse). However this leads to questions like: What should the transports do on non-bigworld maps? (wagons could easily appear too small) And what should be done to prevent you from running around shops in a wagon? Such things incline me to want to disallow them from going through exits, though that in my opinion makes them more limited in usefulness too. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 1/31/06, Alex Schultz [EMAIL PROTECTED] wrote: Such things incline me to want to disallow them from going through exits, though that in my opinion makes them more limited in usefulness too. Can exits use the move allow/block idea too? if so, you could look at them to decide whether a transport can go through an exit or not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 1/31/06, Mark Wedel [EMAIL PROTECTED] wrote: Usage/implementation details: To activate a transport, the player will stop onto it and 'board' it. When this is done, the transports op-contr will point to the player, and a pl-transport pointer will be set up. An 'unboard' command will be needed to leave the transport (thoughts on a better way to deal with this?) I don't think apply will work because that will be needed to get stuff in/out of it like a container. what's wrong with pickup? If I follow the description properly, this transport will stop most of the items on the ground being useful once you are inside it anyway, so you could send as the ground view a single item such as 'get off horse' 'dismount ship' (this requires a new K-V (onboard name). Picking up this item should then dismount from the transport. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] cfclient colouring (was: gcfclient options deathlist)
On 1/31/06, Mark Wedel [EMAIL PROTECTED] wrote: I'd personally say that requiring a 256 color display isn't asking too much now days. I'm inclined to agree, I just don't know xlibs well enough to break support for 16 colour displays in a non-hacky way. (there is still some 'private colourmap' stuff, which I think is somehow related to that) I actually think the grey background looks nicer than the old dark green background. excellent, I've commited the patch. ___ 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] crossfire traffic
Great idea! Now make the URL to that widely known, and easily findable, so the user base will easily find it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
Brendan Lally wrote: On 1/31/06, Alex Schultz [EMAIL PROTECTED] wrote: Such things incline me to want to disallow them from going through exits, though that in my opinion makes them more limited in usefulness too. Can exits use the move allow/block idea too? if so, you could look at them to decide whether a transport can go through an exit or not. Ahh, good idea. That should work in theory from what I know. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 1/31/06, Anton Oussik [EMAIL PROTECTED] wrote: In order to achieve that I propose starting with 3 changes: * DRASTICALLY reduce the hp regeneration (something like 10-fold) * Significantly increase hp of players and monsters (3-10 fold) * Significantly lower resistances given by items (so a player can get up to 25% resistance or so with several items) One thing that might work well there, would be to also have a reduction in weapon speed (reduce it by a factor of 2 or so). Currently when you attack monsters the attack messages are numerous and spam-y, if they were slowed down a lot (to at least the point where you could read all of them out loud as they come in). There would be fewer attacks to calculate, the rate of damage would be less, and there would also be fewer draw_info messages to transmit, which seems like a win all round. It would also make it possible to bring back the point from long ago of attack sounds, since attacks and parries would be slow enough that you could actually have sounds mapped to them. As an extension to the aboce extension a new family or party spells can be introduced. These will aid parties in combat by providing spells like party heal, and party word of recall. Possibly party strength, party wisdom, and so on can be introduced. They would be high level spells that would act on all of the party, and will belong to different magic schools. IIRC party spells are already supported in principle, but nothing is currently using them. ___ 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] Transports
Brendan Lally wrote: On 2/1/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: One can't put unpaied stuff in a box and steal them, same would go for transports I'd assume. I think the point is rather that horses shouldn't go into shops in the first place, through gates maybe, and certainly into cities, but not shops or other buildings with human-sized doors. Yes, that is the point I am trying to make. Though it would probably be good to have a sanity check that covers what mikee is saying. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] cfclient colouring
Brendan Lally wrote: On 1/31/06, Mark Wedel [EMAIL PROTECTED] wrote: I'd personally say that requiring a 256 color display isn't asking too much now days. I'm inclined to agree, I just don't know xlibs well enough to break support for 16 colour displays in a non-hacky way. (there is still some 'private colourmap' stuff, which I think is somehow related to that) actually, I don't think there is anything specific about using 16 colors. I think it was just that 16 colors were used - it could very well be 12 or 25 - as far as X is concerned, it doesn't care (unless someone only had 4 bit color, but I don't know if such hardware ever existed). And right now, while only those 16 colors are used for standard drawing elements, hundreds of more are used for the actual images themselves. Private colormap is a leftover from 8 bit display - most 8 bit hardware could only display 256 different colors at a time, but out of the palette of 16 million (24 bit color). So one would use colormaps to determine what colors of the palette your are drawing. Now there may still be some people out there still on 8 bit color. But it is probably fair to have 16+ bit color be a minimum requirement now days (actually, the other clients, that don't do color map stuff, will probably work on 8 bit color, just look pretty crappy) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] crossfire traffic
That looks like a great idea to me. Nice to also get a monthly recap of what has been talked about ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Brendan Lally wrote: On 1/31/06, Anton Oussik [EMAIL PROTECTED] wrote: In order to achieve that I propose starting with 3 changes: * DRASTICALLY reduce the hp regeneration (something like 10-fold) * Significantly increase hp of players and monsters (3-10 fold) * Significantly lower resistances given by items (so a player can get up to 25% resistance or so with several items) One thing that might work well there, would be to also have a reduction in weapon speed (reduce it by a factor of 2 or so). Currently when you attack monsters the attack messages are numerous and spam-y, if they were slowed down a lot (to at least the point where you could read all of them out loud as they come in). There would be fewer attacks to calculate, the rate of damage would be less, and there would also be fewer draw_info messages to transmit, which seems like a win all round. It would also make it possible to bring back the point from long ago of attack sounds, since attacks and parries would be slow enough that you could actually have sounds mapped to them. 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
