#Make 'Terrain high prediction time' look at set min/max altitudes

36 messages · Page 1 of 1 (latest)

spring flower
#

instead of just looking at obstacles or the sea.

  • would help with heavy craft that CAN fly low crashing into the sea cuz the AI doesn't bother to cancel there downwards thrust in hover movement until they've PASSED that minimum altitude.
  • would also help certain fast craft entering space cuz they dont take there velocity into account either and slingshot themselves way above there max altitude, then losing control cus there too high
  • would also help niche designs that may make use of weird AIs and min and max altitudes, overall being a more flexable system.

Currently. it seems the prediction time is only for collisions with craft, running aground if your a ship, or running into sealeevl or land for aircraft. While min and max altitudes only are considered when theyve been reached, not approached.

image.png
#

yesyes. "can be fixed with breadboard". But your either doing it quickly by just tossing in an extra drive to GO UP to slow you down sooner if your gonna hit the water. (which is kinda jank)
OR
your taking over the entire pid propulsion system already and none of the settings in this suggestion effect you anyway really.

its simple in principle (i have no idea how spaghetti the engines is so im not gonna comment on if its a simple game change) and would be a blanket improvement to core functionality. im struggling to think of how this could make any existing design worse as its merely adding prediction to limits crafts already have set.

flint verge
#

"doesn't bother to cancel there downwards thrust in hover movement until they've PASSED that minimum altitude." this is just wrong though

#

what the max and min altitude does is clamp ai waypoints

#

if your pids are set well it will anticipate movement as much as it needs to

spring flower
#

PID doesnt look in the phisical space of the craft?
it just goes off of input trends, Averaging with extra steps. So since this is a oneoff manouver there is no average, and having a weaker PID (more direct inputs) would help as it would reduce delay in getting to full thrust before smacking into the water.

the only thing that actually seems to 'look ahead' is the anti-collision stuff and waypoint seting. but the waypoints are correct here, and the craft can perform the waypoints fine. the issue is the AI isnt taking into account its a heavy fat craft and is putting into a very fast freefall for said craft with no way of knowing how fast it can arrest this frefall.

flint verge
#

no?

spring flower
#

im messing with PIDs right now and recreating the scenario over and over. nothing in this reacts until AFTER we pass the minimum altitude mark (aka: were at/below our waypoint). Its all reactive.

flint verge
#

thats not what a pid does

flint verge
#

this makes it predict where you are going to be in the future based on how you are moving right now

#

you can use that for things that need to react before passing the waypoint

spring flower
#

so derivitive is prediciton, and integral is... averaging/trim?
and gain is intensity of the input?

flint verge
#

yes

spring flower
#

follow up.... why the hell doesnt this just say that then?

image.png
flint verge
#

it does though

spring flower
#

in english

flint verge
#

it does though

spring flower
flint verge
spring flower
#

just saying
its allot of words and most of them dont mean squat to someone who likely clicks on that page looking for 'help'. And apparently i just explained it in under 20 and cleared up years of confusion. nearly clear enough for an ork to understand.

#

it has fixed my issue BTW (and thank you). but maybe should change the thread title to 'add a summery to the top of this help page'

quartz onyx
#

more words does not automatically mean harder to understand

#

it literally says it predicts the error

#

but that help page could use some rewriting

#

like hundredths of a second is way too low for Td

#

and PD controllers are only not recommended if your input is noisy, which is not the case with FtD movement PIDs

spring flower
# quartz onyx more words does not automatically mean harder to understand

the first line is the equation it works off. that really narrows down the base that'll understand, really fast.
it explains how everything works, but when i fist saw this when the better PID system was added, you think i had any idea what an 'error' was at the time? looking at it now i get the context abit (honestly, after posting this thread, was the first time in years ive looked at this page). i feel pretty comfortable in saying, most people are gonna look at that, and many more, help pages and just see words.

i get its something having knowledge in the right ballpark makes it clearer right away. but i feel allot of FTDs help pages that get abit technical could do with a 'for dummies' couple sentence explanation so everyone can get a rough idea of how to use things without guessing.

quartz onyx
#

the equation only contains addition, multiplication, and division. if that throws anyone off then either they didn't go to primary school or they have a mindset of math = instantly give up

#

and yeah the rest of it does use some technical language but the derivative term does have the word "predict" so you could guess off context clues that derivative is the prediction term

#

plus PIDs are very common elsewhere so you can look them up for a better explanation

#

yes I admit this help page isn't written very well but at the same time people give up way too fast

#

stop underestimating yourself and assuming you're too dumb to understand anything with numbers in it

sour gorge
#

bug report: oftd can't read