Buggie wrote: ↑
Sat May 08, 2021 10:35 am
If I add to level PathNodes which not even in NP chain, then paths can stop work.
Finding paths is based on NavigationPointlist, like more things from UT. However, they said that some of these "variables" are constants
- which is plain stupid, so to speak this chain would be configured only at C++ Level - I don't get what was their problem anyway. I demonstrated since 2020 that this chain can be linked/unlinked/rebuild/edited in UScript without having any issue and even creating new connections with server-side C++ support, applying patches dependent on run-time factors (gravity, game-speed, etc) - because in Editor physics are not the same as in run-time and you might have more capabilities in run-time or adjusting these. But... if these are constants with any matter and we must stay in this stage 100 years, we can say good night Development and Creativity and we can rest in amoeba stage living with only what Editor does for reasons having zero logic.
Sometimes I'm sitting down talking to myself:
- they say about updating D3D drivers, OpenGL drivers;
- they talk about updating Audio drivers;
- they speak about changing default UTConsole;
- they are telling things about new game browsers;
- they pointed new demo-record drivers;
- they are pointing all sort of 'updates'...
BUT nobody and 'absolutly' nobody is talking about a replacement/enhancement of DevPath drivers which for me looks hilarious in all the way. Either way these 'constants' should be passed with new compiling support for a bit more advanced developers - nobody talks about these
We must stay original for future 'automated amoeba builds'. I never knew that a map it's not done for being played perfectly as main purpose, properly tuned, but it's done for being edited in "fixed" versions, like this is the master purpose of a map not for run-time and for game-play. An Automated Script will never be winner in a competition with human sensors, and trying harder to make hard-coded primitive things to work to me doesn't make any sense.
From my poorly math and physics knowledge, when you have a rat-hole, don't try to push a cow inside, otherwise you'll get some results as follows: 1 - Cow will die pressurized; 2 - Wall will get broken destroying poor rat's house; 3 - Your arms might get broken trying to push the cow with external support pushing you.
When these devs are not working beyond their boundaries you have to change boundaries or forget what you want. Due to my primitive math experience, I decided to no longer use maps over 3000 specs because This Is what Engine has and not 12000 or 800000, or anything like that I as can see here and there through forum and it's called 'mapping'. By simply following UE1 rules without going over any boundary I got a ++ at stability and I'm not joking.
Several DevPath Notes of mine:
- A Node for navigation purpose must be in chain;
- reachspecs are not only in Paths array, they need to be in upStreamPaths in other side, delete all upstreampaths in a simple map and see what you get;
- finding something is based on a valid closer node and another valid closer node around seeker - if they are empty of specs data, no path will even be found - it's advisable that blind nodes to be HIGHER located from the ground base level;
- in a big space - common big uni-zoned maps, things are going almost nowhere - can work partially or they won't work at all - 800 entry range it's no longer 800 for some space reasons - remember that Skaarj problem which had to be moved, there weren't 800 UU, but lesser;
- I suspect that it might be a plus in performance if these are wrapped in certain order (search order maybe...) and not in steps triggering more internal cycles. It's why manual control and random specs placement might not be the best practice but it's heading to other advantages. I'm for these advantages.