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

[Murdabenne]

Never said it was required.  I did say the the more widespread apps tend to do this to help each other.  Throwing in a config flag for a widely used app would be a plus for this app - not every user has mastered the modmanager configuration stuff. And that's for the author to decide. Not some bystander trying to prevent others from suggesting this as an improvement. Thats one thing I never understood about internet forums = why people act like suggesting a change is an insult.  Its not.  Its a suggestion, and common practice.  No need to get all defensive and try to shoot down such things.

Edited August 1, 2016 by Murdabenne

[Starwaster]

6 hours ago, Commissar said:

would it be possible to add an autocut delay option... i.e. delay the chutes cut at landing by a few seconds... useful for long craft that land on one end and then fall down... intentionally.

would look into it myself.. but i don't know c#... just some java

I'm sure it would be technically possible but have you tried experimenting with the autocut speed? Try lowering  below its default. The scenario you describe sounds like it could still have enough velocity not to trigger autocut if it's low enough. 

3 hours ago, Murdabenne said:

Never said it was required.  I did say the the more widespread apps tend to do this to help each other.  Throwing in a config flag for a widely used app would be a plus for this app - not every user has mastered the modmanager configuration stuff. And that's for the author to decide. Not some bystander trying to prevent others from suggesting this as an improvement. Thats one thing I never understood about internet forums = why people act like suggesting a change is an insult.  Its not.  Its a suggestion, and common practice.  No need to get all defensive and try to shoot down such things.

1. The suggestion you made has been made already and discussed in this topic nearly two years ago. I think it's safe to say the author has decided not to implement that or other patches dealing with third party plugins.
2. Both Phineas and I contribute enough to these forums and to KSP players to be more than just 'some bystander'
3. It's ok for other people on these forums to disagree with you and you should get used to that and not take it personally. Nobody here has acted as though you are insulting them. You should try taking your own advice in your last several sentences.

Edited August 1, 2016 by Starwaster

[Pappystein]

On 8/1/2016 at 2:55 AM, Starwaster said:

I'm sure it would be technically possible but have you tried experimenting with the autocut speed? Try lowering  below its default. The scenario you describe sounds like it could still have enough velocity not to trigger autocut if it's low enough. 

1. The suggestion you made has been made already and discussed in this topic nearly two years ago. I think it's safe to say the author has decided not to implement that or other patches dealing with third party plugins.
2. Both Phineas and I contribute enough to these forums and to KSP players to be more than just 'some bystander'
3. It's ok for other people on these forums to disagree with you and you should get used to that and not take it personally. Nobody here has acted as though you are insulting them. You should try taking your own advice in your last several sentences.

@Starwaster I have tried this with my own games and gave up.   Mind you this was pre 113 (1.05 and 1,1,1)  As soon as the rocket touches down had has zero VERTICAL speed the chutes cut, I have Diazo's Vertical Velocity control installed and can clearly see the Vertical speed is 0m/s at time of cut and then as the rocket falls I still see 0m/s on the display.   But my Rockets are still moving as they tip over.   It appears that KSP is reporting the Vertical velocity of the LOWEST part to Real Chute or atleast Diazo's VVC. 

Since I don't routinely land large rockets with chutes it wasn't a big enough issue for me (Staged Recovery to the Rescue.)  Maybe I am missing some key piece of functionality here but there seems to be several related stay deployed on ground issues currently.   EG I can not perform the primary RealChute Contracts (Test xxx Chute landed/Splashed down at Kerbin.)      But Like I said that could be a known "Feature" or by Design and I just don't know about it.

[Starwaster]

4 hours ago, Pappystein said:

@Starwaster I have tried this with my own games and gave up.   Mind you this was pre 113 (1.05 and 1,1,1)  As soon as the rocket touches down had has zero VERTICAL speed the chutes cut, I have Diazo's Vertical Velocity control installed and can clearly see the Vertical speed is 0m/s at time of cut and then as the rocket falls I still see 0m/s on the display.   But my Rockets are still moving as they tip over.   It appears that KSP is reporting the Vertical velocity of the LOWEST part to Real Chute or atleast Diazo's VVC. 

Since I don't routinely land large rockets with chutes it wasn't a big enough issue for me (Staged Recovery to the Rescue.)  Maybe I am missing some key piece of functionality here but there seems to be several related stay deployed on ground issues currently.   EG I can not perform the primary RealChute Contracts (Test xxx Chute landed/Splashed down at Kerbin.)      But Like I said that could be a known "Feature" or by Design and I just don't know about it.

It actually uses the vessel's horizontal speed + landed state. (has to be landed or splashed)

The autocut speed is configurable in the editor and can be set as low as 0.01 m/s

As far as issues go with staying deployed on the ground, stupid_chris has said flat out they aren't meant to stay deployed on the ground (or at least not once it's below its autocut speed)

[Murdabenne]

On ‎8‎/‎1‎/‎2016 at 1:55 AM, Starwaster said:

I'm sure it would be technically possible but have you tried experimenting with the autocut speed? Try lowering  below its default. The scenario you describe sounds like it could still have enough velocity not to trigger autocut if it's low enough. 

1. The suggestion you made has been made already and discussed in this topic nearly two years ago. I think it's safe to say the author has decided not to implement that or other patches dealing with third party plugins.
2. Both Phineas and I contribute enough to these forums and to KSP players to be more than just 'some bystander'
3. It's ok for other people on these forums to disagree with you and you should get used to that and not take it personally. Nobody here has acted as though you are insulting them. You should try taking your own advice in your last several sentences.

I'm used to forums, probably been dealing with them since before you were born (back in USENET days, far rougher and tougher environment).  And as far as discussions from 2 years ago, sorry, nobody really has the time to read 163 pages of old discussions of things that do not related to current or near current releases - and there is really no good way to index for this sort of thing (forum limitations I guess). I did read back a few months worth (questions about 64bit, CKAN, etc), and that's usually sufficient. 

The attitude is what got me.  You made it a question about me and why I would ask for such a thing. That's why I responded as I did.  For someone supposedly as experience with forums as you are, you sure posted to provoke rather than explain.  All you had to do was post #1 from your reply - The author decided its not worth the hassle.  That's all that was needed.  Perhaps after all your "experience" with forums, you might want to remember that, especially since you are acting as a spokesperson for the author.

Anyway, thanks for finally posting the actual answer.  That's all I was needing - that I need to put the adjustment in my own mod manager config because the author doesn't want the task of supporting other mods. Fair enough.

[Starwaster]

18 minutes ago, Murdabenne said:

I'm used to forums, probably been dealing with them since before you were born (back in USENET days, far rougher and tougher environment).  And as far as discussions from 2 years ago, sorry, nobody really has the time to read 163 pages of old discussions of things that do not related to current or near current releases - and there is really no good way to index for this sort of thing (forum limitations I guess). I did read back a few months worth (questions about 64bit, CKAN, etc), and that's usually sufficient. 

The attitude is what got me.  You made it a question about me and why I would ask for such a thing. That's why I responded as I did.  For someone supposedly as experience with forums as you are, you sure posted to provoke rather than explain.  All you had to do was post #1 from your reply - The author decided its not worth the hassle.  That's all that was needed.  Perhaps after all your "experience" with forums, you might want to remember that, especially since you are acting as a spokesperson for the author.
 

 

No, you did all that yourself, and you're still doing it. Persisting in personalizing something that was never personal and now you're going even further by making wildly inaccurate and snide assumptions about a perceived age gap. You apparently STILL haven't gotten this whole thing about dealing with and relating with people remotely,, projecting non-existent motives and emotional states onto other people. You really need to work on that.

As far as reading 163 pages worth of thread, nobody actually expects that of you and nobody called you out on it. Though since you bring it up, you COULD have used the search function. You might want to consider that in the future.

 

[Red Iron Crown]

It would be greatly appreciated if we could refrain from discussion of people's personalities in this thread. It seems Murdabenne's question has been asked and answered satisfactorily, please allow the matter to drop without making things personal.

[Lilienthal]

Size of chutes not taken into account by deadly reentry?

I am running RSS/RO/RP-0 in its newest version, and have just tried returning with a MkI pod from outer space (400.000 km up), using the descend mode, i.e. non-central center of mass.

When I am using a real-chute double parachute part, it burns up, even when use a really small size.

However, Mk16 std chute, or radial chutes work fine.

My Question (possibly bug report) therefore: Is it possible that the size of the chute chosen in the action menu doesn't change its size with regards to whether it gets protected by a heat shield or not?

Thanks,

Gustav.

[Starwaster]

4 hours ago, Lilienthal said:

Size of chutes not taken into account by deadly reentry?

I am running RSS/RO/RP-0 in its newest version, and have just tried returning with a MkI pod from outer space (400.000 km up), using the descend mode, i.e. non-central center of mass.

When I am using a real-chute double parachute part, it burns up, even when use a really small size.

However, Mk16 std chute, or radial chutes work fine.

My Question (possibly bug report) therefore: Is it possible that the size of the chute chosen in the action menu doesn't change its size with regards to whether it gets protected by a heat shield or not?

Thanks,

Gustav.

FYI, Deadly Reentry doesn't handle that sort of thing anymore. Stock handles the application of all reentry heating and determines whether or not a part is shielded by another part, unless you're using FAR.

For stock, it doesn't look like the drag data changes when RC parts are resized, just going by the physics data available in-game. (referring to drag cubes here)

FAR has its own way of doing things... I think it recalculates for size changes though.

[Lilienthal]

1 minute ago, Starwaster said:

FYI, Deadly Reentry doesn't handle that sort of thing anymore. Stock handles the application of all reentry heating and determines whether or not a part is shielded by another part, unless you're using FAR.

For stock, it doesn't look like the drag data changes when RC parts are resized, just going by the physics data available in-game. (referring to drag cubes here)

FAR has its own way of doing things... I think it recalculates for size changes though.

Thanks for the info! I am running FAR, but it doesn't seem to recognise the size changes either.

Looks to me like a but / missing feature. - Not grave, but maybe worth changing?

[charliepryor]

I'm curious as to whether or not RealChute is causing this error I keep seeing. This is an image of what Exception Detector sees, and this number just keep rising, and fast. My log is flooded with the following message every single time I have a craft is loaded.

Spoiler

NullReferenceException: Object reference not set to an instance of an object
  at Vessel.GetUnloadedVesselMass () [0x00000] in <filename unknown>:0
  at Vessel.GetTotalMass () [0x00000] in <filename unknown>:0
  at Vessel.CalculatePhysicsStats () [0x00000] in <filename unknown>:0
  at Vessel.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Here is a past log. No real changes from this one exist in new logs either. Because it's trying to "get mass" with this, and I see "DragCubeSystem" in there, I thought that maybe this mod would have something to do with it. It's really lagging out my game, and RAM usage moves up to as much as 15GB sometimes. Granted, I do have a lot of mods installed, but still. I've posted in numerous places on these forums with different context for each place because this is driving me nuts and I'd love to solve it, or to have somebody far more knowledgeable at least give that one clue that sets me in the right direction.

Thank you in advance for your time

Edited August 23, 2016 by charliepryor
forgot to link the image

[stupid_chris]

Hello people! Time for a little announcement.

As most of you might have noticed, I have been rather inactive from here in the past few months. There are multiple reasons for that. First off, let's just say that RealLife™ got in the way. Work and personal time took most of my summer. As a matter of fact, I did not touch anything prog related for the whole summer, and instead tried to focus on enjoying my vacation. Now that college is back on, I'm starting to dabble back into my projects. The other reason of my inactivity here is that other projects, notably a completely new game I'm working on with friends, are starting to take up large amounts of my time.

For this reason, I have decided to press the brake a bit on RealChute matters. I'm not abandoning this completely, but given that modding is a very high expanse and very low return activity, and that on all fronts, I definitely do not have as much time to accord to this.

Therefore, I am looking for a maintainer for RealChute. I'm talking here about someone that would manage the current 1.x versions of RealChute to keep them working, compatible, and on level with KSP's progress. The reason for this, is that updating RealChute constantly to the core game while working on RealChute2 is highly counterproductive, and prevents me to correctly focus on new stuff.

Please PM me if you desire to help. I already do have quite a handful of names in mind, but I also want to see who will come forward on their own, as I'm not willing to pass this on to just anyone.

Thank you, and see you all around.

Chris

[Drew Kerman]

4 minutes ago, stupid_chris said:

but given that modding is a very high expanse and very low return activity, and that on all fronts, I definitely do not have as much time to accord to this.

Especially if you're not even playing the game much at all. Good luck with your own game tho.

[pap1723]

RealChute is officially supported by the Historical Progression Tech Tree!

[TiktaalikDreaming]

Well, just started messing with this mod for making another mod RO compatible.  Why do I keep stumbling on mods when the devs are backing away?

So... I guess this question goes to "the community" or @stupid_chris if he happens to have time.

I've been trying to add MM config for RealChutes for two chutes for my MEM project.  I've done both fairly similar for testing, and one works, and the other is plain old broken.

I've gone over the config a bunch of times.  The animation names match, the parachuteName matches the chute's mesh, exactly the same as the stock config's canopyName.  Similarly the capName matches.  Material is set to Kevlar (I also experimented with adding materials, which seems to work fine, but for debug purposes, removed).

The thing is, it's broken before use.  The UI for showing chute properties doesn't even come up right.

So, the non-functioning chute (a ballute) has a shrunk UI that can't be dragged around the screen;

While the functioning drogue chute seems to work fine (apart from needing tweaking so it can open *before* smashing into the ground);

 

The RealChuteModule component of the MM for the ballute;
 

Spoiler

   MODULE
    {
        name = RealChuteModule
        caseMass = 0.08
        timer = 0
        mustGoDown = true
        cutSpeed = 2
        spareChutes = 1
        
        // Single main chute
        PARACHUTE
        {
            material = Kevlar
            capName = ChuteUnitCover
            parachuteName = Ballute
            preDeploymentAnimation = Stage1
            deploymentAnimation = Stage2
            preDeployedDiameter = 19.6
            deployedDiameter = 28
            minIsPressure = false
            minDeployment = 30000
            deploymentAlt = 15000
            cutAlt = -1
            preDeploymentSpeed = 12
            deploymentSpeed = 6
        }
    }

 

The output_log.txt seems to suggest I have names of objects wrong.  But I can't see where.
 

Spoiler

Module RealChuteModule threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object

  at RealChute.Parachute.Initialize () [0x00000] in <filename unknown>:0

  at RealChute.RealChuteModule+<>c.<OnStart>b__99_0 (RealChute.Parachute p) [0x00000] in <filename unknown>:0

  at System.Collections.Generic.List`1[RealChute.Parachute].ForEach (System.Action`1 action) [0x00000] in <filename unknown>:0

  at RealChute.RealChuteModule.OnStart (StartState state) [0x00000] in <filename unknown>:0

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

 

&

Spoiler

 

NullReferenceException: Object reference not set to an instance of an object
  at RealChute.Parachute.PreDeploy () [0x00000] in <filename unknown>:0

  at RealChute.Parachute.UpdateParachute () [0x00000] in <filename unknown>:0

  at RealChute.RealChuteModule+<>c.<FixedUpdate>b__97_2 (RealChute.Parachute p) [0x00000] in <filename unknown>:0

  at System.Collections.Generic.List`1[RealChute.Parachute].ForEach (System.Action`1 action) [0x00000] in <filename unknown>:0

  at RealChute.RealChuteModule.FixedUpdate () [0x00000] in <filename unknown>:0
 
(Filename:  Line: -1)

 

&

Spoiler

 

NullReferenceException: Object reference not set to an instance of an object
  at RealChute.Parachute.FollowDragDirection () [0x00000] in <filename unknown>:0

  at RealChute.Parachute.UpdateParachute () [0x00000] in <filename unknown>:0

  at RealChute.RealChuteModule+<>c.<FixedUpdate>b__97_2 (RealChute.Parachute p) [0x00000] in <filename unknown>:0

  at System.Collections.Generic.List`1[RealChute.Parachute].ForEach (System.Action`1 action) [0x00000] in <filename unknown>:0

  at RealChute.RealChuteModule.FixedUpdate () [0x00000] in <filename unknown>:0
 
(Filename:  Line: -1)

 

 

 

But, it also doesn't *seem* to throw any errors when configuring;

Spoiler

 

[ModuleManager] Applying node DeadlyReentry/DeadlyReentry-RealChutes/@PART[*]:HAS[@MODULE[RealChuteModule]]:Final to NAR_MEM/Parts/MEM-Ballute/Ballute/MEMBallute
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[ModuleManager] Applying node DeadlyReentry/DeadlyReentry-RealChutes/@PART[*]:HAS[@MODULE[RealChuteModule]]:Final to NAR_MEM/Parts/MEM-Drogue/Drogue/MEMDrogue
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

 

 

 

So I guess the question is, are there any obvious requirements I might not be meeting to use RealChuteModule?  This is a Ballute that isn't functioning, so if there's expectations on the look of the mesh (seems unlikely) or if the values are somehow capped. 

Zip of the full configs, the parts, and the output_log.txt > https://www.dropbox.com/s/m2gze0ezplfs32y/BalluteIssue.zip?dl=0

 

Halp!

Although I have to go to work now.  And I'm not sure how much time I'll have to look at this when I get home.  and...

... 1.2 pre-release could drop any moment, where-upon I'll run around checking stuff out there like everyone else.

But, if someone's come across this sort of thing before and has an answer I'd be very happy to hear about it.  :-)

[Starwaster]

d

On 9/13/2016 at 6:03 PM, TiktaalikDreaming said:

Well, just started messing with this mod for making another mod RO compatible.  Why do I keep stumbling on mods when the devs are backing away?

So... I guess this question goes to "the community" or @stupid_chris if he happens to have time.

I've been trying to add MM config for RealChutes for two chutes for my MEM project.  I've done both fairly similar for testing, and one works, and the other is plain old broken.

I've gone over the config a bunch of times.  The animation names match, the parachuteName matches the chute's mesh, exactly the same as the stock config's canopyName.  Similarly the capName matches.  Material is set to Kevlar (I also experimented with adding materials, which seems to work fine, but for debug purposes, removed).

The thing is, it's broken before use.  The UI for showing chute properties doesn't even come up right.

So, the non-functioning chute (a ballute) has a shrunk UI that can't be dragged around the screen;

 

So I guess the question is, are there any obvious requirements I might not be meeting to use RealChuteModule?  This is a Ballute that isn't functioning, so if there's expectations on the look of the mesh (seems unlikely) or if the values are somehow capped. 

Zip of the full configs, the parts, and the output_log.txt > https://www.dropbox.com/s/m2gze0ezplfs32y/BalluteIssue.zip?dl=0

 

Halp!

Although I have to go to work now.  And I'm not sure how much time I'll have to look at this when I get home.  and...

... 1.2 pre-release could drop any moment, where-upon I'll run around checking stuff out there like everyone else.

But, if someone's come across this sort of thing before and has an answer I'd be very happy to hear about it.  :-)

I'll take a look at your problem when I have time. Probably sometime this evening. (5:30AM right now)

However, the output_log.txt file in your download doesn't match with your issue as it was recorded when neither Realism Overhault or Real Chute were installed. It's not going to be of use in troubleshooting. Need an output_log.txt file that matches with your current installation.

Also, ModuleManager.configcache would be handy too.

[TiktaalikDreaming]

On 15/09/2016 at 7:32 PM, Starwaster said:

d

I'll take a look at your problem when I have time. Probably sometime this evening. (5:30AM right now)

However, the output_log.txt file in your download doesn't match with your issue as it was recorded when neither Realism Overhault or Real Chute were installed. It's not going to be of use in troubleshooting. Need an output_log.txt file that matches with your current installation.

Also, ModuleManager.configcache would be handy too.

Thanks.  I'll have to relook at what I added to that zip.  I could have sworn it was from the right KSP, but maybe I've added the really old copied over pre-64-bit one.  I'll check, and add the MM cache.  I didn't think to look at that.  Which is pretty daft.

Updated the zip.

This time I checked the file before copying, and after by opening the zip.  It contains the line;

Non platform assembly: G:\KSP1.1.2RO\Kerbal Space Program\GameData\RealChute\Plugins\RealChute.dll (this message is harmless)

Which I take as a good sign.  And this sign it's loading my config;

Config(@PART[MEMBallute]:NEEDS[RealismOverhaul]) NAR_MEM/Config/RealismConfigs/@PART[MEMBallute]:NEEDS[RealismOverhaul]

 

and now that I'm removing the parachute module AND the RealChuteFAR module, it's working nicely.  :-/

 

Edited September 19, 2016 by TiktaalikDreaming

[TiktaalikDreaming]

I changed the config to NEEDS[RealismOverhaul]:AFTER[RealChute] and made it all @-based, like the FASA configs in RO.  Now the chute vaguely behaves, but is reporting the wrong materials and so on.  I think I'll just mess around some more and see if I can get it to behave.

[stupid_chris]

Hi everyone!

Just a short message to let you guys know that none other than @Starwaster will be making the compatibility updates for RealChute until RealChute2 is ready.

Thank you all and see you around

[Starwaster]

On 9/22/2016 at 1:52 PM, stupid_chris said:

Hi everyone!

Just a short message to let you guys know that none other than @Starwaster will be making the compatibility updates for RealChute until RealChute2 is ready.

Thank you all and see you around

And going through the process of updating it now. In-flight functionality is intact though I still have to go through parts of it to see if any of the code still needs to change to conform to new KSP 1.2 changes.. Menu fails sometimes

Also, the compatibility checker throws Linq errors on startup so I need to make sure that actually works. Maybe give it bad version requirements to make sure it actually returns positive for incompatibility. (that one is really odd because at one point I installed Deadly Reentry which uses the same checker and the error stopped. And DRE's checker correctly indicated incompatibility... AFAIK the code is 99% identical)

[drtedastro]

sounds great.

looking forward to getting it and checking it out.

cheers.

[lajoswinkler]

*obligatory petty screaming at modders for not giving out the links few minutes after the update*

[Starwaster]

On 10/12/2016 at 11:42 AM, lajoswinkler said:

*obligatory petty screaming at modders for not giving out the links few minutes after the update*

obligatory 'I'm working on it'

[MaverickSawyer]

Obligatory reminder that most folks understand that mod makers have lives outside of KSP, and that patience is a sadly underrated virtue.

*goes back to playing 1.1.3 until ALL the mods are updated and debugged...*

[Starwaster]

54 minutes ago, MaverickSawyer said:

Obligatory reminder that most folks understand that mod makers have lives outside of KSP, and that patience is a sadly underrated virtue.

*goes back to playing 1.1.3 until ALL the mods are updated and debugged...*

Patience is a virtue but the virtuous are few.

Ask the modder for an update and he'll come looking for you...

(that said, I'll just leave this thing here...)