DrawPaths - mutator which draw network paths in game

[papercoffee]

Example for coverage feature:
scr_1620344449.png
Area not lit with red placed too far from any NavigationPoint, so from where Bot/Monsters can not reach Navigation Network in most cases.

Oh that's an interesting feature now.
visualising the reachable area ...I like this idea.

[Buggie]

Add show coverage:

mutate coverage X
where X = 0 - 1
Show/hide coverage by red light

Labels for paths now draw with color from path (based on flags).
And Label near path show only distance from reachspec if real distance different not more than 3 uu.
If more then draw real distance in brackets.

[sektor2111]

Yes, "ActorReachable" is an important factor for being understood by mapper, especially when Game-Type (such as MonsterHunt) needs to find an actor Target which is not a NavigationPoint connected. There is a problem if you are based on Engine and Nothing else.
Technically you will want to know exactly Reachable range. I used original paths finding testing commands, never knowing exactly where it comes impossible to be found and where it can be found. Of course, given the 800 range, target must be located well on the ground and not in air - higher. This Z location is mandatory for a plain search of a MonsterWayPoint - the thing is... such a WayPoint can be found when Bot is set with bHunting. The nearest node with good paths will be the meeting point. When Bot is there it's needed some brute-force because Waypoint it's not reachable directly even if it was hunted. This bHunting is addressing combat, enemy can run away, and in big parts cannot be found directly but it works with any actor even for NON-Pawns. Too bad that game designers did not know these - Documents explaining these are nowhere, pretty nasty from Epic at this point. Community should have access at these assets for doing things better. To not forget that if goal is behind a mover it's like vanished even in 800 range - only bHunting is helping here.
If these would be known earlier, perhaps community would clone this bHunting stuff into a more expanded solution, the closest node, ignoring 800 and going up to 2000-3000. In one of my MH2 version I'm not counting on Engine. Target is the closest NavigationPoint but not very closer, for reaching in a better spot even if goal is higher. This could be written better but in that time I did not know where to look, perhaps in future I'll touch codes here and there...

[Buggie]

Safety notes:
Stick at Max 1600 UU length. Pawn blocked in the middle won't resume navigation too soon. Pawn blocked closer to initial point resumes navigation from there and facing the blocker again = Loop. It's why the best practice could be at 1200 - 1400 if map it's... bigger. If map is really obstructed - small - I never recommend 1000 UU length for paths, here are generated just too many links which are not needed

This depends from another coverage.

On picture max distance fit to 1600, but exists big not covered area on left and right side of circles intersection. From where return to net can be a problem for usual bot/monster.

[sektor2111]

Yes, entirely agree here.
"NoLost" was delegated to "attach" pawns back into network when they were outside of such circles or blown away. I was a "nice boy" writing that for original Bot. My Bots don't need such things but they are not hurt by such tool.

I see this sort of "native" issue in MH-Arden+fix1. Map has paths but nothing nearby mountains - I tested such actors in a copy of that map - they helped. A similar recovery can be written in "SpecialAttraction" function from any TeamGamePlus controller. In next PickDestination cycle Bot will scan closer points and moving there even if it's far from any Node. I have to admit that I did not try to optimize code for a better speed...
Initial version I wrote 5-6 years ago or more, and was based on multiple guards placed around. Later I decided to wrap these into ONE single actor and not more actors.

[Buggie]

It is bad practice embed in map such hacks. They must be released as separated mutator. Because you can not know what bots operate here. Possible with same mutator and they can fight or make things worse.
--- EDIT ---
Also, even if big paths not a problem, bots very limited in search range.
search here for "PickLocalInventory"
https://github.com/Slipyx/UT99/blob/f2e ... t.uc#L2514

Code: Select all

Botpack/Classes/Bot.uc:3038:                                            PickLocalInventory(160, 1.8);
Botpack/Classes/Bot.uc:3043:                                            PickLocalInventory(200, 1);
Botpack/Classes/Bot.uc:3048:                                            PickLocalInventory(280, 0.55);
Botpack/Classes/Bot.uc:3051:                                    PickLocalInventory(400, 0.5);
Botpack/Classes/Bot.uc:3070:                                            if ( PickLocalInventory(600, 0) )
Botpack/Classes/Bot.uc:3105:                    if ( PickLocalInventory(300, 0.55) )
Botpack/Classes/Bot.uc:3128:            if ( !bTriedToPick && PickLocalInventory(600, 0) )
Botpack/Classes/Bot.uc:4610:                                    PickLocalInventory(160, 1.8);
Botpack/Classes/Bot.uc:4615:                                    PickLocalInventory(200, 1);
Botpack/Classes/Bot.uc:4620:                                    PickLocalInventory(200, 0.55);
Botpack/Classes/Bot.uc:4623:                            PickLocalInventory(400, 0.5);

As you see, Bot never search Inventory more then 600 via this function.
Of course exists another functions for Inventory, like FindBestInventoryPath.

But if order "Follow" given by human, Bot use only PickLocalInventory(600, 0), before go to human location.
And if no any Inventory in Radius of 600 of start point, then Bot goes help you with enforcer.

[sektor2111]

Too bad that you think DeathMatch works only this way...
As a matter of fact, have you ever seen these codes or did something for these ? Order 'Defend' or 'Follow' is not 'Freelance', they deliver a different action.

Code: Select all

state Roaming
{
...
	function PickDestination()
	{
	....
		// look for long distance inventory 
		BestPath = FindBestInventoryPath(BestWeight, !bNovice && (skill >= 2));
		//log("roam to"@BestPath);
		//log("---------------------------------");
		if ( BestPath != None )
		{
			MoveTarget = BestPath;
			return;
		}
	....
		if ( RoamTarget == None )
		{
			i = 0;
			for ( N=Level.NavigationPointList; N!=None; N=N.NextNavigationPoint )
				if ( N.IsA('InventorySpot') )
				{
					i++;
					if ( (RoamTarget == None) || (Rand(i) == 0) )
						RoamTarget = N;
				}
		}	

		// roam around
		if ( RoamTarget != None )
		{
			if ( ActorReachable(RoamTarget) )
			{
				MoveTarget = RoamTarget;
				RoamTarget = None;
				if ( VSize(MoveTarget.Location - Location) > 2 * CollisionRadius )
					return;
			}
			else
			{
				BestPath = FindPathToward(RoamTarget);
				if ( BestPath != None )
				{
					MoveTarget = BestPath;
					return;
				}
				else
					RoamTarget = None;
			}
		}
		....

After sampling a functional demo map before you still don't get these ? Why do you think Bot was moving for Shield ? I listen... I don't understand what is goal of discussion here... BOT ALWAYS... BUT ALWAYS can find a long range inventory if the thing is connected into Navigation Network and map inside engine limits. BotyMan3 tester does exactly this test but... in human format...

It is bad practice embed in map such hacks. They must be released as separated mutator. Because you can not know what bots operate here. Possible with same mutator and they can fight or make things worse.

False, I wrote Bot codes and so I know what I'm talking about - usually I do around 20-30 tests before to claim something READY. Even in a DeathMatch I can bring Bot to certain spot based on Bot itself. Bot reacts like a fish, a good bite catches him. A push code must leave pawn alone if has a target and sending it to a node ONLY if has Nothing to do - WANDERING. It doesn't affecting anything unless map is plain dumb - actor does damage in maps with lava holes and all sort of hazard and no, a generic mutator it's not welcomed at all in such a case.
PickLocalInventory concerns nearby items. Far away items are another story or else a DM map would never work. Exactly this case works when some objective such as Flag MonsterWaypoint cannot be found and Bot just follows another way if it's "FreeLance"-d.

In other hand, I have some UNR files here as Lab junks, some of them I deleted and others will never leave my machine because they don't have a DM purpose. Those are stages from which I'm learning or I learned and then I wrote my own Bots working better and having another sort of deal. I'm not telling stories because I did tests and I have logged their activity. First MBot from working lab was an expanded Bot having zero adds, I only logged what it does. After understanding code I went to add my codes.
Now if you give me some BBots, something better similar to that UZ compressor, I'll replace my Bots immediately. But... first you have to understand Stock's Bot mechanics, then we talk more.

Good. And now if you really want to see some interesting stuff, do a mutator and give to the Bot some toy/actor/whatever. When Bot has RouteCache[x] points active, drop whatever symbol-actors from this master actor around these RouteCache points 1 to 15. If you want to track where the Bot is moving just watch cache points and you'll see how is moving and let me know if you have full routes or just "local" bad smelling items.
Let me know if you need textures with route cache numbers. Then you can draw Bot Name for said RouteCache (something like team beacon).
Trivia: If you can see Bot's RouteCache, in a 1on1 DeathMatch you can see when Bot is hunting you, Routecache points are going to be wrapped up to closest Node from you. Jump on a bigger box without paths and routes are gone away from you when you'll go UnReachable from this closest node.

[Buggie]

Too bad that you think DeathMatch works only this way...

Too bad that you think I am think that...

I exactly describe what i mean. And specify of existence above another ways.
My main interest about supporting bots in MH which follow human.
So this notes about this case.

[sektor2111]

Bot which cannot follow human will roam around - this is what it does - from factory... Read this well and check it...
If you need another test map and extra testing information I'll demonstrate once again that I know what I'm talking about.

A few tunnels, a hole in walls where player can be kicked without paths heading there. Map has items all over the place. Order Bot to cover you from said hole in wall. Now look with F5 what it does when he cannot find you... He will execute code which I posted. I don't tell stories here.

Code returns when pawn is closer to OrderObject. If not, Pawn is trying to find OrderObject. If has no path given, code keeps moving ahead and there is native roaming, Bot is not wasting time waiting OrderObject to be on paths-net. He collects all good items far or closer.

MH and Bot - charging weapons and following human player ->
- Do paths always through InventorySpots;
- Do custom PathNodes with SpecialCost and grant access only if pawn has power (health, ammo and a well rated weapon) - expensive but efficient.
Stock UT has all needs for these things.

[Buggie]

I work about CoopTranslcator support for bots. So bot ALWAYS can follow player.
So there goes another problem. Prevent bots tele too early. Or with bare hands into middle of battle field.

In this case bot just fall to you head in direct sense of this words. no any paths or inventory spots.

[sektor2111]

no any paths or inventory spots.

And probably without enough ammo.
CoopTranslocator should Translocate only Bot which has a good charged weapon, testing Bot in timed cycles and not just teleporting alive pawn.

Am I wrong here ? Why would not allow time for being weaponized ?
Else, Spawn a copy of weapon held by Player OrderObject, give the copy weapon to Bot and full ammo...
Note: Use SkaarjCode for preventing some RateSelf weaponry bubbles. Spawn, RespawnTime 0, bHelditem, WCopy.Touch(Bot) or Bot.Touch(WCopy).
Ninja is ready now. Add some smoke when it's showing up nearby player... .

[sektor2111]

Credits Timer ON.

My old plugins were creating paths during map's run-time fired in stage by NavAdder main mutator - cancelled because XC_Engine was cancelled too and left unfinished, harder to be managed by normal users - too bad, it would be priceless.
I was doing these plugins spending more time for testing connections as long as I did not see them in that time but only deducting them. Right now I fired a map - an empty one - with paths created in game. It's visible that my work looks normal using this mutator which nobody did before, indeed I cannot see all data (not yet) but plugins are doing a good job. Of course, Teleporters were connected WJ not X but... it doesn't matter, they are working and this tool does an amazing job, it makes testing more simple.

Shortly: NICE JOB !