House of Fools

Small intro:
At a moment a mapper making a MonsterHunt map which is supposed to have Bot support, will want to check it if paths to MH objectives are done properly.
Blocker:
If you don't know what is about with terms MH objectives read tutorials and you can stop reading this topic because this proves that you don't have a clue what to do in MH mapping for Bots.

Description:
Such Mutator works based on tester will. Which means that we do need to input mutate commands for testing / stop testing.
When mutate command (document included) is fired up mod will cause a message about positive results and how results are acquired - later about this.
If paths are not found because map is bad or we are too far from Paths mod will stay active in background showing routes later when network is closer.
Due to engine capabilities, a pawn hunting another pawn has another path finding power boosted natively by engine. A superior version like XC_MonsterHunt will use this feature and has better results toward Bot Support. Original MH in plain UT won't use this feature. For these reasons mutator shows which method was returning results. When Paths are good but available only VIA hunting, we have to adjust locations for MH Objectives else plain MH and Bot won't go nowhere but this is proving that paths are good in big parts.
When paths are good and objectives placed properly, Mod will show route-cache points (red circles) heading hunter to MH goal. So to speak we know if map has Bot Support without even to use Bots for testing - but we have to check them later in a last TEST.
Here is the mutator-tool: Next Good-To-Know things:
Last XC_Engine (v24) is capable to offer an advanced power to Pawn Paths Seeker. In big maps where mutator was showing no navigation and Bots were wandering, right now they might be operational, Bots are moving ahead. This Mutator can simply confirm what I'm talking about.

Here comes some evidences. Map tested is a version with paths of map MH-GardenOfDeath - not using triggers (because I did that in the past before XC age) but PathNodes mapped as a default Navigation Network.
Due to map size, original DevPath does nothing - engine going over boundaries: But... if we are using original MonsterHunt in UT having XC_Engine v24 loaded, results are different, paths being shown shortly: Of course, map has paths optimized but this is not enough for plain UT which has old and obsolete codes, and such a Map might be even annoying for players at how much has to roam hunter. The rest of game idea and critiques are not part of this presentation/topic.

Rant (Rat) On:
From now on MH mapper saying that he could not check or do good paths in map, has no excuses, is simply lying. In 2019 WE DO HAVE testing tools and information required for debugging. If mapper has no clue about pathing generally, I can expect to not even know what is for this mutator and what it does...
Rant (Rat) Off.
How comes with newer Editor Adds by Higor it's another story to discuss...

This is really interesting Nels. How fast can it compute the path in real time?

Is possible to use it in other game modes too, and it shows problems with the path?

D13GO_{HoF} wrote: ↑Sun Sep 15, 2019 6:02 pm Is possible to use it in other game modes too, and it shows problems with the path?

For a DeathMatch I'm planing a modification to the other toy which I did previously: BotyMan3 - this one in XC_Engine shows even paths through JumpSpots which usually are not available in plain UT - SHAME to you Epic... but I think I can do an ugly stunt for that plain UT... Bot probably won't be happy...
The rest of hints for Testing Levels are handy for All Mappers - checking various spots is doable with old original commands RememberSpot ShowPath - see Video from pathing tutorials which I did not see in other tutorials generally... - Epic did some interesting stuff I have to admit...

Kelly wrote: ↑Sun Sep 15, 2019 3:32 pm This is really interesting Nels. How fast can it compute the path in real time?

Little secret and not secret - I have this mod loaded in my Home server (Engine is tweaked there for that Warp crash) and there are no issues. Pawn looking for path will gain result in my slow machines in around 0.000185 seconds or such, even faster depending on map - less than an eye blink - only mutator is getting late due to state code written like that on purpose, I'm not rushing nowhere. Mod works in a sort of background state looping slowly for preventing a nasty load. I always check a fresh loaded map in server with such tool (previous was V4 not so powerful).
Mutator it's inspired from original testing devs done by Epic and properly fu....ed by UTPG - yes, read well, that was their fix for preventing a so called lag.
When game does lags ? When a Pawn is brute forcing paths searching faster even than a tick interval - see those toys which you have sent me time ago - those are evil things not really DevPath , and even loading CPU processing... - I know what I'm saying because I tested around 300 angry monsters against Tamerlane (poor guy)... For a default game with Bots and two people searching Paths-Net there is nothing noticeable toward a performance loss. Searching Paths uses C++ natives helped by the rest of OS things... More than that - paths are shown only at owner not at all Players. So even replication is not highly loaded - server environment. For another clarification you can pick a MonsterHunt game in a map like Arden+fix1 or Kroogaar or whatever Liandri or Templar or even some Forbidden, Canyon by Shrimp himself (you'll see even bugs toward Bots too), input mutate mebot command with this mutator loaded in list - see what's the deal - advisable not using Bots in initial stage because they trigger monsters and you have to be relaxed. In a future version I might do a configurable option for clocking using XC_Core - but for me that's not a very high priority, the goal is to check map if it works properly.

Chapter CTF
All what I have so far is my custom CTF which in raw format shows beacon to Enemy flag Home flag without AlternatePaths - a basic check for CTF maps - using mutate commands and a key bound to ShowPath because player used there is a custom class ignoring UTPG's stupid "solutions".

Darkish note: Somebody was "smart" enough to post some downloads at UT99.org where I could find some old Source-Code for UT, we can throw some assets around and then we can discuss what's happening inside Engine. However, C++ works X times faster than UScript, limitations are those hard-coded things which Epic were deciding in 199x years for PII, PIII machines...

It might be time to just start a community of players all using the same dll with straightforward solutions to these stupid uscript issues.

Plain UT player can use this toy in my server without installing anything strange.

Now let's keep going with debugging. This tool it's not 100% needed when is about making paths with XC_EditorAdds. New stuff shows already paths right in Editor and mapper won't need to waste time with X+Y test sessions. See images which I described in tutorial with those 2 lines needed...
And then when I'm using it ?
- 1 In big maps - must have a clue if map is supporting these devs for not wasting time doing useless bytes;
- 2 In maps without paths which will have paths in run-time - GiantBoss2, Detour, Tomoko..., URealv3, etc;
- 3 Learning when a MonsterWaypoint is UnReachable in original MH by repeatedly adjusting height location and testing - it's why I know several tricks which more MH mappers don't even dream about them.

At point 2 map must be checked because all paths are thrown in game blindly based on my prediction - I don't have a clue what "lines" are added and then testing for functionality it's a must because game environment it's not the same as Editor Environment - Doors here... In Editor Scout will walk through doors but not in run-time after first tick when all Mover will collide blocking paths creating task. For doors I do have Forced paths at low range connected without testing movement, and then if two nodes are connected by accident through walls this has to be fixed. The other solution is to move doors until Scout is roaming navigable areas but this is not really great in those maps with brushes stripped for some reason... The third solution is using variables for said future connected nodes and processing them directly with desired reachSpecs. Sample We have a node assigned as N1 and other as N2. They get connected with XC_Engine Taken from patch plugin doing paths in map MH-Deep(v2).
Why setting up these reachSpecs "manually" ? Because sometime Engine claims no navigable area when actually Bot can manage to move between two nodes even if they are connected through a ledge or such - Higor connected such nodes in run-time in certain stock maps and... Bot can use them without a single problem.
I have to admit that these devs are still "young" but are superior in a way to defaults.

Common mapper for a basic check might use those original two commands for testing various map sequences/rooms. Such a check will never hurt anything.

Bumping with another Tester tool done by Buggie at UT99.org.
DrawPaths
mutator is capable to draw nearby Paths/ReachSpecs in game. So far we can see some of these in Editor, but now we do have more than that during run-time. I wrote here another document with a few explanations. This is original TXT file: PDF document contains a bit more info and a picture: Whatever discussions toward debugging a map can be pointed below...

DrawPaths in dynamic Navigation.