missing server messages

[Florian]

Btw, when you log in with active shield spell, no SEND_BUFFS package is received.

 

My bad. add_actor also has the buffs, so I'll have to call some update function there too ...

 

Radu, what did you expect to be with particles?

The screenshot only shows the buff icons, not the eye candy effect for that buff.

[Torg]

Just store the state in a flag. I (and ecraven) did something similar on berlios way back when (harvesting animation, http://developer.berlios.de/patch/?func=de...p;group_id=1256 )

Ahhh, but if you stop harvesting while resyncing then no message is shown (afaik) and hence the flag is out of sync.

 

My bad. add_actor also has the buffs, so I'll have to call some update function there too ...

I guess the special effects functions should be checked at this point, regarding Piper's comment about the shield not redisplaying.

[Florian]

My current implementation ideas looks like this:

 

- the buffs have to be parsed every frame, to display the icons correctly. the buffs are already in the actor struct

- the corresponding ec_references for the effects will also be stored in the actor struct. add_actor, add_enhancecd_actor, the function that removes actors which I haven't found yet, for short: every function that changes the actor list will get a "update/remove all ec references for buffs for this actor" call

 

I think I'll have to write something like the eye candy debug window to switch all buffs on and off w/o magic to make testing/debugging faster. the shield just doesn't wear off fast enough if you want to test something

[Florian]

OK, the BUFFS are in CVS.

 

I hope I didn't forget any files or #defines or break anything.

 

Please test it.

 

TODO:

- actors who log in with buffs don't get their buffs set correctly.

- more testing, of course

[LeFallen]

Ahhh, but if you stop harvesting while resyncing then no message is shown (afaik) and hence the flag is out of sync.

Why aren't these sorts of things server messages anyway? Scraping messages from the server and "guessing" states like this seems stupid. Is it a technical limitation of some kind? It'd sure make bot coding easier too

Edited November 20, 2008 by Le Fallen

[Torg]

Is it a technical limitation of some kind?

Yes. It's not coded into the server. :-P

 

Basically there is 1 byte assigned for "commands", that means 256 possible different commands sent from the server. I assume that early on in the development it wasn't thought that there would be ways to display these things graphically (or a need) and so they were sent as raw text instead to conserve space for other commands.

 

It'd sure make bot coding easier too

Why? Bot's aren't allowed to harvest, etc.

[LeFallen]

Basically there is 1 byte assigned for "commands", that means 256 possible different commands sent from the server. I assume that early on in the development it wasn't thought that there would be ways to display these things graphically (or a need) and so they were sent as raw text instead to conserve space for other commands.

I just mean when the decision was made to have a harvesting effect, the first thing that should have happened was the creation of a message of some kind. The 1 byte isn't really a limitation as you could have an EVENT message (for example) and extended information in that. Worst case you have a EXTENDED_MSG message that then gives you another 255. Either would be much nicer than looking for a particular string or the +harv xp. Another place where this seems really bad is the counters.

 

Why? Bot's aren't allowed to harvest, etc.

I was more referring to other areas. Stuff like location retrieval returns a string via RAW_TEXT. And you have to look for "Trade request from" to detect a trade request etc. To be fair though, the game was obviously never designed for much of the data to be interpreted, just displayed.

[Torg]

I just mean when the decision was made to have a harvesting effect, the first thing that should have happened was the creation of a message of some kind.

In what regards? The idea of having a harvest effect in the client was simply a client dev who thought it would look cool. The message "You have started harvesting" has been sent from the server since the days back when you had to manually click for each harvest (similar to how you used to have to click for each manufacture).

 

I think the problem you have discovered is that there are many client devs (from time to time) but there are only 2 server devs and they are generally very busy coding other things. You will find the forums full of suggestions for extensions to the protocol, especially for coding bots.

 

The 1 byte isn't really a limitation as you could have an EVENT message (for example) and extended information in that. Worst case you have a EXTENDED_MSG message that then gives you another 255. Either would be much nicer than looking for a particular string or the +harv xp. Another place where this seems really bad is the counters.

Of course, but this comes back to the problem that Ent (head server dev and owner etc) doesn't want to spend time coding protocol to support these features. He mostly wants to add new things into the game to keep it interesting for people.

 

I was more referring to other areas. Stuff like location retrieval returns a string via RAW_TEXT. And you have to look for "Trade request from" to detect a trade request etc. To be fair though, the game was obviously never designed for much of the data to be interpreted, just displayed.

Exactly. That is the problem indeed.

[LeFallen]

In what regards? The idea of having a harvest effect in the client was simply a client dev who thought it would look cool. The message "You have started harvesting" has been sent from the server since the days back when you had to manually click for each harvest (similar to how you used to have to click for each manufacture).

I do understand the limitations from the server development side of things but I don't think dirty client hacks are a solution.

 

When confronted with a requirement one needs to ensure that it is implemented correctly or hacks of hacks of hacks will end up being required and the product will suffer greatly for it. Again I think the counters thing is a great example. It depends on so many messages and other things to try to track this information. I doubt it even does so accurately.

 

That kind of coding is just scary IMHO. While it's not the most desirable from the users to wait, getting a server msg delivering the REAL data would be much more preferable and I think any real developer (not to say you aren't one) would agree that it's the cleaner, better solution.

[Torg]

I do understand the limitations from the server development side of things but I don't think dirty client hacks are a solution.

Agreed, it is nasty and will eventually cause problems with hacks on hacks. We all know that.

 

Again I think the counters thing is a great example. It depends on so many messages and other things to try to track this information. I doubt it even does so accurately.

Of course it doesn't. A perfect example of that is deaths. A death is determined by searching the actor list for an actor in the map square directly in front of you when you die. It is simply a guess, but in multi-combat maps, that might not have been the character to serve the killing blow. There is no way of knowing.

 

On top of that, it needed to be adjusted to include the 2 map squares in-front of you to handle chims, as they take up 2 map squares in terms of walking/access, but naturally the map square in the actor information is only 1 of those 2 squares.

 

Then there is the case of all this data only being stored locally on your machine, so if you use another machine, or delete your user dir, your start your counters back at 0 and they won't ever add to the counters on your main machine.

 

You can find the thread about it here: http://www.eternal-lands.com/forum/index.php?showtopic=23878

 

While it's not the most desirable from the users to wait, getting a server msg delivering the REAL data would be much more preferable and I think any real developer (not to say you aren't one) would agree that it's the cleaner, better solution.

Tell that to Ent. He isn't interested in "wasting time" coding that sort of thing. Therefore, sometimes the only way to get it into the client is to hack it.

 

It sux, but that's how half of the client is done.

 

That said, it is getting better. There have been a few protocol issues brought to him recently that he has considered.

 

It would be preferable to have a client dev that has access to the server codebase and is specifically assigned to maintaining and extending the client/server protocols. It is relatively unlikely to happen, because that adds another level of potential failure in the server, which Ent is very protective of (understandably).

[Entropy]

I do understand the limitations from the server development side of things but I don't think dirty client hacks are a solution.

 

When confronted with a requirement one needs to ensure that it is implemented correctly or hacks of hacks of hacks will end up being required and the product will suffer greatly for it. Again I think the counters thing is a great example. It depends on so many messages and other things to try to track this information. I doubt it even does so accurately.

 

That kind of coding is just scary IMHO. While it's not the most desirable from the users to wait, getting a server msg delivering the REAL data would be much more preferable and I think any real developer (not to say you aren't one) would agree that it's the cleaner, better solution.

 

The reason why there is no server support for that is that no one asked me to implement it.

[Alberich]

Is it possible to scale down the icons over the heads to 1/4 of their size?

with many people in pk it gets confusing

[Florian]

When you log in with shield buff active, this buff is not set by the SEND_BUFFS package when you change maps, and it's not set by the initial add_actor package.

 

Is it possible to scale down the icons over the heads to 1/4 of their size?

with many people in pk it gets confusing

 

I'm currently working on customizable icon size

 

/EDIT: customizable buff icon size is now in CVS

Edited December 5, 2008 by Florian

[bluap]

I'm currently working on customizable icon size

/EDIT: customizable buff icon size is now in CVS

I haven't been following this thread but I've just reread it. I'm sorry to say I don't understand the reason for the icons over your head. What's more I don't really like them. Sorry about that, just my personal opinion. Could the size option be changed to turn them off completely when the value is set to zero?

[Alberich]

I'm sorry to say I don't understand the reason for the icons over your head.

I don't know if you missed this point... it's mainly to see what spells others have active.

But I agree icons over your own head are not really necessary, although I like them because in pk it's nice since you see more of your critical stats on one view (health & MI, only mana missing now).

 

Also without eye candy you wouldn't see the buffs and with eye candy plus many different spells active it hard to tell which one is on.

[Learner]

I'm sorry to say I don't understand the reason for the icons over your head.

I don't know if you missed this point... it's mainly to see what spells others have active.

But I agree icons over your own head are not really necessary, although I like them because in pk it's nice since you see more of your critical stats on one view (health & MI, only mana missing now).

 

Also without eye candy you wouldn't see the buffs and with eye candy plus many different spells active it hard to tell which one is on.

Even though I don't PK, I don't feel you should easily see what spells someone has active. That defeats many defensive strategies.

[bluap]

I don't know if you missed this point... it's mainly to see what spells others have active.

But I agree icons over your own head are not really necessary, although I like them because in pk it's nice since you see more of your critical stats on one view (health & MI, only mana missing now).

 

Also without eye candy you wouldn't see the buffs and with eye candy plus many different spells active it hard to tell which one is on.

I suspected PKers might find it useful, I've not explored that activity though. I've only tried the shield spell which is obvious from the eyecandy. I'm only asking for an off switch for my view though, reconfigurability is the EL way.

[Entropy]

Even though I don't PK, I don't feel you should easily see what spells someone has active. That defeats many defensive strategies.

 

'In the real world' you would be able to see if someone has a magic spell on them, at least that's how it is in movies and other games.

And since you are able to see the weapons and armors, col and so on, I think it's only nice to see the spells as well.

[The_Piper]

'In the real world' you would be able to see if someone has a magic spell on them, at least that's how it is in movies and other games.

And since you are able to see the weapons and armors, col and so on, I think it's only nice to see the spells as well.

 

In the 'real world' you are able to hide a dagger under your cloak, for example, so the fact of surprise is a nice thing to think about it.

 

Why should every enemy be able to see how you organize your defense?

 

Isnt that too easy to PK?

 

If someone attacks someone, why must this guy know, how the other guy defends himself?

 

Piper

[Florian]

int view_buffs from buffs.h, used in actors.c

0 means icons off

1 means icons on

 

feel free to hack elconfig.c

 

Even though I don't PK, I don't feel you should easily see what spells someone has active. That defeats many defensive strategies.

 

That's what I told Ent. but he wants it in the game. In WoW you can even see how long other player's buffs last.

Edited December 6, 2008 by Florian

[Light Lan]

In the 'real world' you are able to hide a dagger under your cloak, for example, so the fact of surprise is a nice thing to think about it.

 

in el you are able to hide any weapon and armor in your inv.

also you could wait with casting the spell when the enemy comes.

as soon as you use it he sees it.

[bluap]

int view_buffs from buffs.h, used in actors.c

0 means icons off

1 means icons on

 

feel free to hack elconfig.c

I've hacked away. There was a bit of strangeness to resolve due to the spin widget setting the new value before your range checking code could do its stuff so I hope you are happy with my changes. The result is the same, a value of zero (or <5) will turn off the icons.

[bluap]

When you log in with shield buff active, this buff is not set by the SEND_BUFFS package when you change maps, and it's not set by the initial add_actor package.

In the original 1.7.0 release, if you login with an active shield or magic immunity, the eye candy effect starts as you'd expect. With the CVS version, not only do you not get the overhead icons, the eye candy effect is missing too. However, the bottom left icons are here. Is this something you are working to fix?

[Florian]

In the original 1.7.0 release, if you login with an active shield or magic immunity, the eye candy effect starts as you'd expect. With the CVS version, not only do you not get the overhead icons, the eye candy effect is missing too. However, the bottom left icons are here. Is this something you are working to fix?

The 1.7.0 doesn't use the buffs information of the actor, it uses the code in spells.c.

--> http://cvs.berlios.de/cgi-bin/viewvc.cgi/e...amp;sortby=date search for "// check ongoing Eye Candy effect"

 

I suspect the server doesn't send "old" buffs when you relog, but it does send some "spells you have" message.

[Entropy]

Yes, not all the buffs are sent on relogin. I'll fix this after I am done with the instances (so a few days).