CTFM-FSW-DxTrEmeFx-2022

[[NBK]DxTrEm3Fx]

This is an old DM map of mine I converted to multi-CTF IG low gravity and a redeemer only. Simple set of cubes and a couple of custom brushes. Since I downloaded UTPatch469c I'm having a hard time getting some of my UT tools working like Map Garbage. So I haven't checked the map.
This is the updated map dated 9/19/2022

CTFM-FSW-DxTrEmeFx-2022.zip

(5.5 MiB) Downloaded 4 times

[EvilGrins]

Near as I can tell, bots use the whole area pretty well. There's no problem getting flags and getting back to bases, even with instagibs being the primary weapon on the map. If you fall over the side into the water you're very soon dead.

There are NO SMOKING signs too high up for anyone to be smoking.

A couple spots bots seemed to get stuck, but I couldn't tell if they were waiting for something as instagibs... they died too quick to tell.

When I initially opened the map it opened in Standard CTF (double-clicked on the map file) as gametype was set for Class'Botpack.CTFGame'. I fixed that so it's now on Class'MultiCTF.MultiCTFGame'.

[sektor2111]

What's up with PlayerStart27 ?
PathNodes around FlagBase3 are hilarious - without MapGarbage can be seen overcrowded areas and nodes in air. These are having logically connected ReachSpecs but I doubt that Bots can use them normally. These are similar copies of bugged PathNode112 placed on the ramp from map CTF-Command - players can see what Blue Carrier does there...

Near as I can tell, bots use the whole area pretty well.
......
A couple spots bots seemed to get stuck...

Interesting... You might look how are nodes placed... and this is not a bug free network. In other hand... boys witnessing a Bot running in place somewhere can deliver a console command called "ShowAll" and... they can figure that Bot must fly to reach at node "buzzing over his head" like a horse-fly. Doesn't matter if Bot is trying this two weeks or twenty years - if will fail.

Code: Select all

LostData: ReachSpecs missing from Paths[0-15] 		= 701.
LostData: ReachSpecs missing from upStreamPaths[0-15] 	= 479.
FixedWithSuccess: ReachSpecs successfully attached 	= 1106.
FixFailures: ReachSpecs attaching failures - probably no place = 74.

Edit: A few things which I'm not sure if turtles tutorials are describing.
In maps with stairs and ramps where PathNode (originally designed for Skaarj usage) can do funky paths because of Scout, you can keep in mind Navigation Nodes that are aiming Bot:
#1 - InventorySpot (not Shown in plain view) is a small NavigationPoint just because it must ensure navigation here - Stock Bot is aiming these points inside its code - "FindBestInventoryPath";

Code: Select all

FindBestInventoryPath(BestWeight, !bNovice && (skill >= 2))

#2 - PlayerStart where Bot(and The Player) spawns it's causing Bot to be thrown INSIDE Network without the need for that 800 UU 3D test concerning the entering into network. It will be already joined.
And then ? What's the logic of these aiming Bot and what can we do with regard to PathNodes ?
We need to ensure a good placement for PathNodes in similar format as PlayerStarts and InventorySpot. Is this even possible ? YES ! Piece of cake.
We don't drop nodes into map before a preparation. By browsing classes -> NavigationPoint -> PathNode we can access default properties of this class (no, we won't save any stock file but only the map). We adjust PathNode to the size of 40(39) × 20(18) and bCollideWhenPlacing = False. This is what MapGarbage does to some funky nodes (PRE-PATHING task) more exactly BEFORE placing Nodes, in order to allow placement where mapper needs them - we are Bots and we don't care about colors red-blue.
PathNodes placed this way are in lower locations definitely accessible by Pawn having 39×17 dimensions, as long as the map is aiming Bots.
Does this tweak altering assets and Editor ? No, never. You can Save Map after placing Nodes, close Editor, re-open Editor and Map and check properties for these - nothing was changed, default properties for them are normal and are fine. How comes that all are normal after previously they were changed before placing them in map ? DefaultProperties from PathNode are stored in Engine. If you are not saving Engine file (altering stock is not advisable at all) in next session all are loaded as they are in original format. In previous session we altered properties but... NOT SAVING them, so they won't be affected.

#3 Why is not really advisable moving Nodes (and/or PlayerStart actors) after placement ? They not only can fail in having normal paths but might do lousy reactions if they are moved in BSP buggers or into void. If Engine is refusing to put somewhere such an actor, there are reasons for that and we don't need to use brute-force for our own failure.

[[NBK]DxTrEm3Fx]

Near as I can tell, bots use the whole area pretty well. There's no problem getting flags and getting back to bases, even with instagibs being the primary weapon on the map. If you fall over the side into the water you're very soon dead.

There are NO SMOKING signs too high up for anyone to be smoking.

A couple spots bots seemed to get stuck, but I couldn't tell if they were waiting for something as instagibs... they died too quick to tell.

When I initially opened the map it opened in Standard CTF (double-clicked on the map file) as gametype was set for Class'Botpack.CTFGame'. I fixed that so it's now on Class'MultiCTF.MultiCTFGame'.

Thank you for looking and providing feed back. Yeah, I have been opening a lot of CTFM maps I find and some have as game type as Class'Botpack.CTFGame' and others have Class'MultiCTF.MultiCTFGame'. Some have nothing at all. I will make sure I update it to Class'MultiCTF.MultiCTFGame'.

---

Automatically merged

What's up with PlayerStart27 ?
PathNodes around FlagBase3 are hilarious - without MapGarbage can be seen overcrowded areas and nodes in air. These are having logically connected ReachSpecs but I doubt that Bots can use them normally. These are similar copies of bugged PathNode112 placed on the ramp from map CTF-Command - players can see what Blue Carrier does there...

Near as I can tell, bots use the whole area pretty well.
......
A couple spots bots seemed to get stuck...

Interesting... You might look how are nodes placed... and this is not a bug free network. In other hand... boys witnessing a Bot running in place somewhere can deliver a console command called "ShowAll" and... they can figure that Bot must fly to reach at node "buzzing over his head" like a horse-fly. Doesn't matter if Bot is trying this two weeks or twenty years - if will fail.

Code: Select all

LostData: ReachSpecs missing from Paths[0-15] 		= 701.
LostData: ReachSpecs missing from upStreamPaths[0-15] 	= 479.
FixedWithSuccess: ReachSpecs successfully attached 	= 1106.
FixFailures: ReachSpecs attaching failures - probably no place = 74.

Edit: A few things which I'm not sure if turtles tutorials are describing.
In maps with stairs and ramps where PathNode (originally designed for Skaarj usage) can do funky paths because of Scout, you can keep in mind Navigation Nodes that are aiming Bot:
#1 - InventorySpot (not Shown in plain view) is a small NavigationPoint just because it must ensure navigation here - Stock Bot is aiming these points inside its code - "FindBestInventoryPath";

Code: Select all

FindBestInventoryPath(BestWeight, !bNovice && (skill >= 2))

#2 - PlayerStart where Bot(and The Player) spawns it's causing Bot to be thrown INSIDE Network without the need for that 800 UU 3D test concerning the entering into network. It will be already joined.
And then ? What's the logic of these aiming Bot and what can we do with regard to PathNodes ?
We need to ensure a good placement for PathNodes in similar format as PlayerStarts and InventorySpot. Is this even possible ? YES ! Piece of cake.
We don't drop nodes into map before a preparation. By browsing classes -> NavigationPoint -> PathNode we can access default properties of this class (no, we won't save any stock file but only the map). We adjust PathNode to the size of 40(39) × 20(18) and bCollideWhenPlacing = False. This is what MapGarbage does to some funky nodes (PRE-PATHING task) more exactly BEFORE placing Nodes, in order to allow placement where mapper needs them - we are Bots and we don't care about colors red-blue.
PathNodes placed this way are in lower locations definitely accessible by Pawn having 39×17 dimensions, as long as the map is aiming Bots.
Does this tweak altering assets and Editor ? No, never. You can Save Map after placing Nodes, close Editor, re-open Editor and Map and check properties for these - nothing was changed, default properties for them are normal and are fine. How comes that all are normal after previously they were changed before placing them in map ? DefaultProperties from PathNode are stored in Engine. If you are not saving Engine file (altering stock is not advisable at all) in next session all are loaded as they are in original format. In previous session we altered properties but... NOT SAVING them, so they won't be affected.

#3 Why is not really advisable moving Nodes (and/or PlayerStart actors) after placement ? They not only can fail in having normal paths but might do lousy reactions if they are moved in BSP buggers or into void. If Engine is refusing to put somewhere such an actor, there are reasons for that and we don't need to use brute-force for our own failure.

Thank you for checking it out and providing feedback. I'm trying to figure out why my MapGarbage isn't working. That's why the map was never tested with it. There should be 32 players starts 8 on each base. Once i get home from work i will see if I can get mapgarbage working. Are you using UTPatch469c and mapgarbage is for you?

[OjitroC]

I can confirm that MapGarbage works fine in 469c RC-4.

It's hard to know why it doesn't work for you - you have it listed in your UT.ini under [Editor.EditorEngine] as an EditPackage otherwise it wouldn't show up - presumably you right-click on the icon to open the dialogue? And then set the options you want to use to True and click Build? Under WindowPositions in the UT.ini, do you have something like
Brush Builder.Width=500
Brush Builder.Height=900 ?
These set the dimensions of the dialogue boxes of the various tools including MapGarbage - a very low Width or Height would probably mean the dialogue wouldn't show.

Running a basic check on the paths shows the following

Spoiler

UnReachableNodes: PathNode164 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode308 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode313 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode340 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode342 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode347 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode348 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode349 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode350 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode351 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode352 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode354 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode29 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode54 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode81 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode90 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode92 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode93 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode105 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode137 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode147 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode155 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode163 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode165 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode166 looks much over ground for normal Human Size, check it.
UnReachableNodes: PathNode168 looks much over ground for normal Human Size, check it.
UnReachableNodes: Here we have 0 points skipped, 26 Navigation Points which are too high and 235 good ones.
NoIncomingPath: PathNode348 is not having incoming connections.
NoIncomingPath: PathNode349 is not having incoming connections.
NoIncomingPath: PathNode351 is not having incoming connections.
NoIncomingPath: PathNode352 is not having incoming connections.
NoIncomingPath: PathNode90 is not having incoming connections.
NoIncomingPath: PathNode92 is not having incoming connections.
NoIncomingPath: PathNode93 is not having incoming connections.
NoIncomingPath: PathNode163 is not having incoming connections.
NoIncomingPath: PathNode165 is not having incoming connections.
NoIncomingPath: PathNode166 is not having incoming connections.
UtterlyUseless: PlayerStart27 is not having any path defined.

[sektor2111]

I don't know what's up with 469c or whatever, but I only know that if builder's icon is not in editorres folder, builder not in System (or paths for U files) and INI file not mentioning it in EditPackages it's not like the builder will ever show up. Several things which I explained I could see without firing any builder. I did a few checks later. Basically the most ugly issue where player can be punished is that PlayerStart from void.

[[NBK]DxTrEm3Fx]

Okay, as usual, thank you, guys, for your help. I guess after patching you need to re-add your tools back to the .ini since they were all gone in my case. The PathNodes are all fixed along with the PlayerStarts including PS27. No overcrowding going on. I wish someone would update MapGarbage to include Teams 2 and 3 it would sure be helpful for game types that use four teams. Also, I updated the default game type to Class'MultiCTF.MultiCTFGame.
I will update the original post link to the new map version above.

Code: Select all

UnreachNotes: Nodes found with a high placement it's advisable to be pushed lower if they don't have a special purpose.

UnreachNotes: Some of these might be causing loops or they can work, but almost at boundary.
UnreachNotes: These problems are happening more often in ramps. Those 300-400 UU recommended distances are not exactly ramp needs.
UnreachNotes: Pawn should collide center of Navigation Node for being pointed at next one, else it will retry from previous point.
UnreachNotes: This function was written based on that borked PathNode112 from map CTF-Command which is known as a harder one.
UnreachNotes: Such nodes placement it's not welcomed anywhere.
UnreachNotes: LiftCenter types or various special nodes might not have real problems here due to other movement logic required for them.
UnreachNotes: Aerial paths usually are not reachable for Bots but they are working according to their purpose in maps having them properly mapped.
UnReachableNodes: Here we have 0 points skipped, 0 Navigation Points which are too high and 213 good ones.

[sektor2111]

PlayerStarts are reported for all teams since 4-5 updates ago if I'm not mistaking. For Textures assigned I did not used more - it generates dependencies perhaps I'll look at stock UnrealShare UnrealI for finding something useful.
In next version these UnReach Nodes (PathNodes on purpose) will have an optional fix - optional because it might not be useful everywhere.
Instead of inspecting 30 Nodes one by one, all of them are pushed down on the ground with some 50 UU under a second and... Editor takes care to not be buried based on some temporary settings assigned for them, after solving problems they will go reverted to original properties. Yes, they are getting placed as PlayerStarts closer to Bot specific size.

[[NBK]DxTrEm3Fx]

PlayerStarts are reported for all teams since 4-5 updates ago if I'm not mistaking. For Textures assigned I did not used more - it generates dependencies perhaps I'll look at stock UnrealShare UnrealI for finding something useful.
In next version these UnReach Nodes (PathNodes on purpose) will have an optional fix - optional because it might not be useful everywhere.
Instead of inspecting 30 Nodes one by one, all of them are pushed down on the ground with some 50 UU under a second and... Editor takes care to not be buried based on some temporary settings assigned for them, after solving problems they will go reverted to original properties. Yes, they are getting placed as PlayerStarts closer to Bot specific size.

That is correct it counts all four teams just no green and yellow texture is being shown as you mentioned. The visual of the texture helps me anyway with the placement of the PS and making sure they are symmetrical.

[sektor2111]

Okay, so you recommend me to add some Textures for Green and Yellow - not a bad idea... I go to search into Textures.
___
Edit: I think this is what will be here in next Update... perhaps it helps...

[[NBK]DxTrEm3Fx]

Okay, so you recommend me to add some Textures for Green and Yellow - not a bad idea... I go to search into Textures.
___
Edit: I think this is what will be here in next Update... perhaps it helps...

4TeamsMaybe.PNG

That's awesome nice work!