Ever since the newest update any new grids I build that use this script take of and land at an angle. My old grids running this script all work fine. Not sure what's happened.

I just loaded your code into a programmable block and received this error:
184,28 Unreachable Code Detected
2481,0 Unreachable Code Detected

I just came across your script and I have a small grid. In your description you put a link for a script for small grid, (Passer-class Utility Shuttle). That link no longer works. Would you be willing to update the link or publish the script itself? TY

Hey, I know that this hasn't been updated for a looong time now, but I just stumbled over this script. Parts of it are broken now (unreachable code, some API-changes etc.) Is there any chance you might update this again? :O

Bah, silly me. I got the Remote group syntax wrong. The script works perfectly after correcting the error.

This is an excellent script, you deserve a lot more exposure.

Cool, cool. I added the option anyway, but I'll have to test it out before releasing it (and by default, it will continue to use all thrusters for alignment, so there shouldn't be any surprises).

And yeah, I think that's the reason why I set it up this way. In the upper atmo, ions are still somewhat useful... But, for example, if your power is on a budget, I suppose you'd want to restrict it to just hydrogen.

Thanks for the quick reply man, and i think you're right in that it's just the gps alignment that uses the ion thrusters (or rather, all thrusters). I'd have to load up the game and run it again and pay attention to know for sure, but being as i haven't payed attention to it at the end during actual braking, i'd say its safe to say its working as intended. My bad, i should've done a bit more lookin first.

That being said, i actually prefer to have ions help align it to gps as im sure most of the aligning needed is during the beginning of the drop phase (where ions are still useful). Either way, im happy w/ alignment using all. Thx again

Do you mean sideways & forward/reverse facing ions?

I've tested it a bit with my lander and it seems to behave as I expect it to. When it starts braking, it only uses hydrogen. Downward-facing ions are disabled, however sideways/forward/reverse ions (& atmo) thrusters are used to align over the GPS point. In fact, it will use all thrusters for alignment.

So the 2nd thruster-spec in "drop auto" is just for the braking thrusters.

If that's the problem, I can probably add a script option to apply the same thruster-spec to alignment thrusters as well. (I don't really want to add anymore arguments to the "drop auto" command.)

Sounds like a bug. But I'm not seeing anything obviously wrong in the code yet.

Does it behave correctly if you leave out the GPS coords?

Hey man, i've been using the gps guided landing portion of your script and i'm loving it! I spent quite a while trying to get my ship aligned with landing pad on earth while in space, manually. I figured i wouldn't have enough hydrogen to use your script but was completely wrong.

There is 1 thing i'd like to ask about: When using the "drop auto" argument; "drop auto 13 i 5000 h 3 gps gps gps" it activates the ion & hydro fine, but leaves ion ON for the braking. Is there a way thats already built into your script to have it disable ion once hydro is enabled?

Yeah that makes sense, thanks for clarifying that for me. I wouldn't really call it a "consequence" even, doesn't bother me any.

Yeah, pretty normal. It's a consequence of being a "one size fits all" script.

It could probably be tuned to be a lot smoother, but then it would be specific for that particular thrust/mass ratio.

The control over the thrusters is actually analog (0-100% override), but I suspect the tuning is very conservative. If you're familiar with PID controllers, that's what it uses...

TYVM for writing this and sharing.

Would just like to verify something if you dont mind.. Is it normal for when "launching" for the script to toggle thrusters to maintain speed rather than using a certain thrust override and adjusting as gravity changes? It's still saving hydrogen just like thrust overide would, i'm mainly just curious i guess.

So I ran further tests myself, only to realize I COMPLETELY missed the "1 second loop" tag for the involved timer block. The script worked perfectly on my end after correcting that error.

Landed perfectly and right on the GPS point. The command I used was "drop auto 0 iah 1000 iah 1 12345 12345 12345" where "12345" was the X,Y,Z of the GPS marker. I let it thrust laterally in space for a km or two before I made an inverted re-entry into the atmosphere. (Where it then righted itself.)

So it seems fine to me, even when using this large grid lander script on a small grid ship. So the problem may have been:

* Incorrect setup of reference point and/or timer block
* Interference from other scripts
* Interference from mods (I run mostly vanilla except for camera/glass transparency mods)

I found one of my prototype small grid landers and tested with that. It worked with takeoff and landing, even landing right on a GPS point.

Currently testing your ship. Takeoff looks fine. Did you set up the timer block correctly? Give it the correct name so it could be found?

Changes I've done so far:

* Changed all ownership to "Me"
* Found your remote, created a group around it called *MyLander*
* Shut off all but 1 prog block and 1 timer block
* Renamed timer block so it included "1 second loop" in the name
* Deleted all actions on that timer block, adding single action: run prog block
* Loaded this large grid lander script into that prog block. Edited reference variable to *MyLander*. Ran it.
* Verified the timer was looping

I issued a "launch start" and I'm currently 22km above the surface. I'll come back later and report after I attempt a GPS landing.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=902259383
Admittedly it's gone through drastic changes and uses the Ascend script in place. It used to have FOUR Large Atmos Thrusters pointing up, which may have contributed to it flying upwards in what was meant to be Descend Mode, so I wonder if the script failed to accomodate for those.

The VTVL module is exactly the same between the two. The difference between the two versions of the script are all the extra modules that are included.

The small grid version is basically my Drone/Utility Manager + the VTVL module + cruise control.

Though admittedly, I don't have any small ships that can break atmo, so it hasn't really been tested much there. All my small ships just do moon landings & takeoffs.

Do the other modules in the script work? Like cruise control? A pointer to your ship would help as well.

Also, yes, I got the reference remote orientation set correctly.

Are you going to publish your Small Grid version anytime soon? It seems this doesn't translate well 1:1 with Small Grid ships; mine end up FLYING into space when I attempt to land it with this script.

my ship crashed, and so did my game. Oh well.

"Orbit" doesn't touch the thrusters at all, only the gyros. You don't really need anything special (just inertia dampeners) to keep at a certain altitude... assuming you have enough thrust.

Have you customized the script in any way? Modified VTVLHELPER_ORBIT_DIRECTION? By default it will attempt to keep the bottom pointed toward the planet.

Not sure what would be going on in your case. Are you doing anything else? Cruise control?

I seem to have an issue where my ship when "orbit start" is ran just plumets downward and disables my upward thrusters. Is there a way to just have the orbit and not plumet downwards? Like I want the ship to maintain an orbit at the highest most part of the gravity well.

Yep. Lower the minimum speed, set an appropriate stopping elevation, and optionally supply landing coordinates. See the docs for more details.

seems really awesome, clould I use it for semi-automatic airdrops. so t will automatically land safely?

Who knew that such a simple API addition would enable many things.

Not only can the script touch down safely, it can touch down at a specific location on the planet .

I guess all that remains is some sort of autopilot while outside of the planet's gravity. But there's API limitations there...

Just a note, made a breaking change today and removed the gravity survey module (it's no longer needed).

Auto-drop has been reworked as well. See docs/change notes.

I haven't tested auto-drop at elevation 0, but if your ship can survive slamming into the ground at ~5 m/s, I guess it should be ok. ;)

The only thing I want is the alight-ship-to-gravity... could you, please, make that a separate script? I'd like it to work both with inertial dampeners on and with them off.

I'll have to try out your python builder later, sounds good, but I'm afraid that once I start, I'll end up making my ships so complicated via automation that when I take a break from the game I'll not remember any of it when I return :P

The only thing that I would love to see, is having all the feature guides in one place so it's easy to find and add to.

Wow, thank you very much for doing that so quickly! It works perfectly thank you. As does the gravity survey, thanks for the instructions.

For additional gratitude (as that's all I can offer) is it possible to have the script safely return the ship to a landing spot, the location captured with a similar method to the gsurvey commands? - I understand it has recently become possible to get the ship mass in the PB so it might be a little easier to calculate braking distance. - I appreciate this is probably well outside the scope of this script though so completely understand if it's not something you'd like to spend time on. Happy to help with testing if required :)

Hah, took like 10X longer testing the changes than actually making them. Anyway, the script will now "start" timer blocks named "Launch Done" and "Drop Done" at the appropriate times if they are found.

The timer block thing is something I've been meaning to add. I'll see if I can get to it sometime. I plan to add it to the end of the launch sequence and also the end of auto-braking.

For gravity survey, it's:

1. Put a block group named "GS Target" around an LCD or text panel (make sure PB & LCD/text panel have same ownership)
2. When on the planet somewhere, run PB with argument "gsurvey origin"
3. Move laterally along the surface of the planet, maybe like 500m-1km from where you took the origin point
4. Also move to the desired stopping altitude
5. Run PB with "gsurvey snapshot <whatever>" The <whatever> is just a friendly name to label the coordinates.

And that's it. The auto-drop command will use the coordinates from the first line. You can use "gsurvey up" and "gsurvey down" to scroll the lines if you surveyed multiple planets.

This is a really nice script, launching worked first time without any issues, as did re-entry. Unfortuantely I couldn't get a gravity survey to work so I couldn't try the auto-braking feature to work, do you have a guide of how to set things up for the gravity survey? - sorry if it is somewhere obvious and I have missed it.

Would it be at all possible to have the script trigger timer blocks when it reaches certain conditions? eg once a launch is complete trigger a timer block that can detatch some merge blocks and then initiate a re-entry command to bring a ship back to a planet - this would make this a fantastic tool for making re-usable rockets to ferry equipment into orbit.

Yup, you can start/trigger now the timer once it's all set up.

And yes, G menu -- drag prog block to your cockpit's toolbar, and set argument to "drop start". Also be sure to do it again for "drop stop"

And "drop auto" is only usable if you used the gsurvey commands first and have the coordinates written to a lcd/text panel.

All in all, I recommend testing in a creative world first... or checking out one of my landers for an example.

Hey so ocne I've done the timer and the prog block, do I start the timer? Additionally, once I want to do a drop do I add to the G menu the program block with run command drop auto?

No, my reverse thrust thing is currently only available on my warship script.

Most of my scripts that control your gyros and/or thrusters actually use trigger now as well. But they control their own timer blocks -- which is why they need to find the correct one by matching a string ("1 second loop") or sometimes, a group.

However, they only loop using "trigger now" as long as they need it. In that warship script, the only thing that needs trigger now are reverse thrust, the weapon sequencer, and cruise control. If none of those are active, it'll run using "start" on the timer block.

previous post continued...
I mentioned it to him and he is going to make the timer shut off after it spins you and then turn back on when you activate the spin via argument again so sim speed only tanks during the manuever and is normal the rest of the time. I however, would think that the script should be able to calculate the retrograde and turn to it rather than sense where it is all the way around the rotation and which requires constant running of the script. But I don't know what is available to the script and if it can just calculate it once and then excute or if it needs feedback...

Seems like your description for the show damage on huh is similar to what I use now. I will try it out and maybe loose that other script. I noticed your warship one also has retrograde breaking. I use flight assist for tthat but I will try yours. Is that feature in your ship manager, the one I currently use? Flight assist shuts off dampers turns the ship then turns them back on. It is super automatic and really nice. However his script reguires the timer to trigger now and start so that it is running every tick which makes it smoothly rotate the ship, if you remove the trigger now from the timer it overshoots and corrects which takes longer to get to retrograde. However, the timer alone running continuesly like that drops my sim speed to .7 from 1.0!!!

I'm not familiar with MMaster's version. I only use his LCD script.

But the damage control feature (which is also present in my Ship Manager) is unfortunately only documented in one place currently: my Warship manager script .

I don't know how much of an impact multiple scripts have on simspeed -- in my SP survival world, I have dozens of ships running scripts and it's usually a solid 1.0.

Lately, this isn't the case (thanks Keen!), but I think it's something else (conveyor network stuff). When I shut off all scripts, nothing improves.

But anyway, consolidating scripts saves prog blocks & timer blocks too, which is mainly why I do it.

I've been using your ship manager and solar alignment for fixed solar panels on my 3 million kg space only ship. I use the ship manager to close doors, manage oxygen, turn off vents and refinery balancer. I just noticed that this script does a damage on HUD type thing and that it is in the options for the ship manager but is not in the descriptin. Is this similar to MMaster's (I currently use)? If it is and all the features above are in this script I can do all that with 1 script rather than 3. That should help reduce cpu resources right and keep my simspeed high?