A Random Fact

[Nelsona]

Intro is this >> https://ut99.org/viewtopic.php?f=7&t=13560#p114826
The mental answer is:
I don't know if exist or not but it''s doable guaranteed... only for XCGE games because of translocator specific things.
When "No One cares" about what I'm saying there - as specified by some "smarts" - topic starter included, let's say that I can do such mutator as I did MHBotyMan1..5 series, it's easy to hunt Enemy-Flag or HomeBase, it's like hunting MonsterWayPoints showing to players where to move, but... I'm not gonna do anything, at least not for posting it over there because will definitely require XC_Engine for accurate results . Main Base it's done in my NsCTF used in M.G.S. - operational. For something better looking I would do some RouteCache markers with colored meshes like transparent arrows immune at lightning and wrapping them for properly showing direction - even tracking mobile nodes like LiftCenter types and/or my custom nodes...
Of course, I would think at last routecache (number 15) aspect how does it need to be presented - as a "and so on" thing, as a "last known path" or whatever fading or... a common arrow oriented to desired Flag...
Initial mental prototype might go for two pieces: King and Servant which means Server-Side and Common-Side. Let's say that we can be nice to not send all kind of garbage packages to client which aren't needed (all paths processing is server's job) but only required stuff properly mapped as package by ServerSide master.


As a matter of fact for a more constructive waste of time would be the work for wrapping default MonsterHunt using original code integrity, conforming it with last version released by Shrimp years ago and helping with this that NWIII server which is constantly attacked by Accessed Nones getting stuck at random... Such version might be used even for mapping and/or coding MyLevel things for MonsterHunt.

[Kelly]

This sounds not too hard at first, but it's going to be a nightmare to get done using stock UT stuff. You'll need a path network at the very least and you'll also need to be able to map the path at runtime. That's going to be a huge hit to the server, even if you try to drag it out by parsing a little at a time. A couple hundred pathnodes is a conservative total and that's going to take some time to solve. The larger maps with multiple hundreds of nodes would just need an external solution. Likely you'd need to path the maps with some sort of program and then make a map database that loads with the maps to spawn the smoke arrows.

[Nelsona]

Not really, majority of maps with paths are good for such a tool. As in MonsterHunt, CTF supports showing routecache for Owner. Instead of circles can be arrows - a mesh like in that "spawn-saver" whatever how it's called, but not as a coin with face but as an arrow - a well designed one. ALL stock maps are compatible with a path finder stuff - tested already and... the only problem might be TranslocStart actor which is crapped by Epic and UTPG removed path-finding feature in their "fix". As for pathing in run-time NavAdder is proving that has no major performance impact at all for mapping paths. The problem is/are another: each empty map requires writing a run-time network, such a solution is not for default UT because technically there is no support for creating reachSpecs - because all maps where Bot is moving are capable to move human too I REPEAT if navigation points from BotPack are hacked and conformed, and then HUGEE maps natively are not compatible with Bot/Human or whatever entity because are out of Engine boundaries.
Problem with TranlocStart can be solved in stock servers by replacing Botpack with a conformed version. For maps like that rammed in 300k contest I have another solution, more exactly finding path to a nearby PathNode that can be "seen" through network if FlagBase doesn't have a single normal reachSpec heading to that thing. Sample of another crapped map is CTF-GlacierCE10x (- clan Edition my a$$). They modified map having zero clue what the heck they did. Even with this issue, human player can figure where to go based on a nearby reachable PathNode or simply placing a dummy flag there - MH2 by me uses such a strategy almost like engine does for hunter pawn... I know what I'm saying, it's a bit of work, and for those like clowns at ut99.org I'm not gonna waste too much time and neither for those "making mutators" by copy-pasting. If Higor is a more nice person and wants, he can do that.

And now taking a tour through my memory. In a U227 game with a modified BotPack I could figure such a feature in a normal map having arrows pointing direction automatically depending on Player state: FlagCarrier - FlagHunter.

Ranting @Epic:
At least Your describeSpecs could show Collision data too but you did not do anything PRO for navigation - it's not like only Editor can do paths, geniuses...

The more clean reply: Such Mutator doesn't exist and no one did any because plain vanilla UT it's crashing in certain maps - thanks to Epic. But it's not impossible to do after some private files exchange session, and easily doable in XC servers.

[Nelsona]

In mean time RouteCache points might be changed in future versions of my pathing/testing toys like here... this is my design proposal >>

RC_Sample_0.PNG (775.67 KiB) Viewed 9730 times

Such arrows can show direction to follow, pathing based.
Other proposals are kindly accepted.

[Kelly]

That looks good but I'd set the strength really low so it renders only closely and you might lower the visibility of it way down. You could even allow it to be toggle-able by the client.

I'm interested to see how you do this Nels.

[Nelsona]

It's going to be shown as source-code for first stage.
All right... So far I got something for MonsterHunt (because MHBotyMan5 is base). These RouteCache are toggling between sprites and mesh. This way do seems more suitable as long as in plain fields even if I lowered location of these points they don't seems a good idea. Human is small, if arrow spawns on PathNode there might be nothing looking as an arrow from the back. Sprites with numbers are way more relevant than arrows but in whatever moments arrows are pointing that road turns to left or right so toggling them at 1.5 seconds do seems a good option. I reduced their glow because I want more visibility for combat without bugging eyes. In a dynamic CTF match you need to see opponents clearly. If you are lost you might check these points - perhaps final stage will have these permanent for all CTF player.
Now I have to wrap all client side in desired package letting main core only for server/authority.

A big Cave-At: not advisable usage in plain UT servers because you can expect a crash. Perhaps in whatever future I'll use some reference temporary Bot pawn somehow masked just for letting that moron to deal with paths or else Tranlocstart will break the party or WarpZoneMarker.

Edit: Note from testing
Perhaps that arrow has to be more 3D for being figured from various positions else it might be good to have multiple colors and/or something like in Darts...

[Kelly]

I'm really interested in seeing how you do this Nels.

[Nelsona]

You'll see it. Now I'm doing various MH tests before making a modified copy for CTF. Of course, for CTFGame it will need some new implementations. Functionality it's like in MHBotyMan5 but routecache points are toggling aspect sprite-arrows, arrows being wrapped in direction to follow to next one.
The questions:
- How should be named/titled this tool/mutator for CTF Game - it's a tool or a mutator ? It uses paths so it can be used for Testing... else for gaming it's a game helper.
- Activity - always active or... toggling it ON/OFF with mutate commands ? Player bugged by arrows always moving around it might feel frustrated in known maps.

Edit: More thoughts
If we have enemy Flag and our Flag is not at HomeBase perhaps we want to switch routes to enemy flag carrier. Else if we do not have any flag but enemy is holding our flag we need to find it. Or not ? If not why not ?
Seeking network has to be self-adaptive and even some messages shown to player accordingly, in my opinion... I'll need to copy some functions from Bot code which I have in NsCTF3... lol. And then I have to credit myself... .
All right, it will take a while to configure facts in codes.

[Nelsona]

Working note.
I like this function from Flag... Nope, I lie, I'm loving it... in hoping that Holder does exist if bHeld is true. Not a single time Epic were blabbering booleans "bIsPlayer" is a sample of stuff a la EPIC properly giving pain to MonsterHunt for years.

Code: Select all

function Actor Position()
{
	if ( bHeld )
		return Holder;

	return self;
}

and then I think at a moment I'll replace that "love" with another one a la Nelsona - that's it, for old people sometimes an old love is being replaced :

Code: Select all

function Actor Position()
{
	if ( Holder != None && !Holder.bDeleteMe )
		return Holder;

	return self;
}

I'm no longer having trust in their bools... they ruined their own rules, and then I have to rewrite stuff with slower lines... but way more logic and safe.

[Nelsona]

Initial Stage do seems to work - map loaded for testing CTF-BigAndUgly whatever by Frag'N'Brag and using XC_Engine 24 - not sure if all typo is good but... results are important. Here are ONLY Source-Codes.
Mutator/Tool uses two parts like I said. Main mutator has a single class but it has a dependency common part with routecache beacons in case of network play which has to be a package or else player/tester won't see anything...
In order to compile these, first thing is common part - mutator will need this part:

CTFRCBeacon.zip

(23.24 KiB) Downloaded 459 times

This is not mutator is resource package.
And master mutator using previous package which is compiled after compiling prior package:

CTFFlagTracker.zip

(10.14 KiB) Downloaded 426 times

and INT file for loading mutator in list

CTFFlagTracker_int.zip

(243 Bytes) Downloaded 443 times

I did a few tests not really in bad pathed maps and not out of XCGE because I think TranslocStart will crash default game.

Operation:
Mutator is latent in first stage doing nothing by default. When Player/MapTester is firing command mutate mebot (can be changed) technically mutator should start working more convinced in background. If game situation is changing: TeamFlag is taken by enemy, it has to be recovered, beacons spawned from second common package will switch finding routes to enemy carrier or to flag if dropped. If Team Flag is OK routes will head to enemy flag. If a mate is holding Enemy Flag routes are pointed to this guy because you have to cover your carrier. If Flag is being captured routes are pointed again to Enemy Base or Enemy Flag if is on the ground somewhere and can be found using map's paths. Beacons are switching between Sprite circles and Mesh Arrows except the one called in Bot language "MoveTarget" and that is RouteCache[0] - that one is a sort of path/goal processor. Mutator when goes annoying can be turned off with command mutate stopnav.
I don't claim this a final version because I have to do more intensive testing. Perhaps future version will have some Deal with AlternatePath actors - not yet implemented, I have already drunk a lot of coffee for having focus here in order to cover various CTF situations...

For explained functions I'll drop some remarks later if are desired.