Page 1 of 1

An idea for forcing PathNode connections.

PostPosted: Wed Jan 16, 2019 1:06 am
by Gustavo6046
I was placing PathNodes in my map, and moved a single node very slightly, and decided not to rebuild paths, when I realized, I could be smart, and trick the engine into forcing a connection between two nodes, by moving one of them into a position reachable from the other, then moving it back into place without rebuilding.

My questions are,

  1. Is it possible?
  2. If so, was it done before?
  3. What are possible cases where this technique would be useful?
  4. Is there a way to make it automatic, so I don't have to move the forced path nodes back and forth every time I rebuild paths?

Thank you,

Re: An idea for forcing PathNode connections.

PostPosted: Wed Jan 16, 2019 3:00 am
by PrinceOfFunky
Gustavo6046 wrote:What are possible cases where this technique would be useful?.

If it works I guess it could be useful with narrow passages where pathnodes usually don't work.

Re: An idea for forcing PathNode connections.

PostPosted: Wed Jan 16, 2019 7:23 am
by sektor2111
Apology for a half Off-Topic, but speaking about whatever connections (not moved nodes here) this is what I could do in August 2015, some of links were not connected as I wanted but I still could figure operational routes to "RememberSpot" using "ShowPath" - I did not have "BotyMan3" tool in that time...
This is a defending position which works for sure:

Then others a bit more evil and working partially:

After this exercise, I could figure how to link "healthvials" in a DM-CoolBlue map version...

Re: An idea for forcing PathNode connections.

PostPosted: Thu Jan 17, 2019 10:02 pm
by Gustavo6046
That is very interesting, sektor! Indeed, if more people knew this trick, I'm pretty sure many maps would have a higher quality level in terms of pathing. Or we could just have an Editor plugin do this for us.

I don't think you need to stay completely on topic, either, as long as you manage to make the Editor build paths where it would usually refuse to.

Re: An idea for forcing PathNode connections.

PostPosted: Fri Jan 18, 2019 6:40 am
by sektor2111
There is a little story toward this map (another one was shared in that time too).
It was announced as usual in a forum where by default everyone said "woow". In a few minutes I could show a nasty BSP bug and again... a door used as Lift with no A.I. deal. A few hours later I fixed BSP and then I got drunk. Due to my mental state from next minutes I went ahead for mad pathing stunts but it's hard to recall every detail how I bugged Editor for doing these - I think I was about to kill that poor Scout pawn used. Some tweaks which I posted here and there are supposed "dumb posting" - that 90% of "gibberish-txt-sektor-walls" - but I know what paths have done others and who did trash. These devs have a simple logic toward their mode of operating. Whoever is understanding that logic and what Editor does, pathing map becomes a hobby.

As a note:
Sektor was posting 100% wrong stuff - it's about that "udemo" modification which is actually crashing (a map with Biterfish - stupid mapping as usual) and using a smilie like this > :D . Definitely a mod not enough tested, I simply deleted that, disappointed because I really wanted such a tool.
In exchange sektor2111 has evidences and tools done for testing and it's talking after X checks.

You can imagine that I won't post all junks which I have for testing. They are going hosted as "maps / mods" and poor admins will get mad trying to figure what's going on.

For paths: That route should not have a collision with any walls as primary goal - for slants it depends on angle. Path should not be at 80+ UU upper from ground - Bot case. Imagine path used as a defencepoint - pawn should be capable of sitting there, exceptions are in special situations where we need to motivate pawn to fall (jump into hole) combos and custom teleporters. Forgetting buried nodes is a good thing - nodes from ground are not a deal.
All paths which Editor does are based on some movement analysis and using a reference pawn (Scout) as Higor sampled in his devs ported in UScript. As for Scout evidence - in order to demonstrate more clear:
Code: Select all
// Scout used for path generation.
class Scout extends Pawn

function PreBeginPlay()
   Destroy(); //scouts shouldn't exist during play

Can you see first remark ? Can you see collision cylinder ? That's why paths for inventories nearby walls or small places do looks moved away. This Pawn is reference for InventorySpot placement and... it's automated, not like for PathNode case. I did a builder for probing spots before messing with 100+ Paths build, builder uses exactly this Scout for testing spots and it will report when a path might be a red one enough accurate. Flying paths are red anyway, btw, not done with UT Editor.
If inventory has generated a really bad Spot but it "MUST BE" there, don't force path in spot - add inventory AFTER building paths and excepting the nasty one or move it into void until paths are build. Inventories which cannot be touched by Scout (from void) won't generate paths.
Why InventorySpot ? These are DM targets for Bots and exactly here ENGINE decides location VIA Scout not entirely the mapper. Imagine now a... smaller Scout... :wink: .

Re: An idea for forcing PathNode connections.

PostPosted: Sun Mar 17, 2019 9:23 am
by sektor2111
Bump timer here.
As a matter of 2019 year facts, forcing PathNode connections can be done in a simple way.
As UT player/user if you don't like or XC_Engine is bugging you, you don't have to use it for game-play... But you can happily add XC_.... stuff in your modding version, as Editor extension like other builders, you'll gain a new image about paths, you will be able to connect Nodes as you like. Maybe XC document is not explaining in your favorite englitch, maybe you need more... colors...
Okay... switching to paint mode.
We have a path sample (not two paths) done by original Editor:

Let's say our pawns are able to jump on that box so we need some... connection which means in reality Two paths aka Two reachSpecs.
As explained in document we have to Use Event from Start as Tag for End which initially never existed.
Let's paint some strings:
Here we have to edit Both NavigationPoints as shown, in order to gain a connection from PlayerStart to the PathNode placed on the Box.
Then we have to remove old net - maybe even restarting Editor with a cleaned map and prepared with event(s) and tag(s) for using XC builder.
Builder button is shown where usual builders are located, map is cleaned and ready for dance.
After using XC Button...
What can be noticed here ? There is no forced connection here even if we have defined it previously, XC builder has decided that here is a jumpy path making it accordingly. To summarize, this builder is more powerful than original embedded in Editor. No new Scout has been used and no other commands.

And final point - there is not any "idea" for forcing connections, we do already have stuff for such things when connections should exist - even a superior paths building tool. Actually we can do such connections since XC_Engine v21. Visible paths feature and flight support is being added in V23.

Re: An idea for forcing PathNode connections.

PostPosted: Fri Apr 05, 2019 6:15 pm
by Gustavo6046
Really useful stuff!

Indeed, it would be possible to embed XC_Engine stuff into maps, depending on what needs the native DLLs and what doesn't.

DLLs aren't considered network Unreal packages, because it would be a massive vulnerability otherwise, to download and run malicious DLLs from a malicious Unreal server. This, however has the downside that good DLLs also can't be used in multiplayer unless all clients have them as well.

The issue of the engine's design is that, instead of focusing in making UnrealScript the most powerful as possible, by making it optimized enough such that moving (or at least making available, and modifiable to a certain extent) certain internal C++ procedures into UnrealScript doesn't make a significant impact on performance, Epic made many game-changing aspects, such as navigation, C++-only, and usually part of the Unreal executable (or retail DLLs), and thus assumed to be equal and to never change among network clients.

A much better, but also harder, fix, would be to sneakily replace small segments of the executable itself.

Assembly is simple when you look at it in small portions, or batches. And I'm pretty sure it is somehow possible to figure out where navigation-related functions are in Unreal executables; for example, if we know which instructions are run when NavigationPoint pathfinding functions are called, probably via UnrealScript code that intercepts those calls and transmits such data over to other programs (like a database) via TCP sockets, we would likely be able to narrow down the actual code that would need to be changed in order to modify navigation.

A possible change to be made to internal navigation machine code would be to open a local host only, listening TCP port among such code, so that even UnrealScript can connect to it and send commands or data that influence pathfinding, like a sort of local backdoor. This would be vulnerable to programs also running in local host, but that can be fixed by only accepting connections if they are encoded (via Diffie-Hellman) with a value that only UnrealScript code running in the same instance of Unreal would know.

But, right now, in the middle of this endless minuteness we call present time, all we have are ideas.

Re: An idea for forcing PathNode connections.

PostPosted: Fri Apr 05, 2019 8:56 pm
by sektor2111
Okay, let me tell you something - probably simple. Higor sampled how to setup a mutator to not have as dependencies XC assets but which can use them if are found.
I think in a map you can add such a bad-ass actor with no remoterole working only in servers and checking for any XC company - no client involved. If XC is found, this self-mapping actor can perform various stunts needed by server. Example: Map will look for a XC_MyMapper package. If it's found will be loaded and depleted in server - that's all.
But... there are not needed such stunts. Extra-paths are doable in Editor and map has full compatibility with plain Vanilla UT because ReachSpecs are recognized by Original Engine guiding pawns accordingly - no hacks are needed in run-time if map is mapped with XC. Here we can only speak about a poorly coded Editor which can be convinced to do more into a map by "XC advisor". XC will draw "hyper-paths" and Editor will save map - all players will play it with or without XC_Engine.
To not forget that Even with poorly coded Editor we can demand some connections - demonstrated at 512k mapping contest, and in Woot maps as well. We can only complain about other limitations, now days we have some machines which UE1 won't use at normal capacity due to those stupid hard-coded values... because a summary benchmark feature doesn't really exist inside Engine just a few lousy things for mapping Engine's functionality according to machine's power.

Re: An idea for forcing PathNode connections.

PostPosted: Sat Apr 06, 2019 1:25 pm
by Gustavo6046
sektor2111 wrote:<latest reply>

ReachSpecs are, indeed, internal features. However, if I recall correctly, they cap out at 32.
And I didn't really realize you were talking about an XC-boosted, yet backwards compatible, instance of the Unreal Editor, wow. Nice.

Anyway, I was thinking about a slightly different approach to navigation. Illustrations in progress.

We could use a navigation mesh, or set of convex planes. This is my approach to building one via UnrealScript:

1. Define the contour nodes of our navmesh. Every corner of a wall will have one. There probably is a way to place those automatically, from NavigationPoints; maybe one can use Trace from those outward (i.e. toward corners), and find a Trace distance for 8 or so directions, and only plop contour nodes where the two (or so) smallest of the Trace distances are both smaller than a set value. In this case, every new contour point should have a reference to its source NavigationPoint, the originator trace's direction, and the surface normal of the plane below (i.e. of the floor).

2. Once we have the contour nodes, we can begin splitting those into mesh polygons. First, we just assume the navmesh is basically a set of polygons, where each polygon is, in turn, formed by contour nodes that share a source NavigationPoint in common. Every polygon must store, as a variable, an average floor normal vector, i.e. the summation of all the contour nodes' floor surface normal vectors, divided by the number of contour nodes (and thus the number of summed vectors). We can call this vector the polygon's FNV.

3. Merge all polygon vertexes (i.e. contour nodes) that are close to each other. In case we decide that hypothetical contour nodes A and B are close enough to be merged: if A and B are part of the same polygon we just replace them by a single node, at the average of both nodes' locations (or, if there is no open space in that location, at A's location); otherwise, we just either move A and B to their median position, or move B to A, so either way they share the exact same location.

4. We begin to group up the polygons, into Coplanar Groups (CPGs). A CPG basically contains all polygons that:
  1. are contiguous to each other, i.e., are either directly(a) or indirectly(b) connected, and
  2. are coplanar to each other, i.e. have a similar enough Floor Normal Vector (FNV) to be grouped.
(a) Directly connected polygons are those who share at least two contour points, i.e., where there are at least two instances where a contour point from an hypothetical polygon A is close enough from an hypothetical polygon B.
(b) If the set of all considered polygons formed a graph, where every graph node A is connected to every graph node B if both the represented polygons are directly connected, indirectly connected polygons would be those between the which there is a traversal path in the graph, i.e., there is a way from and to both, even if through middle polygons.

5. Finally, we divide each CPG into a list of convex polygons, by triangulating the polygons that participate of a CPG. Ensure there are no obstacles between two contour nodes, and that bots can avoid obstacles in the middle of the CPG by detecting those and plopping FearSpot-like actors that trigger slight path deviation and thus dodging. All the resulting convex polygons, from all CPGs, are indexed into a single navigation mesh.

It is, of course, much easier to use an external program to do all of this, rather than rely on UnrealScript, which has a few limitations accessing map geometry.