Jump to content

[KSP v1.1.3] Stock Bug Fix Modules (Release v1.1.3b.1 - 10 Jul 16)


Claw

Recommended Posts

I just upgraded to a tier 2 pad (Played sandbox in 1.0.2 up until yesterday) and when I load a rocket onto the pad (admittedly a mod one, Tantares R7) I get constant smoke pouring out of the blastways and the "360º scattered landing smoke" on the top of the pad as soon as it loads (IE Engines aren't even firing). This continues until liftoff. Throttle does not affect it.

Could this be caused by the fix to keep rockets from getting stuck in the Launch Pad? :)

JlhK8fY.png

Edited by tg626
Link to comment
Share on other sites

Removed on purpose. It's controlled within the module itself now, so that I could enable it as a StockPlus feature.

ah i see, adds a gui slider in the VAB to set the speed, though that limits all gimbals to be the same 1-30 speed range

while i do like the gui slider, bigger gimbals seem like they should move slower than say ant sized ones

could the gui slider be kept, yet still have default/max values be given in cfg for the module?

Link to comment
Share on other sites

I just upgraded to a tier 2 pad (Played sandbox in 1.0.2 up until yesterday) and when I load a rocket onto the pad (admittedly a mod one, Tantares R7) I get constant smoke pouring out of the blastways and the "360º scattered landing smoke" on the top of the pad as soon as it loads (IE Engines aren't even firing). This continues until liftoff. Throttle does not affect it.

Could this be caused by the fix to keep rockets from getting stuck in the Launch Pad? :)

http://i.imgur.com/JlhK8fY.png

Just based on provided picture - throttle is set to zero, cant provide any thrust. Stabilizator clamps still holds your rocket firmly on the ground.

Have you actualy staged it at least once, or it was drop off or something so Launchpad stabilizator is still shown on the left in staging sequence ?

Also - personal expirience from other rocket design - you need to rais rocket slightly higher from the ground in VAB if you are not using launchpad stabilizators. Otherwise rocket engine can be spawned slightly trough launchpad, unable to provide any thrust. Maybe you have similar issue, try to raise rocket slightly before launching.

Link to comment
Share on other sites

Love your fixes. Thank you for the hard work.

You are very welcome! :D

Could this be caused by the fix to keep rockets from getting stuck in the Launch Pad? :)

Possibly, seeing as how it's happening on the Tier 2 launch pad...except that bug causes the rocket to stick, rather than having the smoke effects. Have you tried it on the Tier 3, to make sure it isn't a career problem?

Really, it looks like you might be having some mod interaction problems. Are you able to do any narrowing down to see what might be causing it? Two things that I can think in my mod that might be interacting would be the StickyLaunchPadFix and possibly the ModuleGimbalFix. They both fiddle with engines, and the SLPFix is connected to Tier 2 launch pad issues.

could the gui slider be kept, yet still have default/max values be given in cfg for the module?

Sure, I could do that. Although I don't know if I will spend the time to write individual baseline and maximum values for each engine, but I can put the mechanics in there to accept default and maximum values via .cfg. Quite frankly, I'm surprised to see how many people want the gimbal response time feature. :P

Cheers,

~Claw

Link to comment
Share on other sites

i don't mind the lack of premade cfg for default/max, i typically redo configs anyways as i do a fully custom install ^.^

what i was planning to do, is a simple curve, use MM to look up thrust, maybe play mass into it a bit (just so high TWR might be faster or slower)

30 speed for engines at 0 thrust, 20 speed at 100, 10 speed by 500, 1 speed by 3k thrust, script is easy enough heh

Link to comment
Share on other sites

Just based on provided picture - throttle is set to zero, cant provide any thrust. Stabilizator clamps still holds your rocket firmly on the ground.

Have you actualy staged it at least once, or it was drop off or something so Launchpad stabilizator is still shown on the left in staging sequence ?

I haven't gone near the spacebar, the engines aren't "on" yet... And the rocket is sitting on a FASA Redstone launch clamp.

... Are you able to do any narrowing down to see what might be causing it? ...

I'll have a go at it tomorrow and see if I can isolate it. I was more or less posting to see if it was a "known" issue.

EDIT: Had a chance tonight, and it is caused by Beale's "Tavio" engines on Tier 2, 3, and in Sandbox (maybe Tier 1 too, but I didn't test that.) Sorry for the false alarm.

Edited by tg626
Link to comment
Share on other sites

Version 1.0.2e.2. Added some additional fixes in ModuleProceduralFairingFix, which should help with fairings getting stuck on ships. There should be a small amount of time for jettisoned fairings to clear close in obstructions (very small)...and any fairings that do get stuck on ships will not cause problems saving. So you can now quicksave/quickload your way out of the fairings if needed.

Cheers,

~Claw

Link to comment
Share on other sites

Version 1.0.2e.3.

Apparently some Work in Progress code snuk into ModuleProceduralFairingFix. Which isn't a huge deal, except it causes excessive log spam (and lag). If you downloaded 1.0.2e.2, please redownload 1.0.2e.3.

Sorry for the inconvenience.

Cheers,

~Claw

Link to comment
Share on other sites

Version 1.0.2e.3.

Apparently some Work in Progress code snuk into ModuleProceduralFairingFix. Which isn't a huge deal, except it causes excessive log spam (and lag). If you downloaded 1.0.2e.2, please redownload 1.0.2e.3.

Sorry for the inconvenience.

Cheers,

~Claw

Yes, it was LAGGING a lot and spamming logs in debug. Seems fixed now.

Link to comment
Share on other sites

First, I'd like to thank you (again) for doing this work. It really makes a difference.

Is there any way you can have a cfg file which would override the "plusEnabled = false" you have defaulted in the ModuleGimbalFix?

In fact (this may be wishing a bit), since you have the plusEnabled in many of them, and they all get overridden every time a new version is released/installed, could you extend this to a way to specify the plusEnabled in a different file for all the modules?

For example, you recommended and supply a "StockPlusController.cfg" to live in the GameData folder, so that the overall plusActive setting would be retained. Would it be possible to extend this file for so that the plusEnabled setting be stored there instead of in the StockBugFixModules directories?

I'm not a MM expert, but would it be possible to specify a MM cfg which would override the setting in another MM cfg?

This isn't too important for me, other than the gimbal fix, but if others are disabling the plus for specific modules, I can see this being very useful.

Thanks

Edit: I think I just answered my question.

If I put the following into the GameData\StockPlusController.cfg file, I'm pretty sure this will work, I've asked the question in the modulemanager thread for confirmation:


STOCK_PLUS
{
plusActive = True
}


@PART
[*]:HAS[@MODULE[MGFix]]:Final
{
@MODULE[MGFix]
{
@plusEnabled = True
}
}

and obviously, you can do the same for anything else which has the plusenabled flag.

Hope this helps someone else

LGG

Edit: A better syntax was posted in the MM thread, so I updated it above

Edited by linuxgurugamer
Link to comment
Share on other sites

linux, alot of mods have issue like that, i took a few min to learn MM like you just did, and no more problems :D

eventually it grew into a custom install of every freakin file checked, but now i only ever update dll files heh easier

Link to comment
Share on other sites

So, no news on the auto-fairing disappearance bugs?

Well, I try not to do general debugging in this thread. I haven't had time to go back and research this bug for replication steps (which greatly speed up building a fix). It takes time to first replicate the problem, then poke around to see where the problem is. This is in my list. It's not quite something that stops gameplay like stuck fairings and non-functional brakes, but I understand that it's annoying.

First, I'd like to thank you (again) for doing this work. It really makes a difference.

Is there any way you can have a cfg file which would override the "plusEnabled = false" you have defaulted in the ModuleGimbalFix?

You are very welcome. :)

I appreciate your request/frustration. The mechanization with the .cfg files is something I've been struggling with, since some people like pure stock behavior, some don't care and will mod to the hilt, and others do things in between. Perhaps I will steal your syntax from above, and test it out/implement in the next major release. Seems safe enough, and I can pull all the StockPlus bits into one file.

Cheers,

~Claw

Link to comment
Share on other sites

I appreciate your request/frustration. The mechanization with the .cfg files is something I've been struggling with, since some people like pure stock behavior, some don't care and will mod to the hilt, and others do things in between. Perhaps I will steal your syntax from above, and test it out/implement in the next major release. Seems safe enough, and I can pull all the StockPlus bits into one file.

Cheers,

~Claw

Glad to help.

LGG

Link to comment
Share on other sites

Can you add a plugin that allows us to invert the direction a control-surface (like an aeleron or flap) moves (individual toggles for pitch, yaw, and roll)? That should allow us to manually fix the wiglet problem.

Link to comment
Share on other sites

First off, thanks Claw, these are some sorely needed fixes.

Second, I think the new PilotRSASFix module is causing some unintended consequences on gravity turns. Ships that could formerly lock to prograde all the way to orbit are now torquing high and flipping around 20km, and the reduced SAS clamping appears to be the culprit.

Link to comment
Share on other sites

Can you add a plugin that allows us to invert the direction a control-surface (like an aeleron or flap) moves (individual toggles for pitch, yaw, and roll)? That should allow us to manually fix the wiglet problem.

This is actually a pretty daunting task, which basically requires rewriting the control surface module itself. The stock module does the individual channels inside the code, and doesn't have any hooks to individually flip them. This means any "simple" plugin (that doesn't replace stock behavior) can only flip the response for all channels, or none.

Incidentally, flaps do have an invert function. But that only flips the flap functionality (which I assume isn't what you're referring to).

First off, thanks Claw, these are some sorely needed fixes.

Second, I think the new PilotRSASFix module is causing some unintended consequences on gravity turns. Ships that could formerly lock to prograde all the way to orbit are now torquing high and flipping around 20km, and the reduced SAS clamping appears to be the culprit.

You are very welcome. And I was concerned that this might occur. I did test with several larger rockets and they worked okay. This is that "I need help with more testing" part. So if you could provide a craft (if it's stock) or some pictures that would help me refine the code.

Cheers,

~Claw

Link to comment
Share on other sites

Hey Claw,

You're right that it's mostly been with smaller, 1.5m rockets. Here are three .craft files that drift high and flip (around 10K). This is when I turn to 80 degrees at either 500m or 1km and then lock prograde.

https://www.dropbox.com/s/vvksxfjs6q9ajjf/KEO%20Base%20Builder%20%28Hab%29.craft?dl=0

https://www.dropbox.com/s/9vsx2e6sdx90dxp/KSS%20Fancy%20Ferry.craft?dl=0

https://www.dropbox.com/s/nnnws2sbehl72wt/KSS%20Outer%20Ferry.craft?dl=0

Link to comment
Share on other sites

You are very welcome. And I was concerned that this might occur. I did test with several larger rockets and they worked okay. This is that "I need help with more testing" part. So if you could provide a craft (if it's stock) or some pictures that would help me refine the code.

If it's otherwise behaving, a small amount of integral action should prevent this occurring. The other option would be to reduce the scale factor slightly, 5 degrees of AoA is marginal stability wise for many rockets

If I read your code right, your fix is making the proportional response scale with error squared instead of linearly (p_res = [Kp * error/5] * error) so it has a very small amount of action close to the target, leading to a stable position a few degrees off the target vector inside the atmosphere (which isn't stable if inwards torque is always less than torque from lift/drag which is what's happening here). Integral action is how that offset gets reduced to zero (negating torque from lift/drag). To reduce overshoot, you can zero it until only the final ~5-10 degrees of error remain.

Edited by Crzyrndm
Link to comment
Share on other sites

Hey, I have a problem that might need to be fixed. I was making my base when I messed up docking a fuel tank (It was high enough but it was slanted), so I reloaded my quicksave, but when I did, the magnetic force on the docking ports was gone, and the docking ports acted as if they weren't even there at all, with no collision box. Help?

Link to comment
Share on other sites

You're right that it's mostly been with smaller, 1.5m rockets.

Awesome, thanks! I will check them out.

If it's otherwise behaving, a small amount of integral action should prevent this occurring.

Thanks for the tip. I'll give that a try.

I have wanted radial parachute spreading for so long! +rep

Excellent, I'm glad you like it. :) I still need to get off my lazy back side and implement spread for stack mounted chutes placed symmetrically.

Hey, I have a problem that might need to be fixed.

That sounds like a generic docking problem on the surface. Although you might also have some variant of one of the docking bugs. Have you tried backing the pieces away from each other and approaching again? You might also need to do a little save file editing to reset the port. You can check out this thread and see if it helps: http://forum.kerbalspaceprogram.com/threads/78863-FIX-Dock-Undocking-Bug-in-0-23-5

Cheers,

~Claw

Link to comment
Share on other sites

This is actually a pretty daunting task, which basically requires rewriting the control surface module itself. The stock module does the individual channels inside the code, and doesn't have any hooks to individually flip them. This means any "simple" plugin (that doesn't replace stock behavior) can only flip the response for all channels, or none.

Incidentally, flaps do have an invert function. But that only flips the flap functionality (which I assume isn't what you're referring to).

Cheers,

~Claw

Oh, well, if you can, I would very much appreciate that specific plugin.

Link to comment
Share on other sites

Here is something that bugs me about the stock game.....

When you retract a ladder or the DTS-M1 or 88-88 antenna, they still seem to have all their drag and vulnerability to reentry heat. Would it be possible to have retracting such parts work like retracting landing gear, reducing their drag and making them reasonably heat-tolerant?

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...