The reason(s):
- plain DevPath has internal issues more or less known by Textures makers and Walls builders;
- some of their settings are wrong as well causing lousy things.
For writing plugins original stock assets are a No Way. By Example if we want to reconstruct navigation chain for discarding buggers, variables used for linking navigation chain are "constants" which are not compiled by UCC/Umake. To be honest with you, for me these "constants" are not constants at all as it's widely demonstrated by Editor itself which is rebuilding paths X thousand of times and creating Navigation Chain at C++ level. Uscript can do the same thing if code would compile so we need to screw trash rules for compiling a code which is more than useful. The same story is for Movers and their constants - yeah, sure
.Step 1) Means examining map for quirks using MapGarbage and playing map a little bit.
Step 2) Would be saving map with a temporary suffix in which we can do our changes or we just don't do that much than figuring what we have and where.
Step 3) We might use a builder plugin for Editor in order to log some pieces of codes, these can be copied in future source-code for plugin.
If map is over-charged and messed up, we need to remove all reachSpecs referenced in nodes and all lousy junk data. We take all ReachSpecs and we make them null.
In next stage Nodes are destroyed (preferring in some "auto state" stage not in prebeginplay) letting things to be set first.
Next move is remaking all Navigation in Temporary map. Testing how does it work. If it's all nice we have to write plugin for creating paths.
Navigation Nodes added in run-time are never bStatic or bNoDelete. Their spawn code and settings for InventorySpots are scripted too.
Preparing copy map for capturing nodes and paths:
- adding InventorySpots (custom ones) over Inventories using MapGarbage;
- adding Nodes (some nodes named as the ones from run-time);
- checking/fixing their real Locations - MapGarbage;
- Linking Nodes into Navigation Chain;
- building paths with keeping old navigation - even if this is not there and it was destroyed - we keep navigation chain even if it's empty;
- doing checks and moving paths or adding paths where are needed;
- Generating Script for spawning current nodes (based on locations, not other data);
- Generating Script for Creating reachSpecs - copy of those from temporary map. Ideal solution would be using current nullified reachSpecs as much as possible.
- Compiling and Probing Plugin in original map.
Auto-Scripting method makes possible writing code for hundreds of paths automatically - compilable code is generated under an eye blink. All Paths are generated by XC_Engine - stock UT cannot do that in UScript. Methods and solutions for generating paths are sampled and can be modified from XC_Engine assets as base. A new XC actor can be delegated to do things different without probing paths. When we do have paths already tested in copy map, these can be added in run-time without testing them again, just dropping data inside Level. This works extremely fast and New "run-time" nodes are usable as long as XC_Engine is taking control over navigation process.
Required Plugin name is delivered by NavAdder - it will say what is looking for. We have to create required folder and perhaps using an older plugin for template in order to not recreate the same classes all over again. We are deleting old Paths codes and polish codes where is needed.