Things around old DM-Giza (03-Jan-2000)

[sektor2111]

This has come behind a duplicated map-name which was shown/posted recently. The already done map is probably more suitable as a

Title : Giza Lava Pyramid (can't think of anything good...)

Here we do have a bit of a deathmatch stage (I played it a few times - OFF-Line), we can discard the story from the same "readme":

Known Bugs : None
...
...
If you put it on a server, it'd be appreciated if you email me... I'd love to play
it with real people.

If it comes to such a stage I think we can have things improved as long as "Known Bugs" is DistanceLightning used here (not None) which ON-Line it's the mostly a flickering crap... as it was even in the year of factoring said map. The rest is something like this - taken from MapGarbage report...

Code: Select all

UnReachableNodes: Here we have 1 points skipped, 23 Navigation Points which are too high and 267 good ones.
...
NoIncomingPath: PathNode99 is not having incoming connections.
...
...
NoIncomingPath: PathNode169 is not having incoming connections.
BreakPointsFound: These 23 navigation points aren't that used as valid paths. They might be break points if are a piece of a road.
...
WrongPoint: translocdest0 doesn't have a private LiftTag string defined, which is pretty wrong.
BorkedStrings: This might not have connections or... it can be connected through walls with Exits if they exist.
WrongPoint: translocdest1 doesn't have a private LiftTag string defined, which is pretty wrong.
WrongPoint: JumpSpot0 doesn't have a private LiftTag string defined, which is pretty wrong.
WrongPoint: JumpSpot1 doesn't have a private LiftTag string defined, which is pretty wrong.
WrongPoint: JumpSpot2 doesn't have a private LiftTag string defined, which is pretty wrong.
WrongPoint: JumpSpot3 doesn't have a private LiftTag string defined, which is pretty wrong.
WrongPoint: JumpSpot4 doesn't have a private LiftTag string defined, which is pretty wrong.
FlawedCombos: This map has 7 messed up Combos, you need to check settings...
...
DupesScanResult: Checked 630 actors. Found 3 duplicates.
...
SpawnRotationResults: 2 Playerstart actors might need another rotation.
...
VoidCheck: Light74 looks placed into void.
VoidCheck: Light79 looks placed into void.
VoidCheck: 2 actors look placed into void, check those.
...
ZoningChecker: ZoneInfo0 and LavaZone0 share the same zone //By chance map is not a full Lava zone - lol
...
UTStockJunksDetected: Map is not really great in Network play with DistanceLightning actors.
LEVELVALIDATE: Validation done...

The rest of activity can be figured more or less in Run-Time - I don't have ammo for ShockRifle (for some reason ). Several Textures are not aligned a little bit, some spot has an ugly shadow which I don't understand, and it might be more than that.
Teleporters of class VisibleTeleporters are only generating fake copies in clients - they are not held as they are.
Discarding these (now days very) KNOWN Bugs that are "!= None", perhaps if map is being played in original (with all embedded Pawns) we can have random ShockCore actors known as ammunition for the two ShockRifle-s used, not adding them somewhere in order to allow original aspect and an improved clone of original map (using a scripted solution with random character).

The question is if a better version of this original map would be welcomed, perhaps is not the best ever design and it doesn't worth attention or it would be welcomed. I'm listening what you think.

PS:_____
I think in MapGarbage for a bit of paths purification concerning useless nodes closer to inventories, method for detecting junks can be changed in future, perhaps more suitable hunting ReachSpecs distances concerning an InventorySpot vs another Navigation Node - if we do have longer paths In-Out for these nodes, we can drop out those that are closer for no purpose - or maybe it doesn't worth changing strategy...

[papercoffee]

what the ...what is this map?

[sektor2111]

Medium size (for me this is how does it looks like), a pyramid, some items, top Udamage, Lava for free-fallers... and such...

[papercoffee]

I had a similar map... That's why I ask.

[sektor2111]

Here are some... "spots"... where I demanded connections for certain items (PulseAmmo, etc) where High-Skilled Bots enhanced by SmartStockBots (whatever) are capable to do some stunts. In other hand, low skilled ones and low game difficulty perhaps are not suitable here. The self question is if is needed some management toward these jump conditions for preventing A.I. to look stupid, like trying to do what they cannot do. For the rest... no complains, I cannot expect great things in years 2000, however some of these are better than some of 2023 products...

[sektor2111]

I've been playing here...

DM-Giza_rS904.7z

(315.88 KiB) Downloaded 4 times

Editing chapter was as follows:
- Removing duplicated actors;
- Tinkering a bit lightning (some shadow was way too ugly);
- Adding some networking support for DistanceLightning (which is ZERO at net codes...);
- Using some birds for whoever uses all Pawns embedded (map doesn't have ShockCores for combo masters so it's a way to gain these...);
- deleted useless space taken by actors (old Location, Tags for those that are not a subject for run-time, nulled data from red brush);
- pathing stuff: Deleting stupid navigation combos because they weren't having anything logic, deleted extra-nodes that are not needed, optimizing network using XCV24 and the "worker" for cutting trash out, creating some other paths manually, cleaned all junk data, wrapped Navigation Chain with Inventories first and PlayerStarts as lasts - attempting to speed up routing calculations.

[OjitroC]

Interestingly MapGarbage reports that about 30 pathnodes are too close to inventory items (and it removes those pathnodes) - which raises the question that if the location of those 30 odd pathnodes in relation to inventory is OK in this map then the same may apply in other maps - should MapGarbage simply delete pathnodes deemed too close or should it report them and ask if they should be removed?

One limitation with the map appears to me to be that Players (at least my Player model) are unable to walk up the faces of the pyramid (except for the lowest one) - which means that one has to go to the top and then go down to get the weapons placed on the horizontal areas of the pyramid - this, of course, has an impact on the nature of gameplay which may or may not be desirable (not all the area of the map that appears available for play is actually available in practical terms).

[sektor2111]

Interestingly MapGarbage reports that about 30 pathnodes are too close to inventory items

This is not plain pathing with Editor, XC has another sort of methods which won't loop like Goblin does, the other ramp issue it's up on what Bots (skill) is used. Things are done this way, yes, some people won't figure nice things with low skilled Bot - those paths can be removed.
In terms with Pathing formula, if you will delete so called "closer paths", MapGarbage will trigger Editor to redo paths and then... certain jumps are no longer added destroying routes which were created manually. If something evil occurs in game I can disconnect only offending spot because Editor won't fix anything. When network has manual control, it's not like it needs any fix with MapGarbage, this one cannot read manual customizations is just a template check related to what Editor does in overcrowded spots - it's not the case here - and Editor did not do anything here, it's all external stuff and wider paths.
More than that, actor "JumpAdjust" delegated to remove jumps in Classic difficulty will get screwed if InventorySpot linked is removed by rebuilding paths. It's not like adjusting paths here with Editor is a good idea, it will do damage. Custom paths will not get fixed by Editor - that's why they have to be solved in the same way - manually.

If it comes to human player - me one I could dodge up to ShockRifle Spots getting those without any sort of help.

In other hand, if you point me where access must be removed, I'll create a plain version without those paths.

[OjitroC]

This is not plain pathing with Editor, XC has another sort of methods which won't loop like Goblin does, the other ramp issue it's up on what Bots (skill) is used. Things are done this way, yes, some people won't figure nice things with low skilled Bot - those paths can be removed.
In terms with Pathing formula, if you will delete so called "closer paths", MapGarbage will trigger Editor to redo paths and then... certain jumps are no longer added destroying routes which were created manually. If something evil occurs in game I can disconnect only offending spot because Editor won't fix anything. When network has manual control, it's not like it needs any fix with MapGarbage, this one cannot read manual customizations is just a template check related to what Editor does - and Editor dd not do anything here, it's all external stuff and wider paths.
More than that, actor "JumpAdjust" delegated to remove jumps in Classic difficulty will get screwed if InventorySpot linked is removed by rebuilding paths. It's not like adjusting paths here with Editor is a good idea, it will do damage. Custom paths will not get fixed by Editor - that's why they have to be solved in the same way - manually.

That's what I am getting at - we may run MapGarbage on another map that also has had custom paths done manually - it may report that there are pathnodes 'too close' to inventoryspots and so may remove them. We have no means of knowing whether pathing has been done expertly with custom paths or not - perhaps MapGarbage should not automatically remove pathnodes in that case? Rather it should ask whether we want to remove those nodes?

Perhaps you need to create an actor to place in maps that you have expertly pathed that prevents the pathing being altered or issues an alert (if, indeed, such a thing is possible)?

[sektor2111]

No need too much science. When Editor does paths that need inspected, there can be seen a lot of links. When these are having less links, it's not like they need anything automated. I specified already that paths were operated using external assets - these won't do more headaches.

You can figure if something was done different by using a copy of map, reconstructing paths and figuring differences between the two paths networks. If are different, then map was not mapped with Editor.

As a different way of speaking, XC_PathsWorker can fix any sort of issue if you ask me - more or less automated.
Edit:By example, here are removed those 4 ReachSpecs that are triggering "ramp assault" - from 900 to 903. "JumpAdjust" will print some log here...

DM-Giza_rS900NJ.7z

(315.7 KiB) Downloaded 2 times

In other hand I might do in future a Texture and a KeyPoint where in Editor at opening map can be read "CheckThisInfo" or such, and said keypoint can have a Text with a few explanations toward executions operated, or a sort of portal where manual control is pointed at user.
_____
Edit2:Here I did some images for pointing what I'm talking about.
Here is an optimized stage where option "bTryFixbadPaths" is pointless and won't fix anything... it's a bad idea to "fix" these paths.

____
And this is original stage that might need a CleanUp - this is where MapGarbage should do some flush - if possible. Don't tell me that paths are the same as above - here is the same "View-Spot" with the same Nodes and the same items, only Paths were created a la Goblin...

And then it's not like using builder aiming Plain editing is suitable in custom stages. Here can be clearly seen differences between an optimized work, bug-free, and plain Editing. MapGarbage helps a bit in plain stage. In other instances it's not like you want to screw up the custom work.

The other hint.
Even if you are using plain editing, certain maps might have original paths but operated over Mover-Bridges / Secret Floors. Here is the stage where the guy "editing map" will ruin everything if he is suddenly pressing this (re-)build button

DoNotPush.PNG (515 Bytes) Viewed 124 times

Such "editing" methods won't help anyone who don't know what's up with map.