From nicolas.weeger at laposte.net Sat Jul 2 15:13:30 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Jul 2011 22:13:30 +0200 Subject: [crossfire] Diseases and immunities changes proposal Message-ID: <201107022213.34360.nicolas.weeger@laposte.net> Hello. Right now the current behaviour with diseases and immunities is: - if you're immuned to a disease up to the disease's level, you can't suffer this disease - else you suffer the disease at its infliction level I'd like to change that to have the immunity reduce the effective level disease. The rational would be that you're immune to part of the disease ;) So for instance: - give cold dragons gain an immunity to cold at level 50 - any cause cold below 50 won't have any effect - a cold at a higher level will have an effect, but at a lower level If a player were to cast cold level 70 on a cold dragon, the effective disease level inflicting the dragon would be 70-50 => 20 (or 70-40, or 70-x*50 with 0 < x <= 1 - right now x = 0, which is what I want to change). This would make diseases less fatal, and less binary too - immune up to a level or totally vulnerable. Of course this would apply to both players and monsters. What do you think of that? The simplest change would be to have x = 1, but maybe that's harsh for players :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From kbulgrien at att.net Sun Jul 3 00:21:54 2011 From: kbulgrien at att.net (kbulgrien at att.net) Date: Sun, 03 Jul 2011 00:21:54 -0500 Subject: [crossfire] Diseases and immunities changes proposal In-Reply-To: <201107022213.34360.nicolas.weeger@laposte.net> References: <201107022213.34360.nicolas.weeger@laposte.net> Message-ID: Seems reasonable to me. >Right now the current behaviour with diseases and immunities is: >- if you're immuned to a disease up to the disease's level, you can't suffer this disease >- else you suffer the disease at its infliction level > >I'd like to change that to have the immunity reduce the effective level disease. > >The rational would be that you're immune to part of the disease ; -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From nicolas.weeger at laposte.net Fri Jul 8 13:30:22 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 8 Jul 2011 20:30:22 +0200 Subject: [crossfire] Diseases and immunities changes proposal In-Reply-To: <201107022213.34360.nicolas.weeger@laposte.net> References: <201107022213.34360.nicolas.weeger@laposte.net> Message-ID: <201107082030.25832.nicolas.weeger@laposte.net> Hello. I've implemented that change, based on the symptoms of the disease. Now a monster with eg immunity to flu 20 infected by flu level 50 will only have symptoms level 30 (but will infect others at level 50 :)) Feel free to revert that change if it breaks too many things. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Jul 10 05:20:22 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 10 Jul 2011 12:20:22 +0200 Subject: [crossfire] Ground and container view Message-ID: <201107101220.26219.nicolas.weeger@laposte.net> Hello. Because I use JXClient which displays contents of a container like the ground view, I changed the server to enable browsing container items like the ground view, with arrows for "next and prev group of items". I just realized the GTK client displays contents of a container as children of that container, instead of the ground view. Thus my changes conflict with that, and introduce "paging" for GTK when there was none. Now I'm wondering, GTK doesn't limit the number of displayed items in containers but the server does limit to 50 the number of items in the ground. This behaviour doesn't make sense IMO - either the ground should display everyhing like containers, or both should be browsable. So I'm wondering what's the correct fix for that: - should server limit items for ground and container view? if so then clients should be adjusted - should there be no limit? note that currently the server will limit to 100 for ground view, but no limit for containers... Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Jul 11 01:17:40 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Jul 2011 23:17:40 -0700 Subject: [crossfire] Ground and container view In-Reply-To: <201107101220.26219.nicolas.weeger@laposte.net> References: <201107101220.26219.nicolas.weeger@laposte.net> Message-ID: <4E1A9584.6050004@sonic.net> On 07/10/11 03:20 AM, Nicolas Weeger wrote: > Hello. > > > Because I use JXClient which displays contents of a container like the ground > view, I changed the server to enable browsing container items like the ground > view, with arrows for "next and prev group of items". > > I just realized the GTK client displays contents of a container as children of > that container, instead of the ground view. > > Thus my changes conflict with that, and introduce "paging" for GTK when there > was none. > > > Now I'm wondering, GTK doesn't limit the number of displayed items in > containers but the server does limit to 50 the number of items in the ground. > > > This behaviour doesn't make sense IMO - either the ground should display > everyhing like containers, or both should be browsable. > > > > So I'm wondering what's the correct fix for that: > - should server limit items for ground and container view? if so then clients > should be adjusted > - should there be no limit? note that currently the server will limit to 100 > for ground view, but no limit for containers... So to go into some background on this: Way back when, the ground view would display all items. The problem was that if the item had a huge number of different objects (typically in apartments), the amount of data that needed to be sent for a ground view was large enough it would overflow the output buffers on the server. The server catches than, and presumes it is a slow or otherwise poor client, and drops the connection. So users would get into cases where when they moved onto such a space, their connection would just drop. The solution to this was to limit the amount of objects we send at the ground view to 50. That number was arrived at through some analysis based on size of ItemCmd, and I also believe that for non image cache users, how much image data might get sent. Now containers (and for that matter, the players inventory) could have the same issues. I suspect they typically don't because there are limits on amount of stuff (based on weight) that can be put into a container or the players inventory - this effectively puts some upper limit on number of items. Now it certainly is possible that this number of items could be too large, but it just doesn't seem to happen much. I suspect some of this may be because in the case of inventory of containers, the objects may share the same image much greater than the pile of artifacts in the players apartment. I also believe that the socket logic has been improved since the original problem, such that the server has additional buffers and thus more data needs to get generated before the buffers fill up - I think when the problem originally happened, the server was just using the size of the OS's buffer, which was 64k. So to answer your questions: I believe there should be no limit for number of objects in ground view - the reason that limit was put in place was due to socket limitations, which _may_ no longer exist. However, there could still be potential cases where a limit is reached - 1000 objects, or 10,000 objects etc on a ground space may go above even the larger buffers now in place. For containers, if this was an issue, a limit could be put on the number of different objects in a container beyond just weight (limit it to 100 or 200). Forcing cache mode for clients would also help this - the amount of data in an itemcmd isn't too large - maybe couple hundred bytes (assume 256)? So 200 * 256 = 64k It is when sending images (and potentially animation sequence, such that one objects may be 4 images) that you really start using up space. In the ideal case, the server really shouldn't care anything about containers or ground view. What I mean by this is that the client would have the contents of the container, and it is totally up to the client on how to display that (in the ground view, as a child, as a pop up window, etc). The extent of this would be that when the player activates a container, the client would send a request to get the contents of the container. The client could in fact send such a request for all containers in the players inventory when the user logs in. The server would have to some sanity checking in this case (can the player in fact open this container (locked chest for example)). Likewise, whenever the player tries to use an object, it would have to same level of sanity checking (is this container still accessible to the player, and can the player still access it (did not leave the key behind)). Likewise, some method of moving entire contents of one container to someplace else could be done - right now, that seems to be done based on active containers and open containers, if the container is on the ground or not, etc - basically, the client doesn't have anything to do on it, and I think the client could be designed to have a much better way to do this (the client could right now iterate through all the items in the container, but ideally you want some good primitive like 'dump all items in the sack into the chest' Some amount of logic in the server is left over from before the client/server split and how things worked then (which was when you opened a container in your inventory, it would show up in the ground view). There is also some commands still in use which require specific item ordering or view (apply below pretty much requires that the server and client agree on what is 'below'). In the ideal case, apply below should basically be removed or implemented in the client, with the client saying what items to apply - in this way, the stacking of objects below the player is not important. That is relevant because the protocol does not have any good way to preserve stacking or insert an item in the 5th position in a stack. So back to the ground view, this means that when the player drops an item, it basically has to clear and re-send the entire stack of items on the ground. So I think that might have been another reason why a limit on ground stacks was applied - simply because otherwise if you had a big stack, dropping items would result in a large amount of data being sent. I don't know if that answers your question or not :) - but in short summary, I'd say that the limiting of ground stacks to 50 items with next/previous buttons is a bit a hack (one which I wrote) and should go away if possible. After all, the client already has scroll bars - so it has its own way to present the data. From meflin at meflin.net Mon Jul 11 13:47:16 2011 From: meflin at meflin.net (James Lopeman) Date: Mon, 11 Jul 2011 12:47:16 -0600 Subject: [crossfire] Ground and container view In-Reply-To: <4E1A9584.6050004@sonic.net> References: <201107101220.26219.nicolas.weeger@laposte.net> <4E1A9584.6050004@sonic.net> Message-ID: <201107111247.16345.meflin@meflin.net> The container change works out fairly well on the GTK2 client. It also prevents disconnects when you have a bag full of rings and such. Unlimited ground view and container view have a large number of issues. Even inventory view CAN ( and has ) caused client disconects. Containers like ground can hold huge lists and its safter and more consistent for them to be .. consistent. Meflin From nicolas.weeger at laposte.net Mon Jul 11 15:17:40 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 11 Jul 2011 22:17:40 +0200 Subject: [crossfire] Face "overlays" Message-ID: <201107112217.45810.nicolas.weeger@laposte.net> Hello. I've been thinking on how to show what equipment a player is actually using during the gameplay. My current idea is to add "overlays" on faces. It would work something like that: - base player animation doesn't show anything - the eg "armour" overlay is displayed on top of the player, to show the armour being worn - for "compound" animations (eg attacking, and thus), use the same overlay, or a specific overlay This could also be used to add effects for long-time spells, eg a red aura for protection from cold, and such. Examples: - base animation "fenx_player" - for armour, use "overlay_armour_fenx_player" if it exists, else "overlay_armour" for an armor with "overlay_armour" overlay specification - if the Fenx attacks, compound animation is "fenx_player_sword", so use "overlay_armour_fenx_player_sword" if it exists - if the Fenx cast the "rage", add "overlay_rage_fenx_player" if it exists, else "overlay_rage" simply This would of course mean many potential animations... And more face information sent to the client. One other option I thought of is to use a "dynamic" face, in which server tells the client "face (max_face + 2) is a combination of this, this and this face", use this special face for the map2 command, and inform client of face changes when the equipment changes. This of course adds some more complicated logic. What do you think of that? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Tue Jul 12 23:03:58 2011 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Jul 2011 21:03:58 -0700 Subject: [crossfire] Ground and container view In-Reply-To: <201107111247.16345.meflin@meflin.net> References: <201107101220.26219.nicolas.weeger@laposte.net> <4E1A9584.6050004@sonic.net> <201107111247.16345.meflin@meflin.net> Message-ID: <4E1D192E.4050500@sonic.net> On 07/11/11 11:47 AM, James Lopeman wrote: > The container change works out fairly well on the GTK2 client. It also > prevents disconnects when you have a bag full of rings and such. > > Unlimited ground view and container view have a large number of issues. > Even inventory view CAN ( and has ) caused client disconects. > > Containers like ground can hold huge lists and its safter and more consistent > for them to be .. consistent. Certainly the current implementation prevents some issues, but it is a bit of a hack. If one applied the 'click here to see next group of objects' to the players inventory, that would be really odd. And I still hold by the statement that it would be better of the client to have all the data, and let it decide how it wants to display it - having the breaking down long stacks of the objects on the server isn't ideal. A better approach, and one that probably works for all cases of a long list of objects, is to have the server send the list of objects, and when it reaches some amount, it sends some special marker to say that there are more objects on this space/in this container (and container could be players inventory), and in that marker is an object tag - probably the next one to send. The client could then have some command which basically amounts to 'send me the next batch of objects, starting with tag X. The server then does so if applicable (eg, if the player has moved to a new space, and object X is no longer below them, it doesn't send anything or maybe sends an error code). This would work pretty good, because the client wouldn't get that marker until it had read all that data - which means that data isn't queued up on the server. One problem with the current look view method is that the server stores the current position of the look stack - which means that the current method would not scale very well for general case. In the ideal case, the client could also say how large it wants those batches - if on a slow connection, you may want to limit it to 10 objects - after all, if you are in combat and moving through an area, you don't want lag caused when you step onto some huge pile of objects. If on a LAN, you might want that value to be 50 or 100. These changes probably would not be that hard - pretty much all the code is in place - the only thing that may be necessary is slight changes to make the marker more clear. When the server responds to the clients 'send me next batch', it would not send the clear stack command - it would just send the next batch, and repeat as necessary. In theory, right now, the client could intercept the more/previous items in the stack, and apply them, and when it gets them, don't actually clear the stack and add onto it, but this requires adding a lot more complexity than just tweaking the protocol a little bit. The other thought I had, which I think is more work, is have a method where the server just sends the objects tags for what is in the container (eg, sack ....) - since each tag is only 4 bytes, unless we are talking thousands (and potentially tens of thousands) of objects, you would never run into a case of filling up the server. The client could then use some method to get information (requestitem ...) - this is pretty much the same way as it deals with images - the advantage here is that the client could make these requests as it sees fit, and it provides a very efficient method for the server to state everything on an item or space. As noted in my other e-mail, one problem with the floor is that stacking there has to remain consistent between client and server. So when a player drops an object, the server has to re-send the entire contents for the ground view, which includes name, face information, etc. With something like the above, the server could basically send the entire floor look in not many bytes. But this is much more complicated for the client - it basically has to keep orphaned objects around for some amount of time - the protocol would basically be as is now - when the client gets that command for the floor contents, it starts from a clean floor, but in fact, if the player is just dropping an object and not moving, many of those objects currently on the ground will be re-used. This is probably a lot more complicated than it is worth, because tracking stale objects becomes much harder. For example, server sends the stack of objects to the client, and the client requests the full info on them. The player then steps off the stack, and a few ticks later, steps back on, and server sends the tags again. The client still has the tags, but neither the server nor client really know if any of those objects on that space have changed (hit by a lightning bolt and maybe the number of some have decreased, etc). From mwedel at sonic.net Tue Jul 12 23:21:01 2011 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Jul 2011 21:21:01 -0700 Subject: [crossfire] Face "overlays" In-Reply-To: <201107112217.45810.nicolas.weeger@laposte.net> References: <201107112217.45810.nicolas.weeger@laposte.net> Message-ID: <4E1D1D2D.7050805@sonic.net> On 07/11/11 01:17 PM, Nicolas Weeger wrote: > Hello. > > > I've been thinking on how to show what equipment a player is actually using > during the gameplay. > > > My current idea is to add "overlays" on faces. > > > It would work something like that: > - base player animation doesn't show anything > - the eg "armour" overlay is displayed on top of the player, to show the > armour being worn > - for "compound" animations (eg attacking, and thus), use the same overlay, or > a specific overlay > > > This could also be used to add effects for long-time spells, eg a red aura for > protection from cold, and such. > > > Examples: > - base animation "fenx_player" > - for armour, use "overlay_armour_fenx_player" if it exists, else > "overlay_armour" for an armor with "overlay_armour" overlay specification > - if the Fenx attacks, compound animation is "fenx_player_sword", so use > "overlay_armour_fenx_player_sword" if it exists > - if the Fenx cast the "rage", add "overlay_rage_fenx_player" if it exists, > else "overlay_rage" simply > > > This would of course mean many potential animations... And more face > information sent to the client. My question here is does this means that each of those combos above (overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to a unique face/png image on the server? Or is there some level of trickiness going on with how the client assembles those faces? > > > > One other option I thought of is to use a "dynamic" face, in which server > tells the client "face (max_face + 2) is a combination of this, this and this > face", use this special face for the map2 command, and inform client of face > changes when the equipment changes. > > This of course adds some more complicated logic. Answer to the above question sort of determines that answer. Using a unique face (max face +2, +3, +4) probably isn't as hard as one might think - if that face is created (and assigned to the player) when the objects are equipped, most of the sending logic remains the same - the only additional logic would be to communicate what faces make up that unique face value. The method used to currently inform about animation sequences could be used, just with the addition to say 'this is a composite face, not an animation'. The one advantage I see with this approach is that a lot of the code can be re-used. For example, the elf equips a sword. The server sees if there is any animation stacking already created that matches - it finds there is none, so it creates elf_sword, and at the given time, sends it to the client. The elf then casts a protection spell, which adds an aura around the player. Once again, server checks, finds no such animation, and creates a new one (elf_sword_aura), which gets sent to the client. Now at some point, the spell expires, so now we are back to just elf_sword - server checks, it already has this, so it just updates the fact to that value, and is done. It would be the actual map sending code which would see if the client (which may not be the elf players client, but another players client) knows about that animation, and if not, would do the normal routine to send the animation information as well as information about the faces. Note that the animation names above are really used for illustrative purposes - I think when it comes time for the server to see if it is new or old animation, it would have to check the actual image numbers, and not go on name. The compositing of images probably becomes the harder case - in your example above for armor, this means you need different armor images that will properly overlay on the given race - for small and big ones, this probably does not work very well. For more generic things, like auras, size on those is not as important, so they probably work in all cases. From nicolas.weeger at laposte.net Wed Jul 13 13:46:58 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Jul 2011 20:46:58 +0200 Subject: [crossfire] Monster regeneration Message-ID: <201107132047.02247.nicolas.weeger@laposte.net> Hello. I wonder why monsters which are asleep in the dark don't regenerate hp/sp. monster_move() is pretty clear, if the monster is asleep, can't find an enemy, and in the dark, then no regeneration. I'd like to change that, and make monsters regenerate anyway. What do you think of that? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Wed Jul 13 15:25:50 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Jul 2011 22:25:50 +0200 Subject: [crossfire] Face "overlays" In-Reply-To: <4E1D1D2D.7050805@sonic.net> References: <201107112217.45810.nicolas.weeger@laposte.net> <4E1D1D2D.7050805@sonic.net> Message-ID: <201107132225.54497.nicolas.weeger@laposte.net> > My question here is does this means that each of those combos above > (overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to > a unique face/png image on the server? I see animations and overlays working like that: - player has a standard animation, "fenx_player" - each action (using skill or item) can have a temporary animation, like it is currently ; thus "fenx_player_sword" or "fenx_player_spellcasting" - each equippable item defines an overlay ; so "armour" would give the "overlay_armour" face on top of the player's face Of course, items can be specialized for player ; so "overlay_armour" could be "overlay_armour_fenx_player_spellcasting" for a specific spellcasting animation, or "overlay_armour_fenx_player" for the general armour. With fallback so not have to explicitely define everything. > Or is there some level of trickiness going on with how the client > assembles those faces? I see it merely as adding new pictures on top of the player's "main" face. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Wed Jul 13 15:53:05 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Jul 2011 22:53:05 +0200 Subject: [crossfire] CS_STAT_SKILLEXP_ constants Message-ID: <201107132253.08576.nicolas.weeger@laposte.net> Hello. In serve/include/newclient.h are CS_STAT_SKILLEXP_xxx defines, which (from what I remember) are for the old skill system, with only ~6 skills defined. Those are still used by the GTK client (common/commands.c). Unless I'm mistaking (and someone remembers better than me :)), I'll clean that at some point in the future. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Wed Jul 13 22:48:04 2011 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 13 Jul 2011 20:48:04 -0700 Subject: [crossfire] Monster regeneration In-Reply-To: <201107132047.02247.nicolas.weeger@laposte.net> References: <201107132047.02247.nicolas.weeger@laposte.net> Message-ID: <4E1E66F4.6010900@sonic.net> On 07/13/11 11:46 AM, Nicolas Weeger wrote: > Hello. > > I wonder why monsters which are asleep in the dark don't regenerate hp/sp. > > monster_move() is pretty clear, if the monster is asleep, can't find an enemy, > and in the dark, then no regeneration. > > I'd like to change that, and make monsters regenerate anyway. > > > What do you think of that? Sounds good to me. From mwedel at sonic.net Wed Jul 13 22:51:34 2011 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 13 Jul 2011 20:51:34 -0700 Subject: [crossfire] CS_STAT_SKILLEXP_ constants In-Reply-To: <201107132253.08576.nicolas.weeger@laposte.net> References: <201107132253.08576.nicolas.weeger@laposte.net> Message-ID: <4E1E67C6.2000608@sonic.net> On 07/13/11 01:53 PM, Nicolas Weeger wrote: > Hello. > > > In serve/include/newclient.h are CS_STAT_SKILLEXP_xxx defines, which (from what > I remember) are for the old skill system, with only ~6 skills defined. > > Those are still used by the GTK client (common/commands.c). > > > Unless I'm mistaking (and someone remembers better than me :)), I'll clean > that at some point in the future. They can almost certainly be removed. They probably were not removed originally to support older servers that used the old skill systems. From mwedel at sonic.net Wed Jul 13 23:00:02 2011 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 13 Jul 2011 21:00:02 -0700 Subject: [crossfire] Face "overlays" In-Reply-To: <201107132225.54497.nicolas.weeger@laposte.net> References: <201107112217.45810.nicolas.weeger@laposte.net> <4E1D1D2D.7050805@sonic.net> <201107132225.54497.nicolas.weeger@laposte.net> Message-ID: <4E1E69C2.5050107@sonic.net> On 07/13/11 01:25 PM, Nicolas Weeger wrote: >> My question here is does this means that each of those combos above >> (overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to >> a unique face/png image on the server? > > I see animations and overlays working like that: > - player has a standard animation, "fenx_player" > - each action (using skill or item) can have a temporary animation, like it is > currently ; thus "fenx_player_sword" or "fenx_player_spellcasting" > - each equippable item defines an overlay ; so "armour" would give the > "overlay_armour" face on top of the player's face > > Of course, items can be specialized for player ; so "overlay_armour" could be > "overlay_armour_fenx_player_spellcasting" for a specific spellcasting > animation, or "overlay_armour_fenx_player" for the general armour. > > > With fallback so not have to explicitely define everything. > > > > >> Or is there some level of trickiness going on with how the client >> assembles those faces? > > I see it merely as adding new pictures on top of the player's "main" face. But is the client assembling these images, or have all these images been pre-assembled on the server (and thus, they are valid images)? If the client is left to do this layering, then somehow, it needs to know what faces to layer for any given object (typically players, but one could see reason to add this to monsters). From my reading, which could be wrong, it sounds like the server would have these composite images - thus, the server itself would have a lot more images, but really no change in the protocol is needed - the server would just know to use different faces and send those to the client, which would just display it. For a small number of combinations, that works pretty well. But if you start to have multiple things you may layer, the combinations multiply up pretty fast. For example, weapon + armor + aura could be hundreds of new images (say 5 weapons, 5 armors, and 5 auras = 125). These would all have to either be images in the arch directory tree, or created during the collect process. I'd personally think that having the client do the layering would be much better - one could have the number of combinations be much larger without having issues (eg, 10 armors x 10 weapons x 10 auras x 50 monsters = 50,000 image combos). From nicolas.weeger at laposte.net Thu Jul 14 08:35:44 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jul 2011 15:35:44 +0200 Subject: [crossfire] Face "overlays" In-Reply-To: <4E1E69C2.5050107@sonic.net> References: <201107112217.45810.nicolas.weeger@laposte.net> <201107132225.54497.nicolas.weeger@laposte.net> <4E1E69C2.5050107@sonic.net> Message-ID: <201107141535.48756.nicolas.weeger@laposte.net> > But is the client assembling these images, or have all these images been > pre-assembled on the server (and thus, they are valid images)? That's one my questions, and something I'm asking other people for opinion :) Two options, server sends all needed faces at the same time ("overlays to the player face") ; or server sends a special face the client knows to be a combination of faces. > If the client is left to do this layering, then somehow, it needs to know > what faces to layer for any given object (typically players, but one could > see reason to add this to monsters). Overlays will be attached to a face in the map2 command, so a specific layer. > From my reading, which could be wrong, it sounds like the server would > have these composite images - thus, the server itself would have a lot > more images, but really no change in the protocol is needed - the server > would just know to use different faces and send those to the client, which > would just display it. That's what I'm thinking about. Server has all images, and looks for correct animations. > For a small number of combinations, that works pretty well. But if you > start to have multiple things you may layer, the combinations multiply up > pretty fast. For example, weapon + armor + aura could be hundreds of new > images (say 5 weapons, 5 armors, and 5 auras = 125). These would all have > to either be images in the arch directory tree, or created during the > collect process. Err no, I see it as 5 weapons, 5 armors, and 5 auras. And they get stacked to produce the final picture. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Thu Jul 14 08:44:38 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jul 2011 15:44:38 +0200 Subject: [crossfire] Monster regeneration In-Reply-To: <4E1E66F4.6010900@sonic.net> References: <201107132047.02247.nicolas.weeger@laposte.net> <4E1E66F4.6010900@sonic.net> Message-ID: <201107141544.39073.nicolas.weeger@laposte.net> > Sounds good to me. Changed in sources. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Thu Jul 14 09:34:39 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Jul 2011 16:34:39 +0200 Subject: [crossfire] Compressed file support Message-ID: <201107141634.43756.nicolas.weeger@laposte.net> Hello. Unless someone is totally against, I'd like to remove support for compressed files (through open_and_uncompress_file() and friends). I don't see the use of that feature, to be honest :) (which AFAIK never was used) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Thu Jul 14 22:41:44 2011 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Jul 2011 20:41:44 -0700 Subject: [crossfire] Face "overlays" In-Reply-To: <201107141535.48756.nicolas.weeger@laposte.net> References: <201107112217.45810.nicolas.weeger@laposte.net> <201107132225.54497.nicolas.weeger@laposte.net> <4E1E69C2.5050107@sonic.net> <201107141535.48756.nicolas.weeger@laposte.net> Message-ID: <4E1FB6F8.6050700@sonic.net> On 07/14/11 06:35 AM, Nicolas Weeger wrote: >> But is the client assembling these images, or have all these images been >> pre-assembled on the server (and thus, they are valid images)? > > That's one my questions, and something I'm asking other people for opinion :) > > > Two options, server sends all needed faces at the same time ("overlays to the > player face") ; or server sends a special face the client knows to be a > combination of faces. Ah - so it sounds like you are looking at one of these 2 possibilites: 1) Server sends all needed faces for the player - this means that for a player, it may have to send 4+ images for the player (aura, armor, weapon, base image) - of course, this could be higher. 2) Server generates a composite face, sends information on what that composite face is, and thus only needs to send 1 face in the protocol command, but it may end up sending a bunch of other information for to tell the server what that composite face is. My gut instinct is that #2 would actually be easier. For #1, I think it may require potentially more protocol changes (there may be issues with number of layers, so some extension for that, and the map send code would have to look at the object and see if that given object has overlays that need to get sent, look those up) - I'm just not sure how efficient that would be. In case #2, all the map logic is basically unchanged (note that some extra logic would be needed to send non layered face information for old clients) - the generation of the composite face can all be done when the player equips the items/does those actions. But I guess it really depends on how hard it is to check the layered faces for an object, or maybe additional structures are needed to hold those. I'm just thinking that in a more generic usage, one might want to use overlays for monsters (I'm thinking more for auras and not armor/equipment), so probably good to make sure a solution is chosen that works for everything, not just players. From mwedel at sonic.net Thu Jul 14 22:48:22 2011 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Jul 2011 20:48:22 -0700 Subject: [crossfire] Compressed file support In-Reply-To: <201107141634.43756.nicolas.weeger@laposte.net> References: <201107141634.43756.nicolas.weeger@laposte.net> Message-ID: <4E1FB886.8000007@sonic.net> On 07/14/11 07:34 AM, Nicolas Weeger wrote: > Hello. > > > Unless someone is totally against, I'd like to remove support for compressed > files (through open_and_uncompress_file() and friends). > > > I don't see the use of that feature, to be honest :) > (which AFAIK never was used) > Sounds good to me. That is something that was leftover from days distant pass where the amount of space used by those files might be a concern. But that probably hasn't been the case for 10+ years. From nicolas.weeger at laposte.net Sat Jul 16 03:45:57 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 16 Jul 2011 10:45:57 +0200 Subject: [crossfire] Face "overlays" In-Reply-To: <4E1FB6F8.6050700@sonic.net> References: <201107112217.45810.nicolas.weeger@laposte.net> <201107141535.48756.nicolas.weeger@laposte.net> <4E1FB6F8.6050700@sonic.net> Message-ID: <201107161046.01730.nicolas.weeger@laposte.net> > Ah - so it sounds like you are looking at one of these 2 possibilites: Correct :) > My gut instinct is that #2 would actually be easier. For #1, I think it > may require potentially more protocol changes (there may be issues with > number of layers, so some extension for that, and the map send code would > have to look at the object and see if that given object has overlays that > need to get sent, look those up) - I'm just not sure how efficient that > would be. #2 seems nice too, but this also means there will be a need for many "temporary" images. Imagine the player with a basic armor, and the associated overlay. There will be 4 (for most races) directions * 3 pictures (for most animations) so 12 composite images. Now the player casts a spell - that's another animation, so 4*3 pictures again. So I'm wondering how many pictures that will imply at total... One way would be for the server to find all "action-related" animations (so "player_fenx_spellcasting" and friends) and for each regenerate temporary faces for any face. That could mean 200 faces for a player. Maybe not that a big evil deal... Also it seems the server will need to send faces updates at almost each equipment change. Probably not that a big deal either, but still. For clients not having this support, the fallback would be simply to send the regular player face, imo. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Sun Jul 17 22:33:13 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Jul 2011 20:33:13 -0700 Subject: [crossfire] Face "overlays" In-Reply-To: <201107161046.01730.nicolas.weeger@laposte.net> References: <201107112217.45810.nicolas.weeger@laposte.net> <201107141535.48756.nicolas.weeger@laposte.net> <4E1FB6F8.6050700@sonic.net> <201107161046.01730.nicolas.weeger@laposte.net> Message-ID: <4E23A979.1010409@sonic.net> On 07/16/11 01:45 AM, Nicolas Weeger wrote: >> Ah - so it sounds like you are looking at one of these 2 possibilites: > > > > Correct :) > > > >> My gut instinct is that #2 would actually be easier. For #1, I think it >> may require potentially more protocol changes (there may be issues with >> number of layers, so some extension for that, and the map send code would >> have to look at the object and see if that given object has overlays that >> need to get sent, look those up) - I'm just not sure how efficient that >> would be. > > > #2 seems nice too, but this also means there will be a need for many > "temporary" images. > > Imagine the player with a basic armor, and the associated overlay. There will > be 4 (for most races) directions * 3 pictures (for most animations) so 12 > composite images. > > Now the player casts a spell - that's another animation, so 4*3 pictures > again. I wonder if the composite images could also include the animations - for some, that may not work if it is a single run action, but for others, one could imagine it would work . In particular, I'm thinking auras might be something animated to some degree, but the timing on those really isn't critical (if the aura animation is a little off from what the server things it should be, no big deal). But likewise, if the armor or weapon is animated (flaming swords, special armor), same thing - those are basically a loop, and if the timing is off on the client, no problem. Casting is trickier (as may be attacks), as you do those once (more for spells). OTOH, attacks maybe should also be a cycle. So one could imagine that if you add a composite image protocol command (cmpimage), it could be something like: cmpimage [|](and repeat those) Type could basically just describe the next set of data that follows. If that data is an animation, the server would have to send the animation. Of course same is true for face - if the face has not been sent, has to get sent to the client also. Directions would still be an issue, as that is 4x or 8x the number of images. > > > So I'm wondering how many pictures that will imply at total... > > > One way would be for the server to find all "action-related" animations (so > "player_fenx_spellcasting" and friends) and for each regenerate temporary > faces for any face. That could mean 200 faces for a player. Maybe not that a > big evil deal... On the server, that is not much a concern - the amount of data for each one probably would not be that much (50 bytes?) A bigger concern I would have would be that if one used a simple method (new composite face = composite face +1), on a long running server, one could go beyond 16 bits (65536 composite faces), which may mean that the server is unable to properly send the data to the client. Realistically, probably want to use a hash table that can hash the faces/animations for the composite image - that makes lookup much faster, and one could limit the hash table size to how many bits the protocol can handle (nearest prime less than 65535 for example). If the hash table fills up, the server could basically just give up an die. A more complex approach could be that each client connection has a lookup table - while it is conceivable that the server will go beyond 16 bits, it is pretty unlikely that a client would see all of those. So for each client, the server could literally start at zero and start increasing as that client encounters more and more composite faces. But that does not have to be in the original design - if that proves to be an issue, it could always be added later. > > > > Also it seems the server will need to send faces updates at almost each > equipment change. Probably not that a big deal either, but still. Yes - for each equipment change, there is the potential of a composite face protocol command. But if the player is not changing equipment all the time (eg, the change in question lasts for a little time) or the player cycles between a few established ones (casting, combat, moving, certain aura going up and down), it probably would not take too long (and many composite image commands) for the client to get all of those, and the server now saves bandwidth on those future updates. For example, if one has to send all the images that make up the player, than that may be 8 bytes (base + armor + weapon + aura) for that, but once it is established, it is just 2 bytes (composite image). The composite image command itself is probably something like 20 bytes? Protocol command (cmpimage?) + 2 bytes for the number + the 8-12 of the actual images. So one doesn't have to use it too many times to come out ahead. > For clients not having this support, the fallback would be simply to send the > regular player face, imo. Yes - the only thing would be that in this case, the composite image, if it exists, should probably be stored in a different field in the object, and not replace the face - then it is very easy. If ob->composite_image !=0 and client supports it, send composite image. Otherwise, send ob->face Some users/clients could also choose to turn it off in such a model - maybe they have a slow system so the extra faces take more time to draw or more bandwidth than they really want to give. From nicolas.weeger at laposte.net Fri Jul 22 15:32:45 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 22 Jul 2011 22:32:45 +0200 Subject: [crossfire] Ground and container view In-Reply-To: <201107101220.26219.nicolas.weeger@laposte.net> References: <201107101220.26219.nicolas.weeger@laposte.net> Message-ID: <201107222232.49806.nicolas.weeger@laposte.net> Hello. Considering the issues James reported, I guess I'll let the paging behaviour like it is for now... If anyone disagrees, then feel free to revert or adjust my change :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sat Jul 23 06:54:32 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 23 Jul 2011 13:54:32 +0200 Subject: [crossfire] Quest dialog Message-ID: <201107231354.35241.nicolas.weeger@laposte.net> Hello. I've commited to the server new protocol commands to notify the client of quest-related changes. Support was added to JXClient (which now features a "quests" dialog), GTK2 is left as an exercice to someone feeling like doing it :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sat Jul 23 10:45:24 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 23 Jul 2011 17:45:24 +0200 Subject: [crossfire] Thaumaturgy changes Message-ID: <201107231745.27888.nicolas.weeger@laposte.net> Hello. Thaumaturgy recipes had the first recipe at difficulty 20. This means it's pretty hard to level up in that skill, apart identifying some zillion wands and rods. So I've added a new archetype, "horn base", that can be made at low level (difficulty 5, meaning 42% chance at level 1). I've also changed other horn recipes to use that archetype instead of the unicorn horn - which is present in many recipes, btw. If anyone has other ideas, feel free to let me know :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: