Fight with runaway limit

[Buggie]

I found some observation which can be useful for other. All Observation done via diassembled token view for function via UE Explorer.

Predefinition:
Runaway counter increased only in two VM tokens: Jump and JumpIfNot.

All stated matter only for bottle necks which make main part of runaway limit. No sense apply this to any code.

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (A) {
			B = true;
			continue;
		}
		C = true;
	}

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (A) {
			B = true;
		} else {
			C = true;
		}
	}

1. Both notation produce exactly same byte-code.

2. Travel via block after if eat 4 points per iteration: for condition, if, continue/end block, jump at loop end.
Travel via block after else eat 3 points per iteration: for condition, if, jump loop.
So better, place things which come often in else block.

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (A) {
			B = true;
		}
	}

Code: Select all

	for (i = 0; i < RUNAWAY_LIMIT; i++) {
		if (!A)
			continue;
		B = true;
	}

this code produce different VM code and first always eat 3 point per iteration.
But second eat 4 point per iteration if "continue" called.

[Feralidragon]

It would be cool if one of the patches included an option to enable a log of this count at the end of every tick, in order to debug and know how far away you're from it, both in normal and extreme conditions, even to check first hand the effect of these things you're talking about.

Having that said, however, if you're near this limit at all, it generally means the code is doing too much and the game will be extremely slow either way.
I already discussed with Anth the possibility of increasing this limit, because of a few very legit possible cases, but he thought it's good as it is, so he might have already a good idea of what the average count might actually be in normal conditions.

But one thing that may be changed in the future is how these are counted towards the limit, because this kind of limit is meant for loops (for, while, etc) and not for if and continue , which seem mostly like an unintended consequence of how this limit is counted, so these might be treated differently in some way so that they don't increase this count, effectively raising the limit in the end.

[sektor2111]

Right now it's entertaining to me that what this post is not recommending - but I wanted that, was turned into the same direction which I stated
viewtopic.php?f=5&t=14672&p=130095#p130095
I don't get the point for not making Editor to help you in any way...
"-norunaway" switch and "abovenormal" priority for Editor are now my default settings - and I'M FINE this way.
When this switch "-norunaway" was created - someone had REASONS for implementing it - and it's HELPFUL in Editor. No crash and no pain, just go to prepare a coffee until task it's ready, I'm not rushing anywhere... At C++ Level Editor does X billions of iterations and I don't see what's the stupid deal in UScript when is executed in Editor. Why having limits in Editor ? Why not doing some cute UScript assets because iterations are throwing rocks at you ?

[Buggie]

In game 10 000 000 is huge number. And you can run client with "-norunaway" switch too.

This is mostly need for crappy solutions on UnrealEd side. But anyway 10 000 000 is slow enough for turn it off on default basis. Who need - able run with switch.

Also I make mistake. Each loop eat at least 2 point. One for condition, second for jump back. I go correct first now.

Another useful info: counter reset only on start each tick.

---

Automatically merged

About handle limiter inside code - I prefer Exec command for that. It will solve all problems and backward "compatible".

---

Automatically merged

https://github.com/OldUnreal/UnrealTour ... ues/774[hr][/hr]

Automatically merged

3. join two "if" together, reduce usage points, because partial equation of condition done via Skip token.

[sektor2111]

Let's consider that my XC_PathsWorker builder tool is pretty much simple and allowing user to work as he wants just because additional tests during building ReachSpecs process might go into crazy iterations and results can be... trash depending on map's geometry.
The harder problem for me was not generating ReachSpecs but it was the solution for optimizing the process for creating them more simple as possible and without adding extra paths from A to C when route should be A B C, unless point B needs to be connected elsewhere. Examining some spots using Script and not eyes was my big problem which I couldn't solve. The rest was piece of cake.
But... because I don't have skills for writing a scripted "eye" for Editor, I leave things as they are because builder is useful for me in this state.

[Buggie]

Code: Select all

	i = -1;
	while (++i < RUNAWAY_LIMIT) {
		C = true;
	}

Code: Select all

	i = 0;
	do {
		C = true;
	} until(++i >= RUNAWAY_LIMIT);

4. first loop eat 2 points per iteration: JumpIfNot + Jump.
Second loop eat only 1 (!) point per iteration. Just one JumpIfNot.
yes, it is not exactly same as second. You need "if" at start. but it is 1-2 additional point once, not +1 point for each iteration.

So now all critical loops must be rewrite to do..until. When do this - pay attention: when "until" condition is true, loop terminated. Opposite for "while".

[Barbie]

So now all critical loops must be rewrite to do..until.

I'd never change a head-controlled loop to a bottom-controlled and lose clearness of code because of language issues. It's the job of the compiler to create efficient machine or byte code of it.

*real programmers use safer hex*

[Buggie]

Yea, yea, yea. You can start from stop use SoftDrv. Because it is re-written on assembler, after figure C++ version is too slow for any real usage.
We live in real world, not in imaginary. So sometimes need do weird stuff if you need things be done.

Anyway, back to direct topic, if your code not suffer from runaway limits (I am sure not), this suggestion not useful for you. Write weird code not in critical for performance parts is definitely bad habit.

[sektor2111]

I'll experiment more of these "do - until" for figuring efficiency. At this moment I'm using it in XC_PathsWorker but... I don't know how much does it help.
Every single Navigation Point is taken and studied what is having in said defined connect range - using RadiusActors then sorting nodes based on distance. More nodes, more iterations - at a moment I think nothing helps here except adding "-norunaway" and all returns to normal. More "smart" probing inside Linked List toward connections means more iterations... Majority of UE1 specific maps doesn't need "-norunaway" only those which are not for UE1...

Perhaps I did an expensive method and code structures/methods could be more optimized - different written. By chance, I did not see more candidates interested to point me a better way and then... it's what I could do after asking X times for a solution concerning ReachSpecs handling in UT - because 227 has more than UT here, still incomplete because you don't know exactly what Pawn is supported when you look at those Lines Drawn, and 227 is mangling UT maps at random...

[Buggie]

Remake loops not able solve runaway limit problem, just make appear it little after. for example if you use 8 if's inside loop then remake loop only give you 10% more. So it is not big win. If you push limit in x4 times, then OFC this remake not help at all.

Also if you use goto - it too jump, which make +1 point for each goto.