CTF-SpaceX

Tutorials and discussions about Mapping - Introduce your own ones!
User avatar
LDinos
Novice
Posts: 15
Joined: Mon Aug 15, 2022 5:40 am

CTF-SpaceX

Post by LDinos » Wed Sep 28, 2022 2:53 am

A modified version of my map DOM-SpaceX, now for the CTF gamemode!
This is a small CTF map (considering you can take the flag in just mere seconds), however it includes at least 4 paths to reach each flag.

Recommended flag point limit: 5+
Maximum recommended players: 12

The changes to pickups compared to the DOM version are that the redeemer is moved to the Lava room, and armor/shields were added for both team sides for balance.
Special thanks to the discord community that helped me with pathfinding problems with bots :)

Screenshots:
Image
Image
Image

For any map updates, you can check out my Github map page

Update 1: Changed path nodes, flag position a bit and generally followed tips from comment below
You do not have the required permissions to view the files attached to this post.
Last edited by LDinos on Wed Sep 28, 2022 10:17 am, edited 1 time in total.

Buggie
Godlike
Posts: 1773
Joined: Sat Mar 21, 2020 5:32 am

Re: CTF-SpaceX

Post by Buggie » Wed Sep 28, 2022 5:28 am

Some advices:
1. Always zip your stuff. In this case it is 870 KB instead of 2.2 MB.
2. Use Radii view on mapping. It is easy see - your flags floating in air.
scr_1664337674.png
3. Run map against MapChecker: viewtopic.php?f=5&t=14809
It can save your time. Like it be with flags.
ScriptLog: ZoneInfo with AmbientBrightness == 0:
ScriptLog: LevelInfo0
ScriptLog: ZoneInfo1
ScriptLog: ZoneInfo0
ScriptLog: ZoneInfo2
ScriptLog: LavaZone0
ScriptLog: ZoneInfo3
ScriptLog: ZoneInfo4
ScriptLog: ZoneInfo5
ScriptLog: ZoneInfo6
ScriptLog: ZoneInfo7
ScriptLog: ZoneInfo8
ScriptLog: ZoneInfo9
ScriptLog: Red FlagBase with blue skin
ScriptLog: FlagBase0 Team = 0 Skin = Botpack.Skins.JpflagB
ScriptLog: CTF map with unfair count PlayerStarts: Red = 10, Blue = 8
First thing about zones - set to all zones AmbientBrightness to 1. This kill possibility create complete dark places, where someone can hide.
Skin of FlagBase better change in editor. This help you do mapping, and know what flag is where.
Last is self-explanatory.

Also for start better stick for mirror map layout.
Current map layout is unfair. Blue have advantage, since have easy access to second level. When red - not.
Boots not is same as walkable entrance.

So in fact blue take boots on own base, come to red from up take blue shield and armor, jump up and left away. And no any chance red catch them.
4. Paths contain A lot mistakes.
Lift combos not use proper lift tag, so all connected between them (pink lines). it must be lines only between each combo.
scr_1664338483.png
Some paths simple missing:
scr_1664338601.png
Some path nodes place in air
scr_1664338854.png
Some places miss pathnode, like this near sound actor:
scr_1664338947.png
Understanding such stuff come with experience and with use Mind reader mutator.

So I suggest Use Mind Reader viewtopic.php?f=7&t=13057
Also use viewtopic.php?f=7&t=15075
Add 1 bot and spectate what he do and how. And if you see unnatural movement, which look weird - change paths.

I use command
start Autoplay?Mutator=MindReader.MindReader,FixCTFBots.FixCTFBots
After load map from unrealed.
addbots 1
for add one bot
And
slomo 1
with numbers 1 3 0.1 for found what happen with need speed.
You do not have the required permissions to view the files attached to this post.

User avatar
LDinos
Novice
Posts: 15
Joined: Mon Aug 15, 2022 5:40 am

Re: CTF-SpaceX

Post by LDinos » Wed Sep 28, 2022 10:15 am

Buggie wrote:
Wed Sep 28, 2022 5:28 am
Some advices:
1. Always zip your stuff. In this case it is 870 KB instead of 2.2 MB.
2. Use Radii view on mapping. It is easy see - your flags floating in air.
scr_1664337674.png
3. Run map against MapChecker: viewtopic.php?f=5&t=14809
It can save your time. Like it be with flags.
ScriptLog: ZoneInfo with AmbientBrightness == 0:
ScriptLog: LevelInfo0
ScriptLog: ZoneInfo1
ScriptLog: ZoneInfo0
ScriptLog: ZoneInfo2
ScriptLog: LavaZone0
ScriptLog: ZoneInfo3
ScriptLog: ZoneInfo4
ScriptLog: ZoneInfo5
ScriptLog: ZoneInfo6
ScriptLog: ZoneInfo7
ScriptLog: ZoneInfo8
ScriptLog: ZoneInfo9
ScriptLog: Red FlagBase with blue skin
ScriptLog: FlagBase0 Team = 0 Skin = Botpack.Skins.JpflagB
ScriptLog: CTF map with unfair count PlayerStarts: Red = 10, Blue = 8
First thing about zones - set to all zones AmbientBrightness to 1. This kill possibility create complete dark places, where someone can hide.
Skin of FlagBase better change in editor. This help you do mapping, and know what flag is where.
Last is self-explanatory.

Also for start better stick for mirror map layout.
Current map layout is unfair. Blue have advantage, since have easy access to second level. When red - not.
Boots not is same as walkable entrance.

So in fact blue take boots on own base, come to red from up take blue shield and armor, jump up and left away. And no any chance red catch them.
4. Paths contain A lot mistakes.
Lift combos not use proper lift tag, so all connected between them (pink lines). it must be lines only between each combo.
scr_1664338483.png
Some paths simple missing:
scr_1664338601.png
Some path nodes place in air
scr_1664338854.png
Some places miss pathnode, like this near sound actor:
scr_1664338947.png
Understanding such stuff come with experience and with use Mind reader mutator.

So I suggest Use Mind Reader viewtopic.php?f=7&t=13057
Also use viewtopic.php?f=7&t=15075
Add 1 bot and spectate what he do and how. And if you see unnatural movement, which look weird - change paths.

I use command
start Autoplay?Mutator=MindReader.MindReader,FixCTFBots.FixCTFBots
After load map from unrealed.
addbots 1
for add one bot
And
slomo 1
with numbers 1 3 0.1 for found what happen with need speed.
Thank you for the feedback! OK, so
1. Will update it now, I totally forgot to zip it
2. Moved the flags further down now
3. MapChecker was helpful and I had fixed lots of mistakes prior to uploading, didn't really know much about the ambient brightness and that's why I didn't mess with them, but I will change them to 1 now after your information :)

Mirror layout is indeed the best idea for CTF maps, but since this was just a map conversion from DOM to CTF, I decided to try it out as it is
I might have to disagree with you about the boot balance here though as both sides have boots available for top level access (and of course translocators can be used aswell). Also, Red team has spawns on the top side which can also balance this out.
Image

4. Thank you about the paths, I fixed these now. About the lifts, you are right, however, I don't know if this is pure luck or if this is working as intended, but my bots would absolutely know what they are doing even when the names were all the same. My initial idea was that the bots could translocate/jump to any platform they wanted from the same initial position and vice versa which is why the names are all the same. I could do lots of liftexits-jumpspots, but that seemed optimal to me at that current time since I wouldn't have to add so many of them near each other. Even so, I will update it and do it the right way right now

Overall, you were really helpful, thanks for checking my map out :)

User avatar
sektor2111
Godlike
Posts: 6039
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: CTF-SpaceX

Post by sektor2111 » Wed Sep 28, 2022 2:38 pm

LDinos wrote:
Wed Sep 28, 2022 2:53 am
Special thanks to the discord community that helped me with pathfinding problems with bots
Useless in big parts, like I said xxxx times, the first thing to do in learning these is ORIGINAL docs written by POLGE himself and not some of those based on "let me guess". Such as...
OldDocs
Show
PolgeDocs wrote: The Navigation Network
Creating the Navigation Network

Unreal Tournament bots use a system of waypoints to navigate the level. Using waypoints allows UT to minimize the CPU cycles used by the AI, and gives level designers maximum control over how the AI navigates their levels.

These waypoints are defined by placing actors which are subclassed from NavigationPoint in the level. This includes actors such as PlayerStarts and Teleporters which designers will place to make their level playable. Certain NavigationPoints, such as InventorySpots and WarpZoneMarkers are automatically placed when the designer "defines" the paths (described below). Other NavigationPoints are intended for Unreal I style single player situations and are not used at all in UT. These include AlarmPoints, ButtonMarkers, PatrolPoints, QueenDests, SpawnPoints, Transporters, and TriggerMarkers.

Once the level geometry is complete, the level designer should fully map the level into the navigation network using PathNodes. Place PathNodes at intersections and turns so that there is as much clearance as possible from corners (at least 50 world units if possible). Paths need a line of sight to each other, clear to the width of the maximum width (2 * collisionradius) of creatures which will use this path. PathNodes should not be placed more than 700 units apart. Since PlayerStarts and Inventory will be placed on the navigation network, the designer can (and should) not place PathNodes where these other NavigationPoints can substitute. On stairs and ramps, the PathNodes should only be 350 units apart. The objective should be to use a minimum number of PathNodes to completely cover a level.

Version 402 of Unreal Tournament has an automatic PathNode generator which will do part of the work of placing paths automatically. It will attempt to cover the level with paths, but will not place special NavigationPoints such as playerstarts, liftcenters, etc.. To use the automatic PathNode generator, open your level in UnrealEd. Select the Window menu, and from it the log. At the prompt type 'Paths Build' (no quotes). This will take 5 to 10 minutes for a typical level.

To navigate around the level, bots will first find the nearest reachable NavigationPoint, and move to it. They will then move toward their destination, going from NavigationPoint to NavigationPoint. It is important that some NavigationPoint is reachable (there are no obstructions in the way) from any location a bot may reasonably get to in the level. If a bot can't find a valid path, either because it can't find a way to get on the network, or there is no valid way to get from the network to its destination, or the path on the network is broken, then the bot will wander (walking) around its current area.

The final step in setting up the navigation network is performing a PATHS DEFINE. This can be done by typing PATHS DEFINE into the UnrealEd console, or pressing the "Paths Define" button in the lighting section of the rebuild window. The designer can examine the network generated in any of the UnrealEd world view windows by selecting "Show Paths" from that window's "View" menu. NavigationPoints which are successfully connected will have either blue or red lines between them. Bots will use either blue or red paths, but blue paths are preferable - they indicate a cleaner, more obstruction free path. Each time geometry is changed or NavigationPoints are added or moved (including inventory, since paths are generated from inventory items), a PATHS DEFINE should be performed.

There are several common problems that result from assumptions and approximations made by the AI to minimize CPU overhead. Make sure that all NavigationPoints are separated by at least 50 world units. If two pathnodes are too close together, a bot may get stuck on them. The editor log window will display warnings during a PATHS DEFINE if paths are too close together. This problem commonly occurs with InventorySpots, which are automatically placed near all inventory items. Don't place PathNodes too near to inventory.

In some situations, bots may get stuck on the edge of a ledge where it runs into a wall. This occurs because of a threshold problem. Bots won't jump off ledges until the angle of their destination is greater than 45 degrees from the ledge direction. If they run into a wall right around this threshold, they may get confused. The solution is to adjust the NavigationPoint they were trying to reach, or add an intermediate PathNode.

Bots will have problems if the NavigationPoints are too high off the ground. Make sure that the NavigationPoint is no more than 1.5x the bot's collisionheight off the ground. This will normally be the case automatically, but in a few situations (such as very steep ramps), the level designer may need to manually adjust the Z position of the NavigationPoint.

PathNodes for the bots to use while swimming must be in the water. Placing paths above the water's surface will result in bots bobbing at that spot, attempting unsuccessfully to levitate to the PathNode's location.

WarpZones should be at least 70 units deep to allow the AI to handle them properly.

Adding Support for Lifts

There are two special NavigationPoint classes used to help bots understand how to use lifts, LiftCenters and LiftExits. Give the lift a unique tag. Place a LiftCenter on the lift, and set its LiftTag attribute to be the tag of the lift. At each exit from the lift, far enough away so that bots standing at that spot won't interfere with the lift, add a LiftExit. Each LiftExit should have its LiftTag set to the tag of the lift.

The default state for movers is BumpOpenTimed. Do not use this state for lifts! Bots misinterpret movers that are BumpOpenTimed as being doors. Instead, use the StandOpenTimed state for most lifts. Bots will also understand triggered lifts (TriggerOpenTimed, TriggerToggle, etc.). In many cases, they will use triggered lifts without any further help. However, for certain complex situations, such as when a delayed dispatcher is used to control the lift, bots may need a hint. In these cases, set the LiftCenter's LiftTrigger attribute to the tag of the trigger the bot should use to control this lift.

There are two other configurable LiftCenter attributes of interest. These should be modified only if absolutely necessary. MaxZDiffAdd, which defaults to 0, specifies an additional allowable difference in height between the bot and the LiftCenter for the bot to consider that LiftCenter reachable. This is useful if the bot must stand below the lift (down stairs or a ramp) while waiting for it. MaxDist2D is the maximum distance between the bot and the LiftCenter. It defaults to 400 world units.

NavigationPoint Attributes

The only configurable NavigationPoint attribute that should be modified is bOneWayPath. bOneWayPath can be set to true so that paths will only be valid in the direction the NavigationPoint is facing. Turn on the bDirectional attribute of the NavigationPoint to adjust the direction it faces.

Special Purpose NavigationPoints

Several special purpose NavigationPoints exist to provide tactical or game specific positions or to provide support for special movement modes such as using translocators and jumpboots. Game specific NavigationPoints will be described in the section of this document devoted to that game type.

PlayerStarts specify allowed spawning locations for players and bots. There are two relevant configurable attributes in PlayerStarts. The TeamNumber attribute specifies which team is allowed to spawn at that PlayerStart in teamgames where team specific PlayerStarts are enforced. The bEnabled attribute, which is true by default, can be toggled to enable or disable the PlayerStart by triggering the PlayerStart.

AmbushPoints are used to specify good camping spots. They are directional and should be pointed in the direction the bot should be looking while using that AmbushPoint. AmbushPoints have two configurable attributes, SightRadius and bSniping. SightRadius specifies how far out the bot should be looking for enemies when camped at the AmbushPoint. bSniping specifies that bots using this ambushpoint should stay at this point and snipe after acquiring an enemy, rather than chasing after the enemy.

DefensePoints are a subclass of AmbushPoint used in team games. DefensePoints have three additional configurable attributes, Team, Priority, and FortTag. The Team attribute specifies which team should use this defensepoint (0=Red, 1=Blue, 2=Green, 3=Gold). The Priority attribute is used in team games to determine which DefensePoints will be manned first (higher priorities are manned earlier). The FortTag attribute is used in Assault games to associate a defensepoint with a particular FortStandard.

BlockedPaths are used to keep bots from attempting to follow routes which are initially blocked (such as a bridge which must be lowered). . When triggered, the BlockedPath is unblocked. Once unblocked, a BlockedPath cannot be re-blocked. If using a BlockedPath, make sure that there aren't any path connections which bypass the BlockedPath and render it useless. AS-Mazon has some good examples of the use of BlockedPaths.

TranslocDests are a special type of LiftCenter which are not associated with a mover. TranslocDests are used to define places that bots can use a translocator to cut a route short. A lifttexit should be placed at the spot where the bot should stand a use his translocator, and a TranslocDest should be placed where the Translocator Target should be thrown. Another liftexit should be placed near the TranslocDest, as an "exit" from this "lift". The LiftExits and the TranslocDest should be given the same LiftTag.

Bots will assume that any LiftExit with the same LiftTag as a TranslocDest can be directly reached from the TranslocDest, without any special action on the bot's part. If the bot must use the translocator to get from the TranslocDest to one of the LiftExits, replace that LiftExit with a TranslocStart.

JumpSpots are similar to TranslocDests, and are also placed in conjunction with LiftExits all given the same LiftTag. Bots understand that in low gravity areas, or in JumpMatch, or if they have JumpBoots, they can also jump to reach JumpSpots. In addition, if the bImpactJump attribute of the JumpSpot is true, higher skill bots will impact jump (using the impact hammer) to reach the JumpSpot. If the bAlwaysAccel attribute is true, bots will use air control to reach the JumpSpot (try this only if they are failing without it).

Teleporters send any pawn which touches them instantly to their destination teleporter, as specified by their URL attribute. If the URL attribute is empty, the teleporter acts only as a teleporter destination. If it contains the same string as the tag of another teleporter in the level, that teleporter will be the destination. If it contains a string in the form of LevelName/TeleporterName, it will teleport to a different level on this server (single player only). If it contains a string in the form of Unreal://Server.domain.com/LevelName/TeleporterName, it will teleport to a different server on the net.

If a teleporter's bEnabled attribute is false, then it will not teleport pawns which touch it, although it can still act as a teleporter destination. The bEnabled attribute is toggled by triggering the teleporter. If the bChangesYaw attribute is true, pawns arriving at this teleporter will have their yaw changed to the teleporter's yaw. If the bChangesVelocity attribute is true, pawns arriving at this teleporter will have their velocity set to the teleporter's TargetVelocity.

Tweaking and Debugging the Navigation Network

After placing and "defining" the navigation network, the level designed should tweak and debug it by watching bots play the level. The designer should the game as a spectator, and add first one and then later several bots to the level. The designer can watch them play, advancing through the bot cameras using the fire button, and looking for problem areas. If the bot currently being viewed seems to be acting strangely, using the console command verbose will indicate what it is thinking. After the play session, reviewing the log file may also provide insight to problems.

If the bots don't seem to understand how to get to a certain destination, the designer can use the rememberspot and showpath console commands to look for breaks in the navigation network. When the rememberspot command is used, the current location is saved. Subsequent showpath commands will cause the best visible NavigationPoint on the path to the remembered location to become visible. If no NavigationPoint becomes visible, there is no valid path to the remembered location.

If a player cannot fit in the position specified by a PlayerStart, then the player cannot properly enter the game and will either wander as a spectator or the game will crash. The log file for that play session will have information on which PlayerStart caused the failure.
UT Game Types

The Unreal Tournament team games require special actors to be placed in the level.

Domination

Domination requires ControlPoints, which are a type of NavigationPoint, to be placed at strategic locations in the level. As with all NavigationPoints, these must not be placed too close to another navigation point, and they must be placed at ground level or bots will be confused by them.

ControlPoints have several editable attributes of interest. When a player gains control of a ControlPoint (by touching it), the optional event related to the player's team is triggered. These events are specified by the RedEvent, BlueEvent, GoldEvent, and GreenEvent attributes. The bSelfDisplayed attribute specifies whether the ControlPoint mesh (which depends on which team controls it) is visible. The PointName attribute gives a human readable name to the ControlPoint. The ControlSound attribute specifies the sound to be played when control of the ControlPoint changes.

Capture the Flag

Capture the Flag requires FlagBases, which are a type of NavigationPoint to specify the home location of the flag for each CTF team. There can only be two CTF teams, and each can only have one FlagBase. The team attribute of the FlagBase specifies to which team the FlagBase is associated, with 0=Red, and 1=Blue.

AlternatePaths are used to indicate alternate routes that bots can use to enter an opponent's base. The AlternatePath's team attribute should be the same as the team of the FlagBase for which the AlternatePath is pointing out a route. The AlternatePath's SelectionWeight is used to modify the likelihood of bots using that path. Bots use AlternatePaths by first moving along the shortest route to the AlternatePath they have chosen, and then moving along the shortest route from their to the FlagBase. If the AlternatePath is set up so that the shortest route to the AltermatePath involves running right by the FlagBase, bots will do that (a bad thing!). The location of AlternatePaths may need to be adjusted to provide the desired results. AlternatePaths with the bReturnOnly flag set true are used by bots with the same team number returning to their base with a flag.

Assault

The FortStandard is used to define the objectives in the Assault map. There can be multiple FortStandards in a map. The bFinalFort attribute if true specifies that when the FortStandard is destroyed, the level is completed even if there are other FortStandards still active. The DefensePriority attribute specifies the order in which the FortStandards should be defended, with the highest DefensePriority FortStandards defended first. The NearestPathNodeTag attribute should always be used to provide bots a hint about how to get to the FortStandard. Set it to the tag of the nearest reachable PathNode. The optional FallBackFort attribute specifies which fort defenders should fallback to if the FortStandard is destroyed (set the FallBackFort to the tag of the desired FortStandard). The bTriggerOnly attribute specifies that the FortStandard should be triggered (using a trigger or by touching it) rather than shot.

The bSelfDisplayed attribute specifies that the FortStandard is visible (using its mesh). This is typically turned off and the FortStandard is displayed with level geometry. The bFlashing attribute specifies that the FortStandard should flash when it is damaged. The bSayDestroyed attribute specifies that bots should announce when they have destroyed this FortStandard (turn this off if the FortStandard marks a strategic location, and not a visible objective). If the DestroyedMessage is not empty, it will be displayed on everyone's HUD when the FortStandard is destroyed. The DamageEvent[] and DamageEventThreshold[] arrays are used to specify events which occur when the FortStandard has incurred specific amounts of damage.

The ChargeDist and bForceRadius attributes are advanced AI tweaks used to determine how aggressively bots will go after a FortStandard, when they feel they don't have adequate backup.

One of the FortStandards in the level should have the DefenseTime attribute (the total time the base needs to be defended) set. Also, one FortStandard should have the EndCamTag attribute (the tag of the spectatorcam to use when the game ends).

The TeamCannon can be placed in Assault levels to support defenders. The MinigunCannon is a minigun version of the TeamCannon.

Every Assault level must have an AssaultInfo somewhere in it. The AssaultInfo contains the text (in the ObjDesc[] array) and screenshots (in the ObjShots[] array) which describe the objectives for the level. The NumObjShots should be se to the number of text/screenshot elements.

The AssaultRandomizer can be used to force bot attackers to vary their entry routes randomly. Place an AssaultRandomizer in a spot along the shortest path, making sure there are no connections around it along that path. Set the ToggledCost attribute to an appropriate value to increase the distance cost of that path. The use a trigger to toggle the AssaultRandomizer on and off as desired, causing the path to appear longer or shorter. Never use a negative value for the ToggledCost.
Of course, he forgot a plenty of things and lousy deals but... they can be investigated/mitigated later. Technically now days we have tools for doing what is needed and a lot of information which Discord members "have forgot" to deliver, including inspection if an original good stock map for figuring various spots:
- if doesn't work properly, you can see what is there - including logs are important;
- if it's a flawless spot - there is the "How To".

Automatically merged

This is a report about pathing state (Update 1 file) - it's shortened. Routes for items are not that important in CTF unless we talk about coverage and fire power.

Code: Select all

Origin: Process items from PlayerStart17 location.
...
ut_shieldbelt0: Searching route...
ut_shieldbelt0: Route Not Found from PlayerStart17...
HealthVial16: Searching route...
HealthVial16: Route Not Found from PlayerStart17...
HealthVial17: Searching route...
HealthVial17: Route Not Found from PlayerStart17...
etc..
WarheadLauncher0: Searching route...
WarheadLauncher0: Trying a closer actor for Marker...
WarheadLauncher0: Failed...
WarheadLauncher0: Route Not Found from PlayerStart17...
...
Origin: Process items from PlayerStart18 location.
ut_shieldbelt0: Searching route...
ut_shieldbelt0: Route Not Found from PlayerStart18...
...
Here is a count of 306 failures to reach at these which means that there are broken routes.

Automatically merged

If you want to see a minimal investigation, I'll be glad to show you even mystical paths which Editor is drawing but they are not updated in internal nodes lists and then... route goes broken and 98% of "Guru" types won't be able to explain in any way (bad english, good english, french, spanish, etc) what exactly is the problem, and how Goblin (aka UT Editor) does its best in creating fake news.
Mystical_Routes.png
Shortly, two connected nodes must have whatever number found in Paths for Start point and upStreamPaths from End point. In this case we talk about JumpSpot2 and LiftExit4. JumpSpot2 seems to have logic updated two connections to Exists, but LiftExit4 doesn't include in upStreamPaths any of the two Paths from JumpSpot2. As result Engine won't find a logic route to the overcrowded island and... I don't see any other arrow (Path/ReachSpec) pointing nearby ground to this island. These can be taken seldom in combat situations but not in a paths searching process.
By doing a simple test with some testing builders in basic format, there will be no flaws reported because nodes have logic paths but... not all required paths are placed inside them.
You do not have the required permissions to view the files attached to this post.

User avatar
LDinos
Novice
Posts: 15
Joined: Mon Aug 15, 2022 5:40 am

Re: CTF-SpaceX

Post by LDinos » Wed Sep 28, 2022 4:22 pm

sektor2111 wrote:
Wed Sep 28, 2022 4:15 pm
LDinos wrote:
Wed Sep 28, 2022 2:53 am
Special thanks to the discord community that helped me with pathfinding problems with bots
Useless in big parts, like I said xxxx times, the first thing to do in learning these is ORIGINAL docs written by POLGE himself and not some of those based on "let me guess". Such as...
OldDocs
Show
Wow! That was a nice read, it is indeed very helpful! Will definitely make more adjustments sooner or later

User avatar
sektor2111
Godlike
Posts: 6039
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: CTF-SpaceX

Post by sektor2111 » Wed Sep 28, 2022 4:46 pm

For completion I could do some "highlight" and quoting original text where the truth is more or less altered - probably this would be trolling document and probably disturbing, reality will go known after an amount of experience.
Just a sample: "gives level designers maximum control over how the AI navigates their levels" - as it was shown, it's about control not maximum control. When a clumsy script is thinking for mapper, it does what it was programed to do and not what mapper wanted. In addition, here are two combos for said island, definitely one of them for going back is useless for two reasons:
- first combo would be enough - these are two-way routes - if they would be completed normally with paths;
- secondary thing - there are already jumpy paths for leaving island having shorter ways during routing calculations - combos are natively set at 1000 UU and a Cost/ExtraCost, with other words they are "heavy" and used only when there is no alternate shorter option.

Edit: Credit time
I have to be grateful for pointing me a few things to take in account when my builder is inspecting paths and it will do some "CleanUp" task. Several things must be fixed and not just thrown away because... they are needed. In other terms, some of these lost paths that are created must be recovered when it comes to combos LE-JS-LE or such...

User avatar
EvilGrins
Godlike
Posts: 8973
Joined: Thu Jun 30, 2011 8:12 pm
Personal rank: God of Fudge
Location: Palo Alto, CA

Re: CTF-SpaceX

Post by EvilGrins » Thu Sep 29, 2022 1:49 am

Question (and I haven't tried this yet) but did you leave the same pathing from when it was DOM or did you update it for CTF?
http://unreal-games.livejournal.com/
Image
medor wrote:Replace Skaarj with EvilGrins :mrgreen:
Smilies · viewtopic.php?f=8&t=13758

User avatar
LDinos
Novice
Posts: 15
Joined: Mon Aug 15, 2022 5:40 am

Re: CTF-SpaceX

Post by LDinos » Thu Sep 29, 2022 1:59 am

EvilGrins wrote:
Thu Sep 29, 2022 1:49 am
Question (and I haven't tried this yet) but did you leave the same pathing from when it was DOM or did you update it for CTF?
I updated it a little with alternate paths and pickup changes, but generally they are mostly the same

User avatar
sektor2111
Godlike
Posts: 6039
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: CTF-SpaceX

Post by sektor2111 » Thu Sep 29, 2022 2:16 pm

Perhaps is visible that map has PathNodes without usage because they are lifted far from walking ground. BlueBase has valid access to Shieldbelt but for RedBase this is a bit doubtful and there is Armor2 not that effective as Shield or some Bot will get it if will find this on his way to Armor - it's in air.
The way to Big Health looks a hazard for returning. Paths that are used I'm not sure if they won't cause a failure and falling into Lava. As Entry Point there is probably recommended a TranslocStart instead of LiftExit - I did not study it in a game session, but such scenarios were proven sometimes buggers in other maps. Here it's about Path from TranslocDest4 to LiftExit2 - real length here is 1234.02 UU with chances to bump into ceiling and falling - with other words this "return" looks like a no return. This happens if by chance Bot can throw Translocator that far. For this sort of deal Editor has no fault - it's mapping fault. Editor can only fail in placing a bunch of useless PathNodes - thing forgot to be described in docs.