XC_Engine v25b for UTPatchV469b
- SC]-[WARTZ_{HoF}
- Site Admin
- Posts: 426
- Joined: Wed May 10, 2017 7:08 am
XC_Engine v25b for UTPatchV469b
Grab it HERE
Re: XC_Engine v25b for UTPatchV469b
XC_Engine 25b Aiming UT version 469b has an Editor extension for building paths. Here is embedded a similar feature with XCv21.
What is about ?
For creating paths stock Editor does a check around a Navigation Point for probing potential paths in 1000 UU range - this range is configurable in these XC assets.
However, if map is a bit overcrowded with nodes creating paths at 1000 UU or higher ranges, it will drive to a bunch of extra reachSpecs causing a lot of processing toward navigation. An ideal case would be finding the best value based on the biggest distance between two nearby nodes, such as Node 1 has 100 UU to Node 2. Node 2 has 300 UU distance to Node 3. Our option would be around 301-302 for preventing other longer paths as long as the best recommended paths scan range distance would be 300.
How to find this ideal scan distance case ?
Definitely looking at each two nodes means ages, eyes bleeding, headaches and so on... but Mr. MapGarbage builder Editor Add-On will scan nodes that are tracing each-other (potential routes) in stock 1000 range (perhaps this will be configurable) and finding the most far each-other two nodes for being connected, reducing the scan range and paths creating over this value and having connections all over the place.
By Example: This sort of operation in AS-HighSpeed recommends Path Scan Range somewhere at 603 UU. After using this option ( and deleting useless LiftCenter3, lol Epic ) the number of reachSpecs aka Paths are reduced from 1885 to 1580 because we won't have any more paths longer than 603 UU length. In other maps these can be reduced more.
Saying these here because it is about XC assets which are the only ones XCv21 XCv25b capable to deal with this RangeScan or ScanRange feature for mapping paths.
Edit: Task for this function will take some time because... there are maps with various "paths" (stock, of course) which might do some data which is not exactly the best ever values. Function shows some steps and node names which can be examined as long as their longer connection has additional routes and then... that long range can be forget, and so on until optimal value will cover everything properly.... Eh... heavy stuff...
What is about ?
For creating paths stock Editor does a check around a Navigation Point for probing potential paths in 1000 UU range - this range is configurable in these XC assets.
However, if map is a bit overcrowded with nodes creating paths at 1000 UU or higher ranges, it will drive to a bunch of extra reachSpecs causing a lot of processing toward navigation. An ideal case would be finding the best value based on the biggest distance between two nearby nodes, such as Node 1 has 100 UU to Node 2. Node 2 has 300 UU distance to Node 3. Our option would be around 301-302 for preventing other longer paths as long as the best recommended paths scan range distance would be 300.
How to find this ideal scan distance case ?
Definitely looking at each two nodes means ages, eyes bleeding, headaches and so on... but Mr. MapGarbage builder Editor Add-On will scan nodes that are tracing each-other (potential routes) in stock 1000 range (perhaps this will be configurable) and finding the most far each-other two nodes for being connected, reducing the scan range and paths creating over this value and having connections all over the place.
By Example: This sort of operation in AS-HighSpeed recommends Path Scan Range somewhere at 603 UU. After using this option ( and deleting useless LiftCenter3, lol Epic ) the number of reachSpecs aka Paths are reduced from 1885 to 1580 because we won't have any more paths longer than 603 UU length. In other maps these can be reduced more.
Saying these here because it is about XC assets which are the only ones XCv21 XCv25b capable to deal with this RangeScan or ScanRange feature for mapping paths.
Edit: Task for this function will take some time because... there are maps with various "paths" (stock, of course) which might do some data which is not exactly the best ever values. Function shows some steps and node names which can be examined as long as their longer connection has additional routes and then... that long range can be forget, and so on until optimal value will cover everything properly.... Eh... heavy stuff...
UncodeX Stuff
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -
Re: XC_Engine v25b for UTPatchV469b
I think there is a bug (pretty ugly one) concerning "AllReachSpecs" iterator - perhaps not fixed in v 25c.
Iterator finding Navigation Chain will start dealing with ReachSpecs - the thing to check it's a map with ONE single Navigation Actor added as "chain". Clearly it doesn't have links / ReachSpecs (a single Node has no external connections and neither with itself), there are no such data and then... iterator will crash whatever environment. This is why last XC_PathsWorker has a "pre-check" before calling this iterator which is attempting to show data from nothing. Clearly that was a lousy map "bug-free" as stated in its "read-me" file.
The rest of obscure bugs from DLL files are not known to me, it's clear that there could be more. CollisionGrid won't work properly with re-scaled Movers, these getting stuck like a normal wall. Disabling this "collision" stuff is mandatory if you want your server in a good state. A CRASH will restart server instead of trying to play a map that goes unusable.
Iterator finding Navigation Chain will start dealing with ReachSpecs - the thing to check it's a map with ONE single Navigation Actor added as "chain". Clearly it doesn't have links / ReachSpecs (a single Node has no external connections and neither with itself), there are no such data and then... iterator will crash whatever environment. This is why last XC_PathsWorker has a "pre-check" before calling this iterator which is attempting to show data from nothing. Clearly that was a lousy map "bug-free" as stated in its "read-me" file.
The rest of obscure bugs from DLL files are not known to me, it's clear that there could be more. CollisionGrid won't work properly with re-scaled Movers, these getting stuck like a normal wall. Disabling this "collision" stuff is mandatory if you want your server in a good state. A CRASH will restart server instead of trying to play a map that goes unusable.
UncodeX Stuff
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -
Not often maintained
My UT Mapping works...
Learn the rules like a pro, so you can break them like an artist.
- Pablo Picasso -