Post: #1

I was just trying to make some effects using sendpacket. Although it brought a few questions/problems.

Quote:1, How do you personally use sendpacket - moving items - to make a good effect without lags, bugs, simply pure and fluent?

Tried, for instance:
for 30
sendpacket bla bla bla
endfor

30 moving items is quite much I quess, I had to increase the speed to minimalize lags. (just example, the number should be higher)

2, Who do you send them to.
-sector? Not perfect... when 1 player is standing in sector 1, and 2. player in sector two, one of them dont see the effect.
-room? doesnt work (at least, not to me)
-region? (isnt it unnecessarily big?)
-serv...(...)
-forplayers/forchars? Well, I tried, but it seemed to be slower and less fluent

In conclusion and for those who dont want to read the craps above - How do you make more complicated effects without lags, or eventual client crashes (because of too many packets)

I see the only way and its - forplayers; sendpacket; endfor...

Post: #2

What you mean about less slower and fluent ?

Anyway, I think that the main problem is not to find "the best way" to implement them, but limiting how many times the players will be able to use the functions/spells that will "trigger" those graphical's packet.

Post: #3

Depends on the nature of the effect itself.

First: I use forclient only and nothing else, to send the packets directly to the clients.

Next:
You should be a bit more specific here, i think you can't do a general approach for large effects, which will work smooth enough in most cases.


My personal approach is to not use many packets, but animated items, some patched for that single effect. I do quite large effects, like fire rains, thunder storms, dragon breaths as spell effects, but never had to move 30 items for that at once at a single point in time (which is what your for-loop does).

Post: #4

(04-25-2013 05:55 AM)darksun84 Wrote:  What you mean about less slower and fluent ?

Anyway, I think that the main problem is not to find "the best way" to implement them, but limiting how many times the players will be able to use the functions/spells that will "trigger" those graphical's packet.

Ye, true... I used timer memory, to be sure players clients won't crash.

Btw. an example of larger effect I made.

Quote:local.x= <r3,7>
sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<p.x> W<eval(<p.y>+<local.x>)> B<eval(<p.z>+12)> B<dlocal.x> B1 00 00 00 00 D0 D0
for 0 <eval <local.x> -1>
sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<eval((<p.x>-1)-<dlocal._for>)> W<eval((<p.y>+<local.x>)-<dlocal._for>)> B<eval(<p.z>+13)> B<dlocal.x> B1 00 00 00 00 D0 D0
endfor

sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<eval(<p.x>-<local.x>)> W<p.y> B<eval(<p.z>+12)> B<dlocal.x> B1 00 00 00 00 D0 D0
for 0 <eval <local.x> -1>
sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<eval((<p.x>-<local.x>)+<dlocal._for>)> W<eval((<p.y>-1)-<dlocal._for>)> B<eval(<p.z>+13)> B<dlocal.x> B1 00 00 00 00 D0 D0
endfor

sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<p.x> W<eval(<p.y>-<local.x>)> B<eval(<p.z>+12)> B<dlocal.x> B1 00 00 00 00 D0 D0
for 0 <eval <local.x> -1>
sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<eval((<p.x>+1)+<dlocal._for>)> W<eval((<p.y>-<local.x>)+<dlocal._for>)> B<eval(<p.z>+13)> B<dlocal.x> B1 00 00 00 00 D0 D0
endfor

sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<eval(<p.x>+<local.x>)> W<p.y> B<eval(<p.z>+12)> B<dlocal.x> B1 00 00 00 00 D0 D0
for 0 <eval <local.x> -1>
sector.allclients sendpacket 0c0 00 D0 D0 W036d4 W<p.x> W<p.y> B<eval(<p.z>+12)> W<eval((<p.x>+<local.x>)-<dlocal._for>)> W<eval((<p.y>+1)+<dlocal._for>)> B<eval(<p.z>+13)> B<dlocal.x> B1 00 00 00 00 D0 D0
endfor
ef_daemon_element_spell_damage <local.x>

[function ef_daemon_element_spell_damage]
local.x = <uid>
forchars <argn1>
if !(<npc>==brain_undead) && (<canseelos> == 1) && !(<local.x> == <uid>)
damage <getarg <uid.<local.x>.tag.element>,<def.daemon_element_damage>>,<getarg <uid.<local.x>.tag.element>,<def.daemon_element_type_dmg>>,<local.x>
effect 3,<getarg <uid.<local.x>.tag.element>,<def.daemon_element_effect_id>>,1,10,0,<getarg <uid.<local.x>.tag.element>,<def.daemon_element_color_spell>>,0
endif
endfor

cso, thats why I'm afraid it might cause problems. ( Ignore sector and those tags.. )

Post: #5

Ok.

I would limit it to 15 or 20 of those fireballs. Should be enough to display that effect to look nice - damage done effectively is another thing but does not have to be related to how many of those fireballs are around. You just use the range to determine the area of effect ... you might be better off to skip some packages (every second or so) if you have some higher values in local.x.


To optimize this one:
Do all those for-loops without sending those packets. Something like that:


Try to count and save all those packets in some locals first. With that you save up time calculating all those coordinates during your sendpacket-statement.

Then send them all at once, rather than looking up your clients all the time.

Post: #6

Are you all running server's and client's on dial up networks that you can't afford a couple dozen packets? Or is it that your Pentium MMX computers cant draw that many effects?

Post: #7

Sinclair spectrum ZX81

Post: #8

While PvP 20+ players might gather in a small area. You have there some aura effects, single spell effects and these AoE spells + other carculations/skills, ... Are you sure that being careful with how many packets you are(are you?) sending, is negligible?

Post: #9

Lets say the average game packet is 20 bytes... so if you're server sent/received 100 of them in 1 second to 1 player, that would be 2k bytes/sec.

If there were 100 players standing there rubbing elbows and each player got the same traffic, 200k bytes/sec...

Bandwidth is usually measured in "bits" (8 bits to the byte), so 200,000 x 8 = 1,600,000 ... in other words 1.6 Mbit which is probably still less than most home cable connections can support in "upload" traffic (download is typically 10 times as much.)

So my question to you is... is there evidence that big effects like this are actually a problem that needs to be solved?

That having been said... I wouldn't be surprised if the client software (of which there are many possible supported versions) has limits on the amount of packets it can process before it crashes, but until we know what that limit is, we can't give advice on how big your effects should be.

Post: #10

Actually, you might get the amount of packets you can send if you try sending them at once and noting when the client crashes. But that's not what I wanted - to tell me how big effects should be(the exact number!)

I just wanted to know, how you make them and who do you send them to. Or what experience do you have with them. Because I was playing on some shard and if you did lots of actions, the client simply shuted down and it often happened whilst somebody was casting AoE spells this type.

I was not GM there, I didn't see the script.

My script works, but the point is to have it as good as it's possible and don't send unnecessarily high amount of packets, or do unnecessary steps in my script.

Ty sco, quess you share the same opinion that effects shouldn't be so large. Actually, I overlooked forclients, so thanks for that too.

Sorry for bothering...