"NHL Rock The Rink" (PS1) announcer wrote:...And there are no stunt doubles in this game, folks!
papercoffee wrote:Ok... nice maps. I tested them with default weapons and NW3 weapons.
Bots work well in both.
I used MrLoathsome's bot order fix and Nelsona's bot-path randomiser.
Small map with only one very frontal way in. Yes the way splits up due to many obstacles but it's actually very straight forward.
The layout gets more interesting inside the bases, with a little Z-axis gameplay. But till you can even enter the base awaits you the opposing team right behind the doormat.
With two frontal entries are the chances very high that you get fragged in the moment you set foot in the enemy base.
What actually happened a lot. But with enough pressing you can make it into the base and better split up then to use the many ways to the flag to spread and weaken the opponents power.
One redundancy ...this boots are useless. If you try to use them you only bump into the ceiling and get smacked down.
Very open and wide map with a lot of Z-axis play. Some places look a little bit dull and the very long corridors are a feast for sniper/camper. But you have at least the opportunity to "sneak" around those sniper spots. All in all great gameplay in a very wide and sometimes dull map.
I have to test it with my RocketGib set up.
sektor2111 wrote:Notes here:
When updating a map after first public release, maybe changing name it's a MUST not an option. The rest of discussions about generic names which anyone can use do seems pointless, no one cares. A G00gle search usually can reveal if exist another map with similar name or crawling a public redirect. Malformed names also might lead to an UnPlayable map On-Line if you are not following URL naming rules.
Reason for having so many PathNodes in CTF-Rage][ map for me is pointless. In mean-time, paths done at less than 50 UU each-other in the same spot are a nonsense.
For now map do looks suitable for some game-play - if paths are completely rebuild in Run-Time. There are not needed 279 PathNodes here, map has InventorySpot actors, 59 AlternatePath actors..., helping Navigation Network.
sektor2111 wrote:and other dumb ideas like these based on IGNORANCE toward UT communities generally.
sektor2111 wrote:Here can be attached "_R18" or such with meaning is redone with editing technology a la 2018
Here I've forgot to mention CTF game which I'm practicing with aggressive translocations performed by Bots and such over-loaded maps are not only forcing engine toward Bot "Path-Seeking" Load, but it's way messy to get killed without even to breath in seconds. Team-Work it's not forbidden, anyone can ask help if has troubles with paths.sektor2111 wrote:Feed-Back for this last CTF map: I don't like paths here - like I said before, it's only a guess work, multiple points in the same spot are pointless. I don't want to go evil but by taking a look over some of those 300k mapping contest maps, anyone can figure how to do paths for a decent engine load and it won't hurt anything. If Bot is not moving for flag there can be ONE problem and not a need for more load. If a single point is not correctly done causing DevPath to not work, the other entire load it's just useless.
Team-Work it's not forbidden, anyone can ask help if has troubles with paths.
SkYlInE wrote:Team-Work it's not forbidden, anyone can ask help if has troubles with paths.
Tbh there is a question how to improve the bot paths. In this case (CTF-Schmall) what is to do that the bots will use the lower path? They use it sometimes when they are freelancing but not on attack Mode. Same for the sideways. Alternate paths didnt bring the effect i wanted to have.
papercoffee wrote:Bots won't use a path where they won't find something of interest ..or if the good stuff is too far away and means a detour.
sektor2111 wrote:Umm... not entirely agree. Sometimes a flag carrier might go out of battle zones with Flag in order to keep game advantage in last minutes.
Very quickly and not wishing to hijack the thread, the Gasbags are good as one can see right at the start-up of a map whether it is pathed or not (and whether or not any of the path nodes are movable).papercoffee wrote: Your randomiser irritates me every time those Gasbags pop up at the start of the map...but that fits better in another thread.
I don't know who was writing and what kind of tutorial, but I can quote a few notes written by the man responsable with this UT's A.I., Polge himself and not other sudden experts:SkYlInE wrote:i read something in a tutorial that pathnodes have to put in the same line where the weapons or other stuff lies that's why i put them to the nearest or to the same height.
Aside, I can complete a few things - undocumented hints about pathing which Polge never described for some reasons or whatever goofing specific to Epic.Polge wrote: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.
Note: UTPG "fixed" this On-Line debugging and here I mean they removed it rather than fixing it. In 451 can be used only in Stand-Alone games - Off-Line.Polge wrote: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.
Like I said, I'm using that only for certain DM maps not for everything because that mutator doesn't have eyes and not even for myself it's not a must have everywhere. In any potential future version I won't remove those temporary checkers (not gasbags) they are saying/testing which node is suitable for being mobile so are the main mutator core and I want them VISIBLE - feel free to modify it in another way.papercoffee wrote:Your randomiser irritates me every time those Gasbags pop up at the start of the map... but that fits better in another thread.
Users browsing this forum: Tyr and 4 guests