Builders helpers for UT Editor

[Cool Cat]

And it happens because A.I. knows everything but... doesn't know itself, so it makes promises that don't materialize even after 3 hours, after which it says it lost the data and needs that again, and we keep running in circle like a dog that wants to catch its own little tail.

Well at least your A.I. did not become nazi, which is already good.
More examples: Grok says it’s ‘skeptical’ about Holocaust death toll, then blames ‘programming error’

Elmo Musk is Ketamin Nazi.

[Nelsona]

During the discussions about “BUILDER”- the purposefully made “BUILDER”- it continued at every reply to provide lines of nonsensical code. The question is whether it's worth paying 24 euros to be able to write more crap having extended communication capabilities. It's the night of the mind.
It makes promises that it won't add any more assumptions, and then 30 seconds don't pass and he's back to useless inventions.
This is no way - I described where to get resources to logically determine what to do plus the old archives stored at ut-files. It's like talking to a wall.
Other topics are indeed unbeatably processed, but in our case, it beats any paranoid.

[Nelsona]

An update has been done in first post.
There was added (a bit late) XC_PathsWorker for month July 2025.
It has now some changes in executions due to some tiny random failures more or less coming from XC assets.
It was embedded with report concerning cycles used in executions coming from XC_Core. Clearly in highly loaded Levels you want the switch "-norunaway". Restricting executions in Editor doesn't make any sense.
Update notes:
- bNoBigRoam - Option will reduce large paths at narrow paths having even user-defined options - the document contains explanations;
- bDistanceSpoof - Option will reduce ReachSpec distance declaration at a half - only longer ones - perhaps it is helping your own experiments;
- bRoundToRealDist - If original placement of nodes has been adjusted a bit, here distance is recalculated to the nearest integer. Rules for R_Special Paths are taken in account as in original Stock 500 UU × 2 and 100 UU.
- bReplaceNode - It needs defined a class of node that will replace a selected node currently used in map. Yes, it does a complete replacement, linking into chain, disconnecting Old Node, removing debris data referenced and adjusting reachspecs coming To and From Old Node at New Node. Useful for replacing a PathNode with an AlternatePath in some spot without overloading map and/or reconstructing paths-net. This was possible so far but in a few steps. Current option will prevent some time wasted with this subject.

Have fun !

[Nelsona]

Bumping topic. At this time some optimisations are taking place and tiny improvements.
XC_PathsWorker has some polishing and we have several results:
Old Code report

ReIndexProcess: Cleaning Navigation Network...
ReIndexProcess: Harvesting Valid ReachSpecs and Adding them into Network...
ReIndexProcess: Moving Debris ReachSpecs at End of Array...
ReIndexProcess: Null ReachSpecs found...
NullAsLasts: 2708 ReachSpecs were moved to last positions in array.
SpecsIndex: ReIndexed and Attached 1286 ReachSpecs into Navigation Chain.
PathsWorker: Time Taken: 0.138096 seconds.
PathsWorker: Cycles Usage: 565404.

And changes delivered different results

ReIndexProcess: Cleaning Navigation Network...
ReIndexProcess: Harvesting Valid ReachSpecs and Adding them into Network...
ReIndexProcess: Moving Debris ReachSpecs at End of Array...
ReIndexProcess: Null ReachSpecs found...
NullAsLasts: 2708 ReachSpecs were moved to last positions in array.
SpecsIndex: ReIndexed and Attached 1286 ReachSpecs into Navigation Chain.
PathsWorker: Time Taken: 0.065846 seconds.
PathsWorker: Cycles Usage: 271970.

This is when combined codes C++ and "for" cycle were replaced exclusively with "do-until"...