Status Change Issue

[Maki]

Ind

I've encountered a bug I'd rather discuss the fix so we get the best option around.

I'll use renovatio as the example, however there are about to 5 others in the same situation.

Renovation is meant to last 90s but its iteration tick is 5s so it heals every 5s, however this affects the display in the client, being it sends the icon to last for 5s and then it goes negative until it reaches -85.

The first I thought was:

Oh OK we save the iteration tick and after we send the icon we set the tick = the iteration tick.

However the above is quite of a waste :[ we have about to 600SCs processed through the same function and the above would be only useful to about 1% of them. Do you have any work-around suggestion that would save performance?

Thank you for your time

[Maki]

GodLesZ

Is this the result of a test?

I thought the status data (ID, icon, tick) is only send once upon status start and cleared on status_change_end().

status_change_timer() should never resend data to the client for general status effects. This would be failed by design in my opinion.

If this is the actuall state, we should think about an optimisation!

Anyways, if this occours for these "<effect> per tick" effects, how is i.e. berserk worken? The effect SC_BERSERK reduce the HP by 5% every 10 seconds and i never recognized a bug in the timer overlay o.o

[Maki]

Ind

Yes it is sent only once and the effect works fine, the issue is the following: the timer is set to the 5s interval, and this 5s is sent to the client as the effect duration (while its actual duration is 90s), to fix this my first thought (and imo not a good approach performance-wise) was to create a temp var to store the actual duration to send it to the client in these cases; so that the icon timer matches the actual duration (at this time it isn't, test renovatio if you'd like to see it live)

[Maki]

GodLesZ

Damn i got it, sorry x.x

Unfortunately i can not test nor debug atm, so how is berserk working? I checked the code and could confirm, berserk works the same way and sends the delay of 10 seconds as duration to the client.

Could someone test this please?

If berserk also got this problem, any other skil with a "effect per tick over time" feature will need this fix and your first approach should be fine

I.e. here berserks status initialisation (line 6131+):

		case SC_BERSERK:
		if (!sc->data[sC_ENDURE] || !sc->data[sC_ENDURE]->val4)
			sc_start4(bl, SC_ENDURE, 100,10,0,0,2, tick);
		//HP healing is performing after the calc_status call.
		//Val2 holds HP penalty
		if (!val4) val4 = skill_get_time2(status_sc2skill(type),val1);
		if (!val4) val4 = 10000; //Val4 holds damage interval
		val3 = tick/val4; //val3 holds skill duration
		tick = val4;
		break;

The important part is the rarly found comment after val4: Val4 holds damage interval

And of course the tick setting: tick = val4;

At the end of initialisation, this tick is used in the clif send (line 7252+):

	if( vd && (pcdb_checkid(vd->class_) || bl->type == BL_MER || bl->type == BL_MOB ) )
	clif_status_change(bl,StatusIconChangeTable[type],1,tick,(val_flag&1)?val1:1,(val_flag&2)?val2:0,(val_flag&4)?val3:0);

i checked it more than once and the tick is never touched in case of berserk, so this problem HAS to be the problem for all "effect per tick over time".

[Maki]

Ind

berserk uses a endure icon in the client, which also goes negative.

[Maki]

GodLesZ

Okay, sounds strange..

2 possible options i think:

1. find all "effect per tick over time" effects or any effect changing the tick value, add a 2nd variable for status duration and compare them before clif_status_change(). If the 2nd variable is above zero, send this a the tick.
   
2. how about storing the tick given before any change is added and use this as the duration send to the client? The tick is given as parameter in status_change_start() and reduced by resistances in line 5228. We could store them in "duration" (i.e.) and send this to the client.
   

Any other judgment?

[Maki]

GodLesZ

eh guess we can't run from doing it

I dont have any other ideas for this problem.

In fact we need a 2nd storage for the real status duration, no matter where, we need them to tell the client the real duration, not only a status tick time.

Ind

OK ended up like this r30 (bottom)

[Maki]

Not a soluiton about the merit of question...

But how much of performance it will mess???

Because, I do think this way Ind, if we are trying to make something closer to Aegis or better than eA, it will also may increase the requeriments... Just to have an idea, when I was on Gravity, to run Chaos server and Loki server we had like 37 machines running the whole thing...

What we have in private servers are like one single part of a server (cause most of private servers are shared) running Login, Char and Map server... XD

So, a small increase on requeriments, I do belive is something which may be needed...

This implementation wont need any noticeable performance issues, because of its only a new variable, used in less than 30 places. So dont worry about your CPU or memory. 4 bytes more wotn kill your RAM.

Be happy about correct status effect timers

[Panallox]

I'm all for this, I've been trying to get L0ne to commit the same thing for a while now, however I'd like to note that any statuses which are being displayed in the client and running into negative values are not meant to display the timer tick. In the LUA file, it is possible to disable the time display timer and according to some testing done it shouldn't be visible. So if we implement the 'status timer' fix, it will be unofficial since the statuses shouldn't even be showing the timer

[Ind]

you're right. as for the renovation case, it would only go negative in the client because the server would misinterpret it.

[Maki]

/me bumps

[xazax]

Is it still an issue? There is something in the source called tick_time, that supposed to store the tick interwalls, and tick remains the whole duration this way. If this issue still persist, the code that was added is an improper solution ( or I interpret it wrongly ).