@SpringFoxy01 ah yes, Keen didn't want to support In-game scripts when they shipped, or on their public servers.
Your problem now sounds like a block ownership issue. Try owning everything.

And now I got the Problem of the script stating that there are no Gyros, thruster and LCD displays in the Group, but I tripple checked everything and there's defenetly a group called Aligner and it has Gyros, a remote control, trusters and even an LCD Display

Found it. Turns out I had to activate custom scripts in the advanced options

@SpringFoxy01 idk what you mean... try constructing a Programmable Block, in terminal select it and click its "Edit..." button. From the script editor, click "Browse..." iirc. If you subscribed to the script, it should be in that list.

Where can I find the script?

sorry I said 'light', I meant "textpanel', they work similarly in the script, lights get the chart's bg color

if you have multiple charts, these days it gets wonky for some reason. Try one at a time.

the general idea is your LCD must be in the Aligner group, and include the chart name or short name in the light's Title property iirc. You'd pretty much need to scan the script for Chart names for a complete list, but many are listed above. Try text mode, debug font, though it should set that up for you automatically..

Hi, thank you for the lovely script. I am having trouble getting my transparent LCD to show any data. Could you maybe advise?

it should be possible to splice code between the two scripts, mostly.

it could, in theory, but there's no code for that in this script. Full Control script has it. Maybe try that.

"It can effectively replace the vertical inertial dampeners on a ship"
how about the other axis?
I made a working platform that needs to hover in place when i exit the cockpit. Reduces speed to zero in all directions and then hovers.

Just to be clear, with deactivated i ment a mod complettly removed the functionality of interial dampeners on my current server. no way to reactivate them, instead i was looking for scripts that could do that on their own.

aforementioned checkbox is in the terminal for the cockpit block

when you sit in a cockpit, the game shows you a checkbox for 'inertial dampeners' and my script reads the state of that checkbox, which is the part that you'd need to modify, in case the server forces that checkbox off. Just search for "dampen" and you'll surely find it

ok

only cockpits in the configured terminal Group matter to the script

cockpit settings? i build a working platform with two cockpits, would that cause issues?

@kinngrimm in fact my script can do its own inertial damping, but currently it checks the cockpit setting and also it would need to disable the thrusting 'free' mode as @Into and I have been discussing, which disengages my script when it's 'aligned'

on the multziplayer server i am, interial dampners are deactivated complettly, would this script still work?

Have meant "maxdownwardvelocity=" by "descending". Two PB deal actually well with bounciness and dampen any oscillations. But even with one PB, if maxdownwardvelocity is triggered, then it overshoots dramatically - sometimes - and yeets me up into the sky. PID shouldn't be the issue.

it probably doesn't sum the horizontal and vertical thrust 100% correctly to deal with diagonally aligned cases perfectly. It's a tricky problem because some of the forces cancel and some don't. Would need to take into account the thrusters' relative strengths and such better than I could think to do.

The problem like I said is when it decides to shut the thrust off ('free' mode) so the solution would be to keep it from going into free mode, by eliminating that clause in the script, I mentioned it below. iirc when I tried this what you get instead is a very bouncy switch back and forth between wanting to thrust up and wanting to thrust down, that never quite settles down, but can be tuned to be very small, sort of like the problem you're wanting to solve, only ... different.

Solving both those problems would probably require both more engineering skill than I possess, and some fixes to the game itself, how it handles overrides.

That's what I did, only one has gyro control. But Thrust calculation if craft is not horizontally aligned seems to be off. If thrust is sufficient, a 45° shouldn't be an issue. Maybe my setup wasn't right, as I filled cargo to the brim for this test.

But if one PB or two, I have that weird issue that sometimes propels the craft upward, like it's not the PID, but it overshoots the thrust when descending, duno how to explain this. I think it's because I changed amt = 0f; to -1, but not sure about that. (like there are many values in Custom Data that can have an effect)

only one of them needs to be doing the angular Gravity Alignering part, just don't give the other one any gyros. I guess only one of the scripts would be controlling any given thrust, that still should work..

Yes, they do and totally freak out if both PB control the same thrusters, but splitting it up equally on both works. During first tests, not even bad. But it also comes with downsides. I've put front and back facing thrusters into the script, so I can tilt up and down without moving. With two PBs now, it can't do the calculation anymore to stabilize it when tilted. Any idea?

I hadn't thought of that... they may fight with each other over control of the overrides! I bet shutdown will be interesting. But if you have them controlling separate Groups of devices, it may work. Good luck!

....I am back... now trying to use two Programmables with this script and a slight offset, in the hope that any issues get canceled out. Which me luck.

I feel you. I've had plenty of frustrations myself. Wish I could improve the script. It's the best I could do. Sorry for your troubles.

I tried it. I rly tried it to make it work and every time I thought I got it right, it wasn't. I don't understand what is going up under the hood, but I've spent a lot of time working with this script and tbh it's still the best I could find, but nonetheless, I can't get a pleasant experience out of it. My goal was to be able to build my own auto dampeners and other fancy stuff like landing computers, hover gliding and so on, which is rly fun and in this regard is this script rly versatile. But it just doesn't like to work, either because I started messing around with the code, or because I don't understand how some values exactly work. So please, consider redoing it, fixing, extending or just making a full guide on how to work with it. I know how to use it, but every time I try to accomplish something specific it starts acting weird, and it just messes with me. It drives me mad. I think at this point I start to lose my mind.

Alright, it seems that it is working
what I did was

amt= 0 to amt= -2
________________________
else if (fraction <= .01) { // off. Tiny overrides cannot be achieved. Prevent builtin inertial dampening after game clips them to zero.
thrust.Enabled = true;

set from false to true
_________________________
thrustvelslop=0.1
thrustposslop=0.1

amt = -1.f might help because in OverrideThruster it checks if (fraction < 0) and just leaves thruster override enabled with value 0 instead of disabling it, which iirc what that does is the thruster isn't totally shut off in that case and will begin acting like it's not overridden or something and start thrusting due to auto-dampening or something, possibly counter to the direction vessel is trying to move in; it's been a long time. That whole snarl is just kludge upon kludge trying to work around buggy game systems.

oh sure, yeah the slop is important. it's similar to the angle clip and slop parameters. the clip zone is a zone within which it just doesn't correct (where the thrusters would be turned off) and is considered 'within range'. the slop is a buffer zone outside that where if it gets outside that zone, it corrects back to the clip boundary. Just a hack, really, to smooth out the correction. It was likely more important in the past when the correction worked differently. So just increasing either of those buffer zones would keep it from doing the correction jiggle so often. One idea is to set the clip and slop both to exactly zero, so that it hardly ever will switch to 'free' thrust

At 0:28 I propell myself up, to fall into the island of stability, it goes well for a few seconds and then starts glitching out again. At 1:04 I repeat it.
https://youtu.be/InrwXz-2dyw?si=gtEokkMAabSgtMl0

So I made the change at Line 1177 and set amt = 0f; to amt = -1f;
I am not quite sure yet if it helps, but it does something ...I suppose
also I am not so sure what
thrustvelslop=
thrustposslop=
do. It seems they have also some effect onto the stability, but couldn't figure out what it exactly does.

first argument is direction to thrust times the force required in Newtons, 2nd arg is the string to print to the chart

Program(999,60) Error: There is no argument given that corresponds to the required formal parameter 'worldN' of 'Program.Motion.ThrustVessel(Vector3, string)'

I have literary no idea of what I am doing. Sorry for being such a pain...

try disabling the call to NoMoveVessel() in Motion.ThrustVessel or maybe the one in AccelerateVessel

iirc it had something to do with originally being unable to know the precise mass of the vessel, so I was unable to get the ship to stop precisely back then, so giving control back to the game was the only way at that point to get the ship to totally stop. But we've had access to precise mass including cargo for some time now.

tbh I can't recall precisely why I chose not to leave them overridden all the time like this; it seems like something I tried at one point though, and arrived here because that didn't work. It's been years though. Getting foggy.

free means that it's disabled the overrides. Yeah this is my workaround for a game problem with overriding thrusters. I feel like I just don't have the control I need, I'd be better off making a real Mod.

The chart "Thrust" tells me that "thrusting: free" is causing the trouble, I guess that by simply adjusting PID I can't solve the issue. i-0.1 was temporarily solving the issue, by changing thrust behavior into a spring, which actually worked rly well and acted as a suspension, but only a short time as it started to glitch out, just after a short time.

nice, you're hauling ass but the script is holding the ship up nicely. Yeah I see what you mean, this is basically my stupid compensation for the inability to override a thruster to exactly zero without turning it off, what I do instead is just disable the overrides when the alignment is within tolerances, and no control inputs are happening that require thrust, giving ship control back to the game's built-in control system to let its velocity dampeners work, their dampening works better than mine anyway. But yeah I know what you mean about feeling when it switches. I can find that part of the script for you so you can try disabling it. Pretty sure it's either in Thrust or Hover module. There's several weird things about this script that are simply due to weird things in the underlying game or in-game programming API, things Keen never addresses.

there are charts for this sort of thing, see above. 'thrust' chart and the default one should both give some info. There's other charts. It's possible to make custom charts that respond to LCD names of your choice and display whatever variables you want to see. All the chart stuff used to work, idk lately.

https://youtu.be/J-RDCZbZvC8

I always end up with the same issue, every few seconds thrusters turn completely down for a split second and overcompensating, resulting into a constant jitter ...ngl. PID is rly hard to fine tune. Do you have maybe an LCD string that could help figure out what is causing the issue? Like a PID visualizer or something?

Just because stuff worked yesterday, doesn't mean it will work today... I think I might have been wrong about negative values. I assume this script is saving some calculations and changing stuff on the fly means that cause and effect can be misleading? Is there a way to reset any calculations, without reloading a save?

the integral control is supposed to be for handling unpredictable extra load. That's fine, but a little weird, since it would indicate that I got a sign backward somewhere in my PID code and hadn't noticed. Not too terribly surprising, I suppose.

It seems that alignlinearresponsei=-1 is smoothing out the vertical acceleration. Can this be, or is my intuition wrong? Didn't knew that negative values would even work

Odd. There have been quite a few wierdnesses about how the script gets initialized during load of a saved game. I never did fully trust the way they call script ctor before the world is finished loading.

The script does not check the Title of screens when loading a save. Only at the time of Title change

Yeah I still need to check out the new flat atmo thrusters more

Thank you for the quick response! I'll see how I get on. I'd love to build me an atmo carrier with some mining drones it releases

howevs if the 'attached' grids are too massive compared to the aligning grid, my script can't deal with it and eventually wigs out. My only consolation is that the game's built-in controller fares little better. Taking the offset attached mass into account complicates the calculations greatly. That's why the PID is so helpful.