Jump to content

[1.0] XT Landertron - Smart Retrorockets for Landers and Spaceplanes v0.08 Oct 10


XanderTek

Recommended Posts

Good news! I've figured out what the problems are and how to fix them.

The issue with soft-landing was that they weren't properly calculating their own Isp (with the stockalike atmosphere curve I patched them to have, they were getting stuck at 0.001 seconds), which was causing them to severely underestimate their actual delta-V, thrust, required firing distance, and everything. That's fixed now.

The giving-up short-landing rockets are caused by jitter, I think. They stop firing if the current velocity is greater than the one from the previous frame. The intent is that this detects when the ship has come to a stop and begun to accelerate backwards., but landing with a bit of a bounce can also trip that condition. I've added some tolerance to stop that from happening further. It works in testing with the Aeris 3A, but I worry that it may be somewhat sensitive to TWR, so be careful.

I've put up the DLL as a release, but if you grab the GameData folder from the repo itself, I've made some changes to the part configs and such that I'm happy to let XanderTek package up and release. In particular, the parts have had their Isp and thermal properties rebalanced to be in line with stock parts and gotten some scale-factor updates to work well with KIS.

Finally, if anyone knows a way to tell if we're in the SPH or VAB, that would be great -- since the scene names are the same now ("GameScenes.EDITOR"), the code defaults everything to be in short-landing mode, even though I would probably rather use soft-landing mode if I'm building something in the VAB. That's the only outstanding issue that comes to mind.

I wondered if this would work with real fuels? It changes the engine module a lot so I don't know if the plugin would work natively. either way thanks for fixing the problems I will be using it either way too cool of a way to land not to!

Link to comment
Share on other sites

I wondered if this would work with real fuels? It changes the engine module a lot so I don't know if the plugin would work natively. either way thanks for fixing the problems I will be using it either way too cool of a way to land not to!

Internally, it looks specifically for solid fuel (and has SolidFuel's density programmed in as a magic number), but otherwise it just piggybacks on the engine module. Since the landertron parts are self-contained, they'll work fine unless RealFuels runs around and patches any mention of "SolidFuel" into APCP or whatever.

I'm not keen on modifying this module too extensively (certainly not while XanderTek's away), but I imagine that it could be made to run on whatever PROPELLANTs the engine has (so that it could be applied to other sorts of rocket engines, not just SRBs). That said, the soft-landing mode does do some throttle manipulation that the realistic engine mods might not accommodate.

Also, I did some testing and found that I could detect the symmetry mode of the editor (looking at Editor Extensions), but because that can be modified (e.g. by Editor Extensions...), I don't want to use that as a basis for automatic mode selection. I might see about modifying the module so that its mode can be changed in-flight, just in case the user gets it wrong or forgets to check in the editor.

Link to comment
Share on other sites

Internally, it looks specifically for solid fuel (and has SolidFuel's density programmed in as a magic number), but otherwise it just piggybacks on the engine module. Since the landertron parts are self-contained, they'll work fine unless RealFuels runs around and patches any mention of "SolidFuel" into APCP or whatever.

I'm not keen on modifying this module too extensively (certainly not while XanderTek's away), but I imagine that it could be made to run on whatever PROPELLANTs the engine has (so that it could be applied to other sorts of rocket engines, not just SRBs). That said, the soft-landing mode does do some throttle manipulation that the realistic engine mods might not accommodate.

Also, I did some testing and found that I could detect the symmetry mode of the editor (looking at Editor Extensions), but because that can be modified (e.g. by Editor Extensions...), I don't want to use that as a basis for automatic mode selection. I might see about modifying the module so that its mode can be changed in-flight, just in case the user gets it wrong or forgets to check in the editor.

It does aim to replace SolidFuel with the real world fuels namely HTPB, HNIW, PBAN, NGNC, PSPC. Of those only HNIW and HTPB I would think would be likely to be used in a SRM like these, but I have no real idea. From the community resouce pack ehre is the stats on the available fuels. Remember these are 1L units as opposed to kerbals ~5L units I think. I assume you have SolidFuel's stats readily available. Now looking there are all really close to stock density is the calculate robust enough to make up the difference? Realfuels does multiply all quantity/voolume of SolidFuel/RF equivalent by the appropriate factor to get the same delta V with SRMs despite RF units being L and therefore less dense. However you want to handle it is fine. This is modding a mod for a mod and I don't expect it to be a priority if is only for me I only ask if you want. Thanks once again for even getting it working with 1.0.


RESOURCE_DEFINITION
{
name = HTPB
density = 0.00177
unitCost = 1.8585
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/HTPB
}
RESOURCE_DEFINITION
{
name = NGNC
density = 0.0016
unitCost = 0.01
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/NGNC
}
RESOURCE_DEFINITION
{
name = PBAN
density = 0.001772
unitCost = 1.593
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/PBAN
}
RESOURCE_DEFINITION
{
name = HNIW
density = 0.002044
unitCost = 0.4504976
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/HNIW
}
RESOURCE_DEFINITION
{
name = PSPC
density = 0.00174
unitCost = 0.01
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/PSPC
}

Edited by Svm420
Link to comment
Share on other sites

It does aim to replace SolidFuel with the real world fuels namely HTPB, HNIW, PBAN, NGNC, PSPC. Of those only HNIW and HTPB I would think would be likely to be used in a SRM like these, but I have no real idea. From the community resouce pack ehre is the stats on the available fuels. Remember these are 1L units as opposed to kerbals ~5L units I think. I assume you have SolidFuel's stats readily available. Now looking there are all really close to stock density is the calculate robust enough to make up the difference? Realfuels does multiply all quantity/voolume of SolidFuel/RF equivalent by the appropriate factor to get the same delta V with SRMs despite RF units being L and therefore less dense. However you want to handle it is fine. This is modding a mod for a mod and I don't expect it to be a priority if is only for me I only ask if you want. Thanks once again for even getting it working with 1.0.


RESOURCE_DEFINITION
{
name = HTPB
density = 0.00177
unitCost = 1.8585
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/HTPB
}
RESOURCE_DEFINITION
{
name = NGNC
density = 0.0016
unitCost = 0.01
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/NGNC
}
RESOURCE_DEFINITION
{
name = PBAN
density = 0.001772
unitCost = 1.593
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/PBAN
}
RESOURCE_DEFINITION
{
name = HNIW
density = 0.002044
unitCost = 0.4504976
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/HNIW
}
RESOURCE_DEFINITION
{
name = PSPC
density = 0.00174
unitCost = 0.01
hsp = 920 // FIXME, total guess but based on 'standardized' solids and the stock SolidFuel hsp.
flowMode = NO_FLOW
transfer = NONE
isTweakable = True
ksparpicon = RealFuels/Resources/ARPIcons/PSPC
}

Looks like RF patches SolidFuel's density into 1L units, and it's 0.00178, very similar to HTPB.

However, it is my understanding that engines are not altered unless a specific config for them is made, and it doesn't look like Stockalike RF Engine Configs has any patches for XT Landertrons, so they should work just fine as-is. (In fact, in the patches that it does have, it looks like it leaves SRBs running on SolidFuel rather than converting them to anything else.) If I'm reading the patches correctly, RealFuels will adjust the amounts in the hexcan or boosters themselves to get to 1L units, but since they'll all get adjusted by the same factor, refilling should still work as normal. Looks like I don't really need to do anything -- but I think it would be better if a landertron used whatever fuel its engine module runs on, so I'll see about making a new branch with that functionality...eventually.

Link to comment
Share on other sites

Well right now you are correct it would still use SF, but that won't last the goal is to convert all SF over to a RF fuelz so I am asking more for future proofing. Plus I made the change to my personal game, just haven't shared the config to the repo. I appreciate your time and effort. I will go back to solidfuel for these SRMs I'd rather have function there and when the time comes I can easily go back.

Link to comment
Share on other sites

Does the mod depend on stock aero? I tried them with RF and FAR. I switched them back to SF and they just fire as soon as they are armed or staged. I guess I will try with just the stock engine module and see.

Link to comment
Share on other sites

It shouldn't depend on aero, but I've just recalled that the landertron code looks specifically for a "ModuleEngines", so it won't control a ModuleEnginesRF (or ModuleEnginesFX, which is a shame, since everything's switching over to ModuleEnginesFX now). Controlling a ModuleEnginesFX shouldn't be too hard, since it does all the same things as a ModuleEngines, but ModuleEnginesRF has extra conditions on igniton and throttle that may not play nice with the landertron. I'll add this to the "0.10" feature pile and see where it goes.

Edited by Kerbas_ad_astra
Link to comment
Share on other sites

It shouldn't depend on aero, but I've just recalled that the landertron code looks specifically for a "ModuleEngines", so it won't control a ModuleEnginesRF (or ModuleEnginesFX, which is a shame, since everything's switching over to ModuleEnginesFX now). Controlling a ModuleEnginesFX shouldn't be too hard, since it does all the same things as a ModuleEngines, but ModuleEnginesRF has extra conditions on igniton and throttle that may not play nice with the landertron. I'll add this to the "0.10" feature pile and see where it goes.

Thanks for the heads up!

Link to comment
Share on other sites

  • 1 month later...
Good news! I've figured out what the problems are and how to fix them.

The issue with soft-landing was that they weren't properly calculating their own Isp (with the stockalike atmosphere curve I patched them to have, they were getting stuck at 0.001 seconds), which was causing them to severely underestimate their actual delta-V, thrust, required firing distance, and everything. That's fixed now.

The giving-up short-landing rockets are caused by jitter, I think. They stop firing if the current velocity is greater than the one from the previous frame. The intent is that this detects when the ship has come to a stop and begun to accelerate backwards., but landing with a bit of a bounce can also trip that condition. I've added some tolerance to stop that from happening further. It works in testing with the Aeris 3A, but I worry that it may be somewhat sensitive to TWR, so be careful.

I've put up the DLL as a release, but if you grab the GameData folder from the repo itself, I've made some changes to the part configs and such that I'm happy to let XanderTek package up and release. In particular, the parts have had their Isp and thermal properties rebalanced to be in line with stock parts and gotten some scale-factor updates to work well with KIS.

Finally, if anyone knows a way to tell if we're in the SPH or VAB, that would be great -- since the scene names are the same now ("GameScenes.EDITOR"), the code defaults everything to be in short-landing mode, even though I would probably rather use soft-landing mode if I'm building something in the VAB. That's the only outstanding issue that comes to mind.

I downloaded your dll and parts from github but ksp gets stuck on the loading screen on XT-L2B and this shows in my log

PartLoader: Compiling Part 'XanderTek/Landertron/XT-L2B/XTL2B'

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

FormatException: Unknown char: -

at System.Double.Parse (System.String s, NumberStyles style, IFormatProvider provider) [0x00000] in <filename unknown>:0

at System.Single.Parse (System.String s) [0x00000] in <filename unknown>:0

at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0

at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at PartLoader.GetDatabaseConfig (.Part p) [0x00000] in <filename unknown>:0

at PartLoader.GetDatabaseConfig (.Part p, System.String nodeName) [0x00000] in <filename unknown>:0

at DragCubeSystem.LoadDragCubes (.Part p) [0x00000] in <filename unknown>:0

at Part+.MoveNext () [0x00000] in <filename unknown>:0

ksp 1.0.4

output.log

Thanks

Link to comment
Share on other sites

I see I made a typo in that config -- it has a double-minus-sign in the "fx_exhaustSparks_flameout" line of the config. You can either grab a fixed file from the repo, or fix it yourself on your own copy. Sorry!

(That's what I get for editing files line-by-line instead of copying over the known-good files from my game installs.)

Link to comment
Share on other sites

  • 4 weeks later...

Hi.

I wanted to use this mod and since I noticed that it's not quite bug-less and the code is rather messy I went ahead and just rewrote it from scratch.

Since I achieved the level of functionality that I'm happy with I decided to share it with you, do what you please with that code.

Here's the packaged mod and code:

https://github.com/charfa/XTLandertron/releases/tag/v0.10.0-alpha

My version has some breaking changes compared to the original, so make sure to read through the release notes, especially if you already use Landertrons in existing vessels.

I will implement bug fixes and feature requests if you report any, but only for a short time. Don't expect me to do any long term maintenance of this mod.

Regards,

charfa

Link to comment
Share on other sites

Hi.

I wanted to use this mod and since I noticed that it's not quite bug-less and the code is rather messy I went ahead and just rewrote it from scratch.

Since I achieved the level of functionality that I'm happy with I decided to share it with you, do what you please with that code.

Here's the packaged mod and code:

https://github.com/charfa/XTLandertron/releases/tag/v0.10.0-alpha

My version has some breaking changes compared to the original, so make sure to read through the release notes, especially if you already use Landertrons in existing vessels.

I will implement bug fixes and feature requests if you report any, but only for a short time. Don't expect me to do any long term maintenance of this mod.

Regards,

charfa

Thanks for the update (and for putting some more experienced eyes than mine on the code)! I'll take it for a spin and see how things go, but one request: convert the textures to DDS. (I'm happy to do it myself and make a pull request. I'll leave the TGAs in a source folder in that case.)

Link to comment
Share on other sites

I'll take it for a spin and see how things go

Cool, let me know if you find any issues.

one request: convert the textures to DDS. (I'm happy to do it myself and make a pull request. I'll leave the TGAs in a source folder in that case.)

I know next to nothing about models and textures, so it would be great if you could do that.

Link to comment
Share on other sites

I wanted to use this mod and since I noticed that it's not quite bug-less and the code is rather messy I went ahead and just rewrote it from scratch.

Since I achieved the level of functionality that I'm happy with I decided to share it with you, do what you please with that code.

I haven't played KSP since 0.90 and this is one of the mods I missed the most. I'll give it a try too. Thanks.

Link to comment
Share on other sites

  • 2 weeks later...
Thanks for the overhaul; I've missed this guy :D

I wonder, does anyone have the ancient version, with the temporary welded parts still? Oddly enough, I rather liked them... I wasn't able to find them in my old downloads, although it just occurs to me to check my laptop. It used to have enough "go" for Ksp, modded even! ( dem were the days, heh)

Thanks again!
Link to comment
Share on other sites

(Thanks for the DDS conversion -- glad you got it sorted, sorry to be out of touch on this point.)

It works in 1.0.5 (though I compiled the source code from the "master", rather than grabbing the 0.10 beta release), but I did get bitten by a user-interface issue. The enable/disable staging button shows an action rather than a state (i.e. when the button reads "Disable Staging", it's actually [I]en[/I]abled, and clicking the button will disable it and make the text read "Enable Staging"). This is not usually a problem because a pure decoupler will only appear in the staging list if it is enabled, but the landertron will be in the staging list no matter what, since it has an arming action, so I got confused. Just leave it alone, as the default setting is fine.
Link to comment
Share on other sites

Thanks for the heads up. I'm waiting for other mods before I switch to 1.0.5 and I've missed this.

I was looking for a way to disable that switch, since it's confusing, and I got really #^%#$^@#$ at SQUAD. They just introduced a very nice method of controlling which modules can be staged or not via switches in part.cfg (stagingEnabled, stagingToggleEnabledEditor, stagingToggleEnabledFlight) and then in ModuleDecouple they override and hardcode those settings... Why would you do that‽ Now I can't disable that switch by setting stagingToggleEnabledEditor=false.

BTW. Kerbas, in case you are going to grab the new part cfg files from repo, you'll notice that that switch now by default reads "Decoupler: Enable Staging". Again, the default is correct: the decoupler module is not staged, only the landertron module is.
Link to comment
Share on other sites

Ok, I found a way to hide that Enable/Disable staging switch.

New release: https://github.com/charfa/XTLandertron/releases/tag/v0.11.0

Bug fixes:
Fix "Look rotation viewing vector is zero" log spam.
Turn off decoupler Enable/Disable Staging switch

Internal:
Compile for KSP 1.0.5
Switch to use 'stagingEnabled' to prevent engine and decoupler from activating upon staging.

Edited by charfa
Fix link (broken BBcode)
Link to comment
Share on other sites

  • 1 month later...

Charfa, considering that you removed the throttling and there's a chance we end up stopping above the ground, is there any chance you add a feature to let us choose the target height instead of assuming zero all the time? That was a feature in the original, it was removed but I've always missed it, for the possibility of stopping a few meters above the ground and landing with airbags, Pathfinder/Spirit/Opportunity style. It's an interesting alternative to LFO+Mechjeb for getting a soft touchdown.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...