0003025: Breaking infinite loop ( the loop is not infinite )

(0016897)
Filystea (reporter)
2017-02-26 12:15

The info about breaking the loop is passed on end of loop when the job is done.

(0016898)
Dusk (developer)
2017-02-26 12:33

Please post the code demonstrating the issue. You said "I will provide the code if this is considered bug." but we can't tell whether or not it's a bug without it.

(0016899)
Fused (reporter)
2017-02-26 12:33

There's no way we can conclude whether or not this is a bug when there's no example

(0016900)
Ivan (reporter)
2017-02-26 13:17

'https://www.dropbox.com/s/a0x8daywn1u3ec2/loopex.pk3?dl=0 [^]' -- Example.

Summon "HEGrenadeX". Repeat a few times and you should see the loop errors. It happens to me with A_JumpIF and user variables. (Anything that involves those really, must be a prediction problem)

Also, this showcases the bounce mispredictions still taking effect (aim at doom 2 map01 stairs, and watch it bounce to some direction but go straight etc.)

(0016902)
Filystea (reporter)
2017-02-26 15:09
edited on: 2017-02-26 15:10

I uploaded example.

In my mod i have this repeating often but here this seem to behave like this.

MUST BE MULTIPLAYER GAME.

Set cheats on server;
Enter game.
Now summon loopex
You will have information *breaking infinite loop*. And this won't repeat. To repeate it you must leave server and join and summon loopex again. Tho in my mod monster using something similar made it trigger many times while same map playing.
WHAT IS MORE.
If you try to summon on spectating the loopex actor it it will inform you there is division by zero.

All this seem to work fine on single player.

(0016937)
Torr Samaho (administrator)
2017-03-05 17:54

For the record, the behavior is the same in 2.1.2 and 3.0.

(0016938)
Torr Samaho (administrator)
2017-03-05 17:58

I had a look at the code of loop.pk3 and with our current jump handling, there indeed is an infinite loop with zero duration on the client. The client in general doesn't have enough information to handle the jump in A_Jumpif and thus always ignores the jump for non-clientside actors. Thus, Spawn2 is an infinite loop for the client.

(0016976)
Filystea (reporter)
2017-03-12 18:52

Status changed to feedback without any information. Not sure. I can do some testing since i reported this certain issue but no info was given.

(0016977)
Torr Samaho (administrator)
2017-03-12 19:20

0003025:0016938 is what I'd like to have feedback on.

(0016981)
Filystea (reporter)
2017-03-12 20:06
edited on: 2017-03-12 20:07

" with our current jump handling, there indeed is an infinite loop with zero duration on the client."

That is more of a statement.
Did the new version came out?

Unless this was not directed to me.

(0016985)
Torr Samaho (administrator)
2017-03-12 20:31

Yeah, you are right, it's more of a statement. So, with our current jump handling this is an infinite loop on the client, thus, the error message is correct. Did the explanation in 0003025:0016938 convince you of that? Or do you have any questions regrading this?

Quote from Filystea
Did the new version came out?

Which new version are you referring to?

(0016986)
Filystea (reporter)
2017-03-12 20:33
edited on: 2017-03-12 20:36

Ok I see so this is not a bug. Allright i did not understand you ( missunderstand you ).

All clear tho I would advice to fix the var handling in future or give information that that variables can't handle loops.

(0016988)
Torr Samaho (administrator)
2017-03-12 20:47

Ok. A revamp of the jump system that should also fix this problem is planned, but won't be in 3.0.

So for now, I'm closing this issue.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	Argentum

Notes
(0016897) Filystea (reporter) 2017-02-26 12:15	The info about breaking the loop is passed on end of loop when the job is done.

(0016898) Dusk (developer) 2017-02-26 12:33	Please post the code demonstrating the issue. You said "I will provide the code if this is considered bug." but we can't tell whether or not it's a bug without it.

(0016899) Fused (reporter) 2017-02-26 12:33	There's no way we can conclude whether or not this is a bug when there's no example

(0016900) Ivan (reporter) 2017-02-26 13:17	'https://www.dropbox.com/s/a0x8daywn1u3ec2/loopex.pk3?dl=0 [^]' -- Example. Summon "HEGrenadeX". Repeat a few times and you should see the loop errors. It happens to me with A_JumpIF and user variables. (Anything that involves those really, must be a prediction problem) Also, this showcases the bounce mispredictions still taking effect (aim at doom 2 map01 stairs, and watch it bounce to some direction but go straight etc.)

(0016902) Filystea (reporter) 2017-02-26 15:09 edited on: 2017-02-26 15:10	I uploaded example. In my mod i have this repeating often but here this seem to behave like this. MUST BE MULTIPLAYER GAME. Set cheats on server; Enter game. Now summon loopex You will have information breaking infinite loop. And this won't repeat. To repeate it you must leave server and join and summon loopex again. Tho in my mod monster using something similar made it trigger many times while same map playing. WHAT IS MORE. If you try to summon on spectating the loopex actor it it will inform you there is division by zero. All this seem to work fine on single player.

(0016937) Torr Samaho (administrator) 2017-03-05 17:54	For the record, the behavior is the same in 2.1.2 and 3.0.

(0016938) Torr Samaho (administrator) 2017-03-05 17:58	I had a look at the code of loop.pk3 and with our current jump handling, there indeed is an infinite loop with zero duration on the client. The client in general doesn't have enough information to handle the jump in A_Jumpif and thus always ignores the jump for non-clientside actors. Thus, Spawn2 is an infinite loop for the client.

(0016976) Filystea (reporter) 2017-03-12 18:52	Status changed to feedback without any information. Not sure. I can do some testing since i reported this certain issue but no info was given.

(0016977) Torr Samaho (administrator) 2017-03-12 19:20	0003025:0016938 is what I'd like to have feedback on.

(0016981) Filystea (reporter) 2017-03-12 20:06 edited on: 2017-03-12 20:07	" with our current jump handling, there indeed is an infinite loop with zero duration on the client." That is more of a statement. Did the new version came out? Unless this was not directed to me.

(0016985) Torr Samaho (administrator) 2017-03-12 20:31	Yeah, you are right, it's more of a statement. So, with our current jump handling this is an infinite loop on the client, thus, the error message is correct. Did the explanation in 0003025:0016938 convince you of that? Or do you have any questions regrading this? Quote from Filystea Did the new version came out? Which new version are you referring to?

(0016986) Filystea (reporter) 2017-03-12 20:33 edited on: 2017-03-12 20:36	Ok I see so this is not a bug. Allright i did not understand you ( missunderstand you ). All clear tho I would advice to fix the var handling in future or give information that that variables can't handle loops.

(0016988) Torr Samaho (administrator) 2017-03-12 20:47	Ok. A revamp of the jump system that should also fix this problem is planned, but won't be in 3.0. So for now, I'm closing this issue.

Issue History
Date Modified	Username	Field	Change
2017-02-26 12:14	Filystea	New Issue
2017-02-26 12:15	Filystea	Note Added: 0016897
2017-02-26 12:33	Dusk	Note Added: 0016898
2017-02-26 12:33	Dusk	Status	new => feedback
2017-02-26 12:33	Fused	Note Added: 0016899
2017-02-26 13:17	Ivan	Note Added: 0016900
2017-02-26 15:05	Filystea	File Added: loop.pk3
2017-02-26 15:09	Filystea	Note Added: 0016902
2017-02-26 15:09	Filystea	Status	feedback => new
2017-02-26 15:10	Filystea	Note Edited: 0016902	View Revisions
2017-03-05 17:54	Torr Samaho	Note Added: 0016937
2017-03-05 17:54	Torr Samaho	Product Version	=> 2.1
2017-03-05 17:58	Torr Samaho	Note Added: 0016938
2017-03-05 17:59	Torr Samaho	File Added: loopex.pk3
2017-03-12 12:29	Torr Samaho	Status	new => feedback
2017-03-12 18:52	Filystea	Note Added: 0016976
2017-03-12 18:52	Filystea	Status	feedback => new
2017-03-12 19:20	Torr Samaho	Note Added: 0016977
2017-03-12 19:20	Torr Samaho	Status	new => feedback
2017-03-12 20:06	Filystea	Note Added: 0016981
2017-03-12 20:06	Filystea	Status	feedback => new
2017-03-12 20:07	Filystea	Note Edited: 0016981	View Revisions
2017-03-12 20:31	Torr Samaho	Note Added: 0016985
2017-03-12 20:33	Filystea	Note Added: 0016986
2017-03-12 20:36	Filystea	Note Edited: 0016986	View Revisions
2017-03-12 20:47	Torr Samaho	Note Added: 0016988
2017-03-12 20:48	Torr Samaho	Status	new => closed
2017-03-12 20:48	Torr Samaho	Resolution	open => no change required

Relationships