[1.12.3+] RealChute Parachute Systems v1.4.9.5 | 20/10/24

[Artemonim]

Hi!
RealShutes does not work with the "ScrapYard" mod, which allows you to use parts that have not been destroyed - it is impossible to apply stored parachutes to the rocket. I have already notified the author of SY, but he does not respond in his topic for at least a month. Perhaps you can do something on your side?

I also tested FAR, which (as I understand it) uses a modified version of RChute, and ScrapYard works with parachutes as it should. (I initially played in a FAR+RC bundle)

I also have You can reproduce it kit — you will need "Быстрое сохранение #.sfs"

Edited June 16, 2020 by Artemonim

[stupid_chris]

6 hours ago, Artemonim said:

Perhaps you can do something on your side?

First thing I'm noticing is the use of the stock chutes. They have an MM patch applied over them, and that might be what's conflicting. Try using the RealChute parts instead and see if that works. FAR's RealChute implementation also does not use an MM patch, so that would make sense why they work.

Otherwise, that does not sound like a RealChute issue, and I doubt I would be able to fix it locally, that's not in my code. Even if I was, as it has been mentioned in the previous pages of this thread and per the disclaimer in the OP, RealChute is not currently under development  Your best bet is to contact the scrapyard author

[Brigadier]

20 hours ago, stupid_chris said:

 Even if I was, as it has been mentioned in the previous pages of this thread and per the disclaimer in the OP, RealChute is not currently under development

I really feel for you.  How many times must you repeat the same mantra to prevent users from asking for "bug fixes" or altered functionality?  While that's a rhetorical question, I have to say thanks for a great mod (it's always worked for me ) and I'm sorry that supporting it has sucked the energy out of you.  I hope you're enjoying playing the game for the first time in years.  You deserve this time to appreciate the changes in the game.

[cordilon]

On 6/16/2020 at 8:36 AM, stupid_chris said:

I also want to note that you are still facing this bounding box issue, and that this very well might be affecting how fast the parachutes think they're moving underwater.

I can at least confirm that I've been having the "parachute has been destroyed due to aero forces and heat" problem exactly as described by @AxleGreaser for many years, without that bounding box issue.
Haven't really tested this on a clean install tbh, my game has been modded pretty heavily for quite some time, so I just assumed (lol here we go again..) it was some other mod causing it.
Yes I know, the mod is not in development anymore, but I'm weirdly glad that this is adressed after all

[stupid_chris]

8 minutes ago, cordilon said:

Yes I know, the mod is not in development anymore, but I'm weirdly glad that this is adressed after all

Unless I get steps so I can reproduce it and a full bug report with according logs, I can't really address it at all even if I find the time  Still haven't experienced it myself.

[cordilon]

8 hours ago, stupid_chris said:

Unless I get steps so I can reproduce it and a full bug report with according logs, I can't really address it at all even if I find the time  Still haven't experienced it myself.

Sorry, wrong choice of words... I meant, I'm glad someone brought it up at least.

[stupid_chris]

@AxleGreaser @cordilon I'm currently working with JPLRepo to fix the issue permanently, and most importantly, without hacks. Next RealChute update, which will come with the next minor patch, will hopefully have this fixed. Im still not sure how to reproduce it consistently, but I'm hoping fixing the problem at the source handles it for all cases!

[AxleGreaser]

I am working through my process of producing a development environment robust enough to produce mods. and highly robust reproducible bug reports.
Currently my setup does not pass my own quality control requirements for producing release level production code. And the failure for the things I have reported so far to be reproducible means I don't yet meet the external requirements either.

===============

So while I have ships that produce the bugs, and ways that I fly them (travelling sideways >autoCut speed when hitting the water means chutes dont cut and thermal event fail (yellow text) happens) that results in that thermal event bug, and logs. I don't have what I can definitively state cant be dismissed as hacks. I also have no idea why there is any problem at all reproducing that effect, or how idetifying the actual lines of code producing the effect (that I changed locally that fixed the effect) does not definitively define where/what it is. But as for me producing definitive reports. My machine has indeed had many local versions of RealChute compiled on it and only one is the original. I'm also finding it hard to work out what I could say more definitively and more explicitly that would allow someone to reproduce what I see than I have already.

When I get there with my production environment setup I will be in position to produce robust bug reports. With ships/craft and logs. And descriptions of how to fly them to produce the effects. Because sometimes just a craft file doesn't reproduce a bug you also have to fly it as described. (mainly in my case hands free, apart from staging)

but,  I take this as a sage warning to myself.

And don't get me wrong, I appreciate that. But developing something, and supporting something are wildly different. I don't mod for KSP anymore because supporting drained me right out of all the energy I had. I'm not going back there for the foreseeable future.
If you can produce me a solid bug report, you can drop it on the github repo's issues, and I'll take a crack at it if I have the time to spare, but I can't promise anything.

until I have worked through my processes, and have a robust development environment, I am taking heed of the above and making sure I dont get burned out before I even start.

On reading the above quote, I noted with some alarm, that I had stopped having fun playing the game at all while trying to deal with the chutes issue. So i have stopped doing that.
Following your lead, like you, I will get back to the issue when I have the time.

Currently I am having fun coding and setting up my development environment again.

==============

In the meantime: the best i have got is:

If you'd like to see chute "fail" due to a thermal event. (see some yellow writing)

Either modify the code so that the chutes groundstop check, also checks vertical speed is > -autocutspeed   (see code snippet below for the change i made in my local copy of realChutes)

(That is a change that I made: in order to try and make realchutes behave more like stock on splashdown (note it happens only in the last few physics ticks so it is very easy to blink and not see it. As mentioned, it becomes much more visually apparent when splashing down larger ships, as they "fall" further and explode more with real chutes than stock.)

or  (if that seems like a hack or something)

in an unmodified RealChute mod (without changing that line of code).  Make sure the ship has a sideways velocity > autocutspeed when it touches the water.

(This can happen in real game scenarios when parachuting planes into the water as they have motors running and may be trying to get close to something else already parachuted into the water and be moving sideways faster than the auto cut speed)
When that happens then, for me every time, the existing 10C thermal gradient between the chute and the water/air (this.Vessel.externalTemperature) 
(and the then the sudden huge change in this value  this.Vessel.convectiveCoefficient)
in the first physics tick after splashdown = true.

Results in >300C temp jump and the chute failing.

I have no idea why there is any difficulty replicating any of that or even observing that, as that is what the code says it will do.

A Change I made locally that Fixes GroundStop issue (chutes being cut, and then (unlike stock) and the craft dropped into the water, accelerating the last few meters from first contact until neutral bouancy)

 

 

 

 

Spoiler

// bolded is the code I added      

public bool GroundStop => this.vessel.LandedOrSplashed && this.vessel.horizontalSrfSpeed < this.cutSpeed && this.vessel.verticalSpeed > - this.cutSpeed;

But fixing that achieves nothing, as the thermal bug described below then happens every time. (instead of happening when moving sideways on splashdown)

====

The code below could perhaps be described as a hack, but given the desire for minimalist changes with least chance of side effects it seemed like a reasonable compromise. That change prevents the bug/misfeature of chutes failing on splashdown. It fixes the only aspect of the physics that matters to the game play: AKA excessive temp spikes in one physics tick. It also rather accurately simulates reality that once in the water the chutes are very rapidly the same temp as the water.
(it ignores as the current mod does, that the chutes are not actually visually in the water at that time)
And that one thing is certain and that that conduction and convection from the water wont heat the chute up a lot. This patch ensures that as a fact

These 4 line of code guarantees that while splashed the chutes cant heat up hotter than the water

Spoiler

           if (this.Vessel.checkSplashed())
            {
                this.chuteTemperature = Math.Min(this.chuteTemperature, this.Vessel.externalTemperature);
            }

those lines of code are in some sense a "hack" in exactly the same way the following existing in the mod lines of code are

Spoiler

            this.chuteTemperature = Math.Max(PhysicsGlobals.SpaceTemperature,
                this.chuteTemperature + ((this.convectiveFlux - emissiveFlux) * this.InvThermalMass * this.ConvectionArea * TimeWarp.fixedDeltaTime * 0.001));

those existing lines, prevent the chute from cooling colder than 4K(space temperature). There are i think conditions under which the rest of incomplete modelling of radiation physics could otherwise make the chutes cool to colder than 4K. The is the line of code prevents that unphysical reality from occurring. And it was in going along with that existing paradigm, of bounding things by known constraints, that I fashioned my patch to prevent overheating on splashdown.

All changes are what I would describe as minimalist and low risk, as they by inspection usually (in nearly all physics ticks (while flying with chutes open)) have absolutely no effect at all.

Both only occur when splashed or landed()
Travelling vertically downwards under those conditions is not situation that can reasonably persist for long. (see submarines... for an 'unreasonable' case.)
The temp limit code basically ensures chutes remain no warmer than the temp of the water they are immersed in. Which is the limit required that has an effect on game play. So in order to be minimalist its the only part of the thermal simulation that i fixed, as its the only one effecting gameplay. While I could devise a more complex computational analogue, it would not make any difference to game play, and would be harder to diagnose and debug. And have much more risk as patch to otherwise very stable code.

I commend my chnages to the aether.

 

Submarines.

Stock behavior

And unexplored (in detail by me) feature of Chutes in stock 1.9.1 is I have observed heavier than water craft parachute into the water and at least some chutes remain intact while the craft sank to the bottom at 0.9m/s. Attempting to reproduce that may be hard as on my test craft some stock chutes cut and some didn't. I am suspecting rotational velocity somehow counted in decided which stock chutes were cut. many tricksy experiments will be required to fully characterise what stock does, reproducibly. I am probably going to make (by maybe Christmas.. 202x.) make a flying merry go round with "stationary" chutes in the middle and moving ones on the spinning edge then fly and somehow land the thing with chutes deployed... and that is what it would take to 'reproducibly' test stock submarine like behaviors to get baseline to test realchutes on submarines with. So yeah, maybe after Christmas.
 

RealChute

Current real chute behaviours is that if any craft touches the water the chutes are either cut due to ground stop, or if moving sideways are failed due to thermal overheating. So realchute behavior isn't a thing for underwater ships at this time.

What the behavior of a real chute mod will be underwater is like all its other features entirely up to the author of the mod. All the behaviors described above could be simply defined as correct desired behavior.

On the subject of what correct even means:

Not behaving liked deadly rentry does or not having a coms black out during reentry are unphysical(realWorld) things but to make the game work for some people they just happen(in kerbal physics). There is no "right" there is only a fun immersive game or not.

Making the changes above to real chutes may lead to chutes remaining uncut and unfailed when underwater if the craft is flown with appropriate care.  AKA it may be much harder to reproduce stock underwater chutes that I have seen than the other easy things described so far.
Also: The concept of some kind of real world underwater "chute" does exist:  They are called   google:"sea anchor"  but realistic ones are nothing like parachutes in size.

Submarines are for me an unresolved issue. I don't parachute heavier than water craft into the ocean so in terms of the chutes I use it is a non issue for me.

But i flag is as possible problem with any fix of the above two issues.

 

Bottom line: my code on my machine works for me. I am having fun.

Sooner or later if the issue persists I expect I would produce craft that strongly tend to produce the bug I described the fixes for. And do so in an environment I can make it clear that was standard and not hacked or borked by the other stuff that i do: But to do that I will need to set up my production code environment.

============

The issues that happen inside the VAB with copy chutes to symmetry parts, is another level of hard for reproducibility.

It is not a thing, and likely will never be a thing where i can provide craft file as my experience is it is dynamic interface issue and that saving the craft tends to make it go away.

I did however provide screen shots of the chute info window showing what ought to be impossible outputs where the mass of a 70m chute was reported as much lower than it can possibly be, if the code inside was computing mass from area correctly all the time. I have produced step by step reproduction steps and cant possibly diagnose "doesn't happen for me". I have not found or fixed the problem in the code but do have interface based work arounds, so again i run into the trade off between having fun and it all becoming hard work.

When i become a much better C# programmer, mare familiar with the application framework structure of the VAB and its callbacks, and better at debugguing I might come back to this one day.

until then i will be following the sage advice above and making sure i keep having Fun and not frustration with what I choose to do.

 

 

 

 

 

 

 

 

[SpaceMoose]

First of all, thank you stupid_chris (and all contributors) for this mod!

Is there a temporary hack I can do to get RealChute to work with KSP 1.10? I can't revert my KSP back to 1.09 with my current save (not compatible), so I'm stuck with 1.10.  I have vessels enroute to Duna and Laythe with RealChute parts, so I have no way to land them without cheating. I should clarify that those vessels were launched before Steam auto-updated my KSP installation.

I've (re)learned my lesson about letting Steam auto-update my KSP installation in the middle of a campaign!

Worse case is that I rebuild my landers with stock parachutes and HyperEdit them to the same orbit/position as my old vessels. I can then transfer the crews and delete the old vessels as if they never existed.

Please note that is not a demand to update RealChute for KSP 1.10. I just want to know if there's a quick fix I can do myself to get it working again (I know this is possible with other mods).

[stupid_chris]

3 hours ago, SpaceMoose said:

Please note that is not a demand to update RealChute for KSP 1.10. I just want to know if there's a quick fix I can do myself to get it working again (I know this is possible with other mods).

Unless you know how to compile a mod, no. The mod is intentionally disabled on new versions, and cannot be reenabled without a recompile. 1.10.0 has a lot of issues as of right now, so I'm waiting off for the first patch before updating, especially since it'll bring me a fix I want to implement.

You can ask Steam to revert you back to 1.9, and you will most likely find backups of your save files in your saves folder that you can revert to, the game creates backups regularly.

[Virtualgenius]

I never upgrade straight away for this reason, the mod guys need at least a month before they release a new update anyway as they need to understand what broke it, thanks for letting us know whats going on @stupid_chris

[GHVG]

7 hours ago, stupid_chris said:

Unless you know how to compile a mod, no.

I tried to recompile it but it still doesn’t work. Compiling for 1.9 works just fine. 

Am I stupid or does the mod need more than just a recompiling to work with 1.1? Did you recompiled it for 1.1 just to see if it works or didn’t you bother since you’re waiting anyway?

[Krazeh]

12 hours ago, GHVG said:

Am I stupid or does the mod need more than just a recompiling to work with 1.1?

You need to edit 'CompatibilityChecker.cs' to allow it to run on 1.10. The needed change should be fairly obvious when you open up the file.

[Virtualgenius]

Guys just show a little patience release came out last week, all mod builders take a month to update there stuff so 9 times out of 10 if you play with mods wait a month and your good to go. Its always better to wait for an official update as the mod builders support there own releases. 

[SpaceMoose]

On 7/5/2020 at 1:11 AM, stupid_chris said:

Unless you know how to compile a mod, no. The mod is intentionally disabled on new versions, and cannot be reenabled without a recompile. 1.10.0 has a lot of issues as of right now, so I'm waiting off for the first patch before updating, especially since it'll bring me a fix I want to implement.

You can ask Steam to revert you back to 1.9, and you will most likely find backups of your save files in your saves folder that you can revert to, the game creates backups regularly.

Thanks for the quick response. Unfortunately, I built an elaborate Mun base while I was running 1.10 and can't revert back to an old KSP 1.9 save without losing my base. It's only after I built my base that I noticed the RealChute parts were broken.

It's no biggie.  I'll simply rebuild my Duna/Laythe landers with stock parachutes and will HyperEdit them to the same orbital parameters as my old landers. I'll then transfer the crews and delete the old landers as if they never existed.

Like I mentioned previously, I (re)learned my lesson about letting Steam auto-update my KSP installation!

Thanks again for all your work.

Edited July 6, 2020 by SpaceMoose

[Probus]

On 7/5/2020 at 8:14 PM, Virtualgenius said:

Guys just show a little patience release came out last week, all mod builders take a month to update there stuff so 9 times out of 10 if you play with mods wait a month and your good to go. Its always better to wait for an official update as the mod builders support there own releases. 

Does anyone remember which release had a patch come out for it like the day after? Was it 1.0 or maybe 1.1.0?

Edited July 7, 2020 by Probus

[TheDerpist]

Hey, Folks! Could someone be so kind to tell me how the "spare chutes" work please and thank you.

[stupid_chris]

9 hours ago, TheDerpist said:

Hey, Folks! Could someone be so kind to tell me how the "spare chutes" work please and thank you.

Left click to repack from EVA. Has to be a lvl1 engineer in career, you can modify it from the settings menu.

[Patriot9330]

has anyone figured out how to run RealChute in 1.10?

[IntoSpaceAgain]

14 hours ago, Patriot9330 said:

has anyone figured out how to run RealChute in 1.10?

This is what @stupid_chris said earlier on this page:

On 7/5/2020 at 5:11 AM, stupid_chris said:

Unless you know how to compile a mod, no. The mod is intentionally disabled on new versions, and cannot be reenabled without a recompile. 1.10.0 has a lot of issues as of right now, so I'm waiting off for the first patch before updating, especially since it'll bring me a fix I want to implement.

You can ask Steam to revert you back to 1.9, and you will most likely find backups of your save files in your saves folder that you can revert to, the game creates backups regularly.

 

[Michel Bartolone]

I know the 1.10.1 patch was just released yesterday, so this is not a "hey I want it now!", just setting my own expectations...first, did the fix you were expecting make it into the 1.10.1 patch? Second, (setting expectations because I don't know how much time you have to work on this) are we looking at a day, a week, a couple of weeks? a month? More?

[Joe.L]

I have installed the realism overhaul and I think it includes this mod with the pack. However, after learning that this mod is out of date at the moment, I tried to uninstall it only to find it's not actually in the gamedata folder or anywhere else in the KSP folders.

 

Does anyone know if there is another way of disabling this mod?

[stupid_chris]

8 hours ago, Michel Bartolone said:

I know the 1.10.1 patch was just released yesterday, so this is not a "hey I want it now!", just setting my own expectations...first, did the fix you were expecting make it into the 1.10.1 patch? Second, (setting expectations because I don't know how much time you have to work on this) are we looking at a day, a week, a couple of weeks? a month? More?

You can always track my progress from the GitHub activity. Short answer is no the fix didn't make it in, but I'll just do it myself, at least I know where to go to fix it.

5 hours ago, Joe.L said:

I have installed the realism overhaul and I think it includes this mod with the pack. However, after learning that this mod is out of date at the moment, I tried to uninstall it only to find it's not actually in the gamedata folder or anywhere else in the KSP folders.

 

Does anyone know if there is another way of disabling this mod?

RO is on 1.8, and this mod is compatible with 1.8 if you have the right version. If it's not in GameData, it's not installed. You may also be seeing the RealChute implementation done for FAR, which hotwires all stock parachutes with RealChute. You can't disable that, this is an integral part of FAR.

[stupid_chris]

Update is up, fixes a handful of bugs and a couple of QoL things

Changelog

August 1st 2020
-Recompiled for KSP 1.10.1
-Added DragCube handling for different sizes and when the cap is blown off
-Parachutes smoothly move towards the drag vector rather than instantly
-Parachutes now look for both horizontal and vertical velocities before cutting
-Fixed issue where parachutes would sometimes break due to aero forces underwater
-Compatibility back to KSP 1.8 has been enabled
-Legacy MM patches removed

Thanks for your patience with this one! Cheers 

[justn444]

Thanks for the update. I, along with the community, appreciate your hard work.