UED Add ons

[sektor2111]

Location has been updated with MapGarbage and XC_PathsWorker versions for October.
MapGarbage has two archives... because I forgot about AlternatePaths when textures are toggled for 4 teams - if there is a need for this check. AlternatePaths concerning 4 teams need a logical placement or else Bot will do more useless roaming.
Adds:
- optional fix attempt for Unreach Nodes - Nodes that are not badly messed up can be solved in seconds;
- another option bBotifyMyNodes - turns PathNodes in a more compatible with Bot format - monster is not affected in a normal navigation environment with logic paths.

XC_PathsWorker
- new option bNullDupedSpecs - will ruin duplicated paths concerning the same two nodes - these can be later "deleted" using function which is available since September 2022.

---

Automatically merged

There are questions to ask concerning those not wanting to see monsters crawling in their maps but making sure that Bots are not affected.
This option can be done in two ways which I'm about to think when it comes to stock Paths/PathNodes - XC assets are in charge here.
Question #1: Solved by doing all Paths R_PlayerOnly ?
Question #2: Solved by doing all Paths 40 × 20 ? - narrow more exactly, still small creatures can hunt enemies.

More solutions ? Opinions ?

[OjitroC]

- another option bBotifyMyNodes - turns PathNodes in a more compatible with Bot format - monster is not affected in a normal navigation environment with logic paths.

Just to clarify - applying this option will not have an adverse impact on how ScriptedPawns will 'navigate' a map? If one is pathing a map mainly for ScriptedPawns then there is no advantage in using this option?

There are questions to ask concerning those not wanting to see monsters crawling in their maps but making sure that Bots are not affected.

Not sure in what circumstances there would be ScriptedPawns in a map if people don't want them in the map? Or you mean when there are ScriptedPawns in a map but one does not want them 'roaming/wandering'?

If all Paths in a map were R_PlayerOnly, then there would need to be a check for this in MapGarbage because there would be no means of knowing that the Paths were PlayerOnly without looking at the bPlayerOnly setting for each PathNode? So I could run all the normal checks on the pathing of a map using MapGarbage - get everything looking good and then play the map with MonsterSpawn and find that no ScriptedPawns spawned because the PathNodes were all PlayerOnly.

[sektor2111]

Just to clarify - applying this option will not have an adverse impact on how ScriptedPawns will 'navigate' a map?

I can setup some demo if you don't believe me - even you can check what does this option. I don't remember a Monster not finding player in well pathed maps because player was beyond a PlayerStart - if you want my personal opinion, the story of PathNode being 50 × 46 doesn't make any sense to me - "Skaarj stuff". Monster can reach in location even if node is lower but I could see even troopers failing in ramps due to this "scientific" decision, even a trooper failed to get on a such "PathNode". Map-names ? No, it will be taken as defaming.

Not sure in what circumstances there would be ScriptedPawns in a map if people don't want them in the map?

Some boys "mappers" were telling a story in a forum concerning MH mapping. We don't want PathNodes because monsters can use them for hunting us - chickens if you want my opinion. But if you don't have paths you can say bye to the Kira and to StrengthRelic. Solution(s) ?
Using smart Nodes doing a denial or... messing ReachSpecs for eliminating monsters from hunting task, a quantity of monsters or... all Monsters.

no ScriptedPawns spawned because the PathNodes were all PlayerOnly

That's good to know, but I have another recall. Even if I used bPlayerOnly nodes, ReachSpecs were not R_PlayerOnly because of something from EPIC...
Bool variable bPlayerOnly and ReachSpec R_PlayerOnly are two different things but in the logic of EPIC these are not melted together exactly like in Skaarj case, it goes a bIsPlayer but without any PlayerReplicationInfo - results can be seen in logs... If you want more data, let's says that I have never seen any ReachSpec R_PlayerOnly outside of my edits - All these are working, reachFlag is calculated properly - only Goblin is the main UE loser unable to follow its own rules.
Of course this is only an option - inactive like all of them - map can be tested before any release if it was touched. Others are not even knowing that they can operate paths and are wasting time X hours painting in Editor - it's not my loss, I shared my stuff.
As far as I know, at this time only XC_PathsWorker is mapping paths in a more logic format. ReachSpecs R_PlayerOnly are available for all outgoing and incoming paths to said "Player" node. The rest is user's control.

Point C: Right now all "Jeronimo" jumps added by XC_EditorAdds v24 can be removed under a blink... Nulled paths can be deleted later - all goes simple and logically connected, no misery.

[OjitroC]

Bool variable bPlayerOnly and ReachSpec R_PlayerOnly are two different things but in the logic of EPIC these are not melted together exactly like in Skaarj case, it goes a bIsPlayer but without any PlayerReplicationInfo - results can be seen in logs... If you want more data, let's says that I have never seen any ReachSpec R_PlayerOnly outside of my edits - All these are working, reachFlag is calculated properly - only Goblin is the main UE loser unable to follow its own rules.

OK now I'm getting closer to understanding this. So it's unlikely that there are maps around now with ReachSpec R_PlayerOnly - presumably the only way to check for this at present is to select all PathNodes and use MapGarbage's bShowSpecs, and then read through the list looking for RFlags=PlayerOnly =64?

[sektor2111]

Bingo !
You get the point. Let me explain a bit next point ->
I did not see any map done using Editor and only Editor aka Goblin creating R_Door flags, R_PlayerOnly, old versions did not even logged a small attempt to R_Fly. These flags are having a logic - amazingly no bugs - which are recognized in run-time without any error. You can discard slow minded creatures from crawling outside of their "yard", you can completely deny them from hunting or... you can setup a hunting session which will make players a la 2022 to quit playing and making happy all UT elders curious about a new challenge. I'm one of those accepting challenges because... Re-Spawning stuff doesn't do any problem for me.
I can lose a match or more in the same map, but if I'm using my brain 3 minutes perhaps I can find an exploit in order to gain an advantage against brainless creatures which are only in bigger numbers but no Intelligence at all - in next stage things are going too easy...
We don't forget that creatures with Intelligence "BRAINS_Human" are accepted by R_Special almighty flag for Lifts. And then ? And then a Mover having BT_PlayerBump doesn't even blink at their presence ignoring their desired route when actually paths are granting access to these Pawns.

[sektor2111]

PathsChecker has been re-uploaded because something was borked, it escaped me. XC_PathsWorker need some external package which is there too - I also updated archive.

[sektor2111]

First Post containing November versions of MapGarbage and XC_PathsWorker has been updated.
All related tasks operated (or more inconclusive reports based on recent UT things) are described in their PDF docs.
Light me if something as a package needed by builders is missing. These Builders (different said Editor Plugins) are still not dependent on BotPack, but package can be linked in Editor by XC_Engine assets due to patching tasks - speaking about 436 assets and Editor embedded in this version. For latest 469c I cannot say anything, but we have XC options for doing various tasks or bugged stuff produced there using prior versions of UT and XC v24.

Let me know if other touches are needed - such as keeping an option active after usage (some of them are going inactive for not being fired multiple times), others are sitting active as long as they might be needed multiple times per minute until user is deactivating them, etc.
Certain XC specific tasks for testing/fixing paths are using a bunch of iterations and here is needed something added in Editor's run-line - subject was posted already so I won't explain it over and over again.

[sektor2111]

An update of MapGarbage for January 2023 is now available - previous post has the link.
Added:
- option for a bit of Z correction at items - the mostly an optional design stuff;
- an option for tracking several stock Triggers that might be miss-configured and they can be pointless.

[sektor2111]

Builders MapGarbage and XC_PathsWorker were updated February 2023.
MapGarbage
Adding option for resetting actors (items, pawns so far).
XC_PathsWorker
Rewriting some checks - needed because some "maps" a la 2023 are having new fantasies which no stock/old map was ever having - awaiting other funky stuff...
Connector option for a full user made path will work exactly like auto-connector - it will use a null ReachSpec if it's found. It will create a new one only if nothing empty is found.

The rest of rules for pathing more or less manually are the same - if user knows what wants. A Generic Tutorial about this chapter is off-topic here...
We can talk about a document or a posting method with Q & A, or not, because people are not really reading forum.

[sektor2111]

There will be something added here for XC_PathsWorker - in testing stage... Bad flags in water... No, Editor did not do them, other things did them...
"Picture" from "Testing Lab".

DevAudio: Galaxy SetViewport: U2Viewport0
Log: Collecting garbage
Log: Purging garbage
Log: 0.0ms Unloading: Package Render
Log: Garbage: objects: 39380->39299; refs: 531888
Note: Creatures from Water Zones that are only swimming are simply denied from routing through these paths.
Note: Pawns won't walk or jump inside a Water Zone. It doesn't make any sense.
Note: This chapter belongs to .......
XC_EA2: Found wrong Water Path 219 PathNode37 InventorySpot236 13 = bad Flag. Adjusting to 4 = R_Swim.
XC_EA2: Found wrong Water Path 229 PathNode36 InventorySpot236 13 = bad Flag. Adjusting to 4 = R_Swim.
XC_EA2: Adjusted 2 Water Paths.

No, R_Special are not a subject to discuss here, they won't be touched.

A Small Test: Can you see this subject (469c) - Bot ?

Code: Select all

singular function Falling()
{
	if (bCanFly)
	{
		SetPhysics(PHYS_Flying);
		return;
	}
	//log(class$" Falling");
	// SetPhysics(PHYS_Falling); //note - done by default in physics
 	if (health > 0)
		SetFall();
}

No ? Too bad...
I see ZERO deal with Water Zones... PHYS_Falling in water ?

Code: Select all

.... // note - done by default in physics

I hope it won't happen this "joke" again... This thing gets called after killing or going to next attack.
I hope that in TickActors Physics are set correctly...

[sektor2111]

In Location first post has been updated for April 2023 as follows:
1) MapGarbage - not major changes but reconstructing Navigation Chain will reorder Nodes with objectives first - attempting to reduce routing cycles...

2) XC_PathsWorker has some news...
- bInWaterWeSwim - XC Paths that are using Walk and or Jump flags inside water are set back as Editor does R_SWIM and not other way (without movement logic);
- bRealDistance - useful for updating certain nodes moved post-pathing in order to match Real Distance - even some COMBO paths are touched when are having small distances - 1000 UU for a small route doesn't make any sense;
- bDisconnectSelection - Selected Node(/s) will have all Paths that are including them Nulled - if node is planed for deletion all references from Network pointing to trash Node must be removed for preventing references to nowhere - next option will clean all Network for such useless routing data stored in map;
- bCleanRoutingJunks - will remove (like MapGarbage) all related routing chains created during Paths Building process by Edy Goblin aka UT Maps Editor;
- bDisconnectTwo - Two Selected Nodes (even more) will have Paths that are connecting themselves each-other removed - this way getting rid of an Evil Path goes easy as a pie - All Left-Over nulled Specs can be cleaned later in final stage with prior option (bCleanNullSpecs).

Edit: Sample bonus for showing what can be done with fore mentioned two tools aka Editor Plugins aka Brush Builders.

DM-Deck16_rS804.7z

All Pathing related tasks were operated manually, Goblin had no business here.

(258.7 KiB) Downloaded 5 times

[darkbarrage99]

In Location first post has been updated for April 2023 as follows:
1) MapGarbage - not major changes but reconstructing Navigation Chain will reorder Nodes with objectives first - attempting to reduce routing cycles...

2) XC_PathsWorker has some news...
- bInWaterWeSwim - XC Paths that are using Walk and or Jump flags inside water are set back as Editor does R_SWIM and not other way (without movement logic);
- bRealDistance - useful for updating certain nodes moved post-pathing in order to match Real Distance - even some COMBO paths are touched when are having small distances - 1000 UU for a small route doesn't make any sense;
- bDisconnectSelection - Selected Node(/s) will have all Paths that are including them Nulled - if node is planed for deletion all references from Network pointing to trash Node must be removed for preventing references to nowhere - next option will clean all Network for such useless routing data stored in map;
- bCleanRoutingJunks - will remove (like MapGarbage) all related routing chains created during Paths Building process by Edy Goblin aka UT Maps Editor;
- bDisconnectTwo - Two Selected Nodes (even more) will have Paths that are connecting themselves each-other removed - this way getting rid of an Evil Path goes easy as a pie - All Left-Over nulled Specs can be cleaned later in final stage with prior option (bCleanNullSpecs).

Edit: Sample bonus for showing what can be done with fore mentioned two tools aka Editor Plugins aka Brush Builders.

DM-Deck16_rS804.7z

Hey sektor, I installed according to your instructions on the pdf. Should the missing "core" "engine" and "editoradds" packages have been included in the zip file or are they a mandatory as a separate download?

Edit: ah, I see. xc engine is it's own thing. would you mind providing a link to the most current version? this is a bit confusing for someone who is "out of the loop" due to there being different versions and compatibility with 469.

[sektor2111]

The thing is that Builder works properly in prior UT versions to 469 (except 451b - Editor is useless there anyway) using XC_Engine version 24.
For 469b, XC_Engine used is version 25b - here looks operational as well. Other combinations won't work.
Required XC packages must be placed in System or whatever Path with U files. If XC doesn't load then... it is miss-configured or it's a wrong version.

For 469c I have no clue about what, or if this thing works. Simply XC_Engine 25c doesn't work in my OS and I have no version available - perhaps I'm not interested about newer added bugs (I can see some newer mapping "products"... ). Already builder is aiming to solve XC/Stock issues added in paths-net and to help editing where NONE of such things are helping.

Resuming:
- UT469b + XC v24 = FAILURE
- UT436 + XC 25b = FAILURE
Each of this UT 469 is CHANGED/Different and then all mods using natives will fail to work in 469 if are not set correctly (mainly everything has to be recompiled or byte-hacked, if works...).

To the point:
I work with stock UT and XC v24. I see funky things in 469b + XC v25b.
The whole XC_Engine thread has already its own section with all related discussions. Look in forum - it's here.

[sektor2111]

I have adjusted a bit prior April version of MapGarbage. In a recent work I found printed two errors. Task was not affected but... I don't like errors, neither duplicated executions...

[sektor2111]

A small bump Note - for potential future updates.
I see that there are users who use XC_PathsWorker. I think it could take two future options:
- "bBotifyPaths" - the current navigation paths will be narrowed for Bots. It will be a complete destruction of the myths related to the red paths - as heavy. They are not heavy, they are just narrow - discarding Big Pawns.
- In the reverse "bMonsterifyPaths" - the wider ways will be extended for all species of creatures in stock.
XC_EditorAdds from XC_Engine V 24 optimizes the navigation well, but we can expand or narrow the roads according to what we want to have as a final result.
I admit it is a bit of work, but it might help (for those who want such options). I'll think about these... Aiming Plain Paths not Special Paths.