[1.12.X] RealChute Parachute Systems v1.4.8.3 | 24/01/21

[stupid_chris]

The problem is the timewarp. Just as for stock chutes, timewarping with them active is a bad idea. Sime I'm using custom forces, the effect is the exact same as timewarping with an engine on. Sometimes the parachutes go out of control at 4x, so simply be careful. It's not a part only issue, it applies to them all. There's no fix unfortunately, physical time warp does some terrible, terrible things to physics.

[rottielover]

The problem is the timewarp. Just as for stock chutes, timewarping with them active is a bad idea. Sime I'm using custom forces, the effect is the exact same as timewarping with an engine on. Sometimes the parachutes go out of control at 4x, so simply be careful. It's not a part only issue, it applies to them all. There's no fix unfortunately, physical time warp does some terrible, terrible things to physics.

But I always land with 4x physics warp on the chutes that sumghai made just fine. For me, the mercury chute is the only one that does this. The rest of the chutes I've used (drogue and mains, and the combo's, and the stock chutes) all work perfectly for me at 4x physic's warp.

I'll just avoid the mercury chute from now on.

[stupid_chris]

But I always land with 4x physics warp on the chutes that sumghai made just fine. For me, the mercury chute is the only one that does this. The rest of the chutes I've used (drogue and mains, and the combo's, and the stock chutes) all work perfectly for me at 4x physic's warp.

I'll just avoid the mercury chute from now on.

It's not part related I can assure you. I had that happen to me on at least six different chutes. It doesn't happen everytime, but it can happen, and when it does it's not a nice thing to see. My reccommendation is to not go at 4x time warp.

[federicoaa]

the parachute for planes is drag or drogue?

[AbeS]

I think what you want is drag, to kill horizontal velocity

[Shad0wCatcher]

@federicoaa Drag. Says so right in the part description in that they're optimized for horizontal; not vertical speed reduction.

@rottie I can account for the same issues with any number of parachutes @ 4x physics. You're asking some really hefty stuff of the Unity engine @ 4x; all calculations are being done at 4x the speed and the engine to cut down on processing requirements does some really nasty rounding that can cause all kinds of problems.

[rottielover]

I can only give you stories, cause there's nothing in the logs.

When I'm playing on my custom built computer, I can run 4x physics warp with ANY of the chutes and nothing bad happens. When I play on my laptop, bad stuff happens. Both machines have the same KSP install because I cloned the DIR's over after letting steam install it.

My only thought is that CPU power must have something to do with it.

Anyway, I'll be careful with the laptop, and fly recklessly with the desktop.

[NathanKell]

Play with max physics DT in settings.

[Frostiken]

So I was having all kinds of weird problems with menus on parts being doubled-up twice on the right-click menu... two entries for all my RemoteTech stuff, two ECLSS buttons...

Come to find out, you embedded a copy of the MM1.5.5 deep inside your mod folders. MM was basically running twice.

So please do not do this.

The proper place for ModuleManager is in \Kerbal Space Program\Gamedata\ModuleManager_1_5_5.dll. Not hidden inside the recesses of your mod folder structure. Your mod should be packaged in its archive in such a way that modulemanager extracts to the root Gamedata directory.

Sorry but I'm a little peeved. This could've saved me a lot of confusion if I knew it was packaged in there. Keeping it in there also means that if there's an MM update, people almost certainly will end up with two copies of MM running since I doubt they would ever know yours was there.

[Dave7]

Come to find out, you embedded a copy of the MM1.5.5 deep inside your mod folders. MM was basically running twice.

You did not install correctly.

The ModuleManager file is not embedded deep inside the mod folders. It's in the GameData folder in the "ModuleManager files" folder. You do not drag and drop the "ModuleManager files" folder into your KSP GameData folder. You drag and drop the files or directories you want to use out of the "ModuleManager files\GameData" folder into your KSP GameData folder.

[stupid_chris]

So I was having all kinds of weird problems with menus on parts being doubled-up twice on the right-click menu... two entries for all my RemoteTech stuff, two ECLSS buttons...

Come to find out, you embedded a copy of the MM1.5.5 deep inside your mod folders. MM was basically running twice.

So please do not do this.

The proper place for ModuleManager is in \Kerbal Space Program\Gamedata\ModuleManager_1_5_5.dll. Not hidden inside the recesses of your mod folder structure. Your mod should be packaged in its archive in such a way that modulemanager extracts to the root Gamedata directory.

Sorry but I'm a little peeved. This could've saved me a lot of confusion if I knew it was packaged in there. Keeping it in there also means that if there's an MM update, people almost certainly will end up with two copies of MM running since I doubt they would ever know yours was there.

ModuleManager never runs twice. It's made itself so that on startup, it finds the most recent version of the plugin and runs only one of them.

As for where it's positioned in the download, it's in ModuleManager_files\GameData\ModuleManager1_5_5.dll so it's at the right place. If you want to update some of the mods to work with RealChute, you simply need to copy over the mod folders as well as the .dll into your GameData directory, it's not embedded deep inside mod folders.

Everyone has been understanding pretty well so far, not sure what isn't clear here. No need for some big caps text when it's already done properly

Edited December 31, 2013 by stupid_chris

[Guest]

Still, you're the one who's doing it wrong. I can see why some people may be confused, because your setup is really bad. Also, you're modifying folders of other mods, which you shouldn't be doing without a very good reason. The whole point of having MM is to be able to keep out of other people's mod folders.

Your thinking about how ModuleManager works seems to be deeply flawed. It doesn't care about where you put the files, and it skips an entry when the parent part is not present. Because of that all ModuleManager configuration files should be your mod's root folder. The ModuleManager DLL should be placed in the pack beside your folder, so that when people unpack it, it's in GameData.

[stupid_chris]

I'm perfectly aware of that. I'm just not seeing the point of forcing people who don't want to use the ModuleManager files to load additional assemblies if they don't plan on using them. And I'm in no way modifying the content of other mods folders, simply adding a file. It's being put there to be easily added and removed at will with the mods that go along.

Installation is far from being hard.

And as far as I know, .cfg files can be placed about anywhere. I know that ModuleManager.dll should be in GameData, and this is where I dropped it.

It's either that or I drop the ModuleManager files outside the main download once more.

[boberts314]

And I'm in no way modifying the content of other mods folders, simply adding a file. It's being put there to be easily added and removed at will with the mods that go along.

But that is modifying the content of the folders. And I'm not just trying to be pedantic, I think it's potentially important. You make a good case for not wasting memory in the event someone decides to uninstall one of the other mods that you've included compatibility with, but what happens if someone wants to remove or modify your mod?

Part of the benefit of ModManager is allowing mods to be contained within a single folder for easy addition, removal, and modification without sacrificing their ability to cross-modify each other. Scattering your files throughout gamedata negates that. And depending on what those .cfgs change it may do worse things, too.

[Guest]

The memory we're talking about is measured in kilobytes. Such dinky amount simply doesn't matter. Besides, it's not loaded at all for people who don't use MM, because KSP doesn't understand the syntax without it. It's benefits, on the other hand, is simple, quick installation and deinstallation of your mod, as well as increased clarity. As I shuffle mods around a lot, this is important to me. Also, it allows to much easier install, and is completely "rename-proof".

Your folder structure in the download should be:

-RealChutes.zip
       ModuleManager1.5.6
      -GameData
          -RealChutes
                 MM_*.cfg

This is the standard other all other mods use. In fact, I modified my RC install to conform to it, and it works perfectly.

[stupid_chris]

what happens if someone wants to remove or modify your mod?.

They create a ModuleManager file to modify RealChute, and not the mods changed by MM?

The memory we're talking about is measured in kilobytes. Such dinky amount simply doesn't matter. Besides, it's not loaded at all for people who don't use MM, because KSP doesn't understand the syntax without it.

An Assembly is a .dll, not a cfg file. ModuleManager.dll is loaded each time you rev up KSP even if you have no MM configs.

It's benefits, on the other hand, is simple, quick installation and deinstallation of your mod, as well as increased clarity. As I shuffle mods around a lot, this is important to me. Also, it allows to much easier install, and is completely "rename-proof".

Your folder structure in the download should be:

-RealChutes.zip
       ModuleManager1.5.6
      -GameData
          -RealChutes
                 MM_*.cfg

This is the standard other all other mods use. In fact, I modified my RC install to conform to it, and it works perfectly.

If it's such a shuffle I'll simply put them in a second download. The ModuleManager packages won't be in the main download for the simple of keeping stock behaviour by default on other parachutes. The ModuleManager files are optional and will remain optional.

[Guest]

An Assembly is a .dll, not a cfg file. ModuleManager.dll is loaded each time you rev up KSP even if you have no MM configs.

This is a matter of ModuleManager, not the configs. It's easy just to delete/not install the .dll, and then, the presence of configs won't matter.

Really, there's no reason for a separate download. If you really must, you might put them in a separate folder in the main download, but in a single one, so that they can be easily unpacked into root.

Oh, and even with the folder layout I proposed, the MM files are still optional, just enabled by default, which is probably how most people want it (make a pool if you want to know for sure). Those that for some reason want to get rid of RC behavior on other chutes can simply delete the MM files. I don't know why you insist on making things harder for the end user, mods like EngineIgniter or MFT use this system successfully since their first release.

Edited January 1, 2014 by Guest

[KASASpace]

Is this integrated into career? And if not, can it be done soon?

[stupid_chris]

Is this integrated into career? And if not, can it be done soon?

It already is, the parts are in the same nodes as the similar parts in the tech tree.

[John FX]

I think I may be noticing an issue. I cannot set the deploy height to be less than 1600m in the tweakables. With a part fresh from the parts list, the height is set to 700m by default but if I try to adjust it I cannot set a height lower than 1600m and have to select a fresh part to have a deploy height of 700m. It is like it is snapping to a predefined minimum value which is larger than the default.

I`m currently trying to have my chutes take 2 seconds to deploy at 300m but to no avail. I have a choice of 700m or 1600m. (50m increments starting at about 100-200m would be awesome)

[stupid_chris]

I think I may be noticing an issue. I cannot set the deploy height to be less than 1600m in the tweakables. With a part fresh from the parts list, the height is set to 700m by default but if I try to adjust it I cannot set a height lower than 1600m and have to select a fresh part to have a deploy height of 700m. It is like it is snapping to a predefined minimum value which is larger than the default.

I`m currently trying to have my chutes take 2 seconds to deploy at 300m but to no avail. I have a choice of 700m or 1600m. (50m increments starting at about 100-200m would be awesome)

That's a problem with tweakables. I tried moving things around, but it mostly ended up in some extremely imprecise ranges. I'd rather finish the editor GUI than mess with this too much.

[John FX]

That's a problem with tweakables. I tried moving things around, but it mostly ended up in some extremely imprecise ranges. I'd rather finish the editor GUI than mess with this too much.

Ah, fair enough. I`ll set them as well as I can then.

[John FX]

I`ve decided to post this in the KOS thread and in the Realchutes thread.

I`ve made an orbital drop pod which is controlled by KOS which uses Realchutes. Does the whole scary drop pod bit. Deorbits with retrorockets, waits until the very last second to pre-deploy the chutes (1000m) and the chutes open at 700m and take 4 seconds to open so they just slow the craft down to about 1/6 the speed of sound by about 45m. The program then activates deceleration thrusters for about 2 seconds that cut out 5m from the surface or so and BLAM. Landed at under 10m/s.

Perfect for spy missions, getting that last best hope behind enemy lines and so forth. Good for all the times you need to get from orbit to the ground as fast as you can with no fuel in a radar invisible one Kerbal craft.

I`ve made a little video too...

Doodbin Kerman has been sent on a super secret spy mission behind enemy lines. He has to launch pre-dawn and land at dusk on the far side of the planet. He will take the new Mk1 DropPod which has been shown to be reliable 37% of the time to the odds are better than normal. He must not use any fuel in the atmosphere above 50m for super secret spy reasons or carry a large chute for weight reasons. the chute will not slow him below 100mph so we have fitted a radar activated thrust pack which will activate at 46m to slow him the rest of the way.

We are thinking we might be able to shave 2-3m off that...

Full video from launch to land.

Time remapped video with slowdown for landing.

(Video shows old script which used staging, downloadable version uses action groups and is much more reliable Also, burn in video is prograde, not retrograde as it should be)

http://www./view/t85sfoc8cy8eqgk/Drop%20Pod.craft

http://www./view/s9fwhv2prg9shdc/drop.txt

Get it into orbit (up to about 120km) point prograde and run drop. You will fire rockets retrograde (from the top of you pod), you will deorbit and land.

This was made as a demonstration of the possibilites of KOS and Realchutes.

Edited January 2, 2014 by John FX

[Mr.Rocket]

I really want to get these, for reasons, but i can't download it. When i put your gamedata folder in the games gamedata folder, it says the parts are downloading, but when i open up the game, the parachutes aren't there. Are there any special things i have to do, or places this has to go, that is different from other mods?

[stupid_chris]

I really want to get these, for reasons, but i can't download it. When i put your gamedata folder in the games gamedata folder, it says the parts are downloading, but when i open up the game, the parachutes aren't there. Are there any special things i have to do, or places this has to go, that is different from other mods?

No, you should only be mergine the GameData folder with your KSP GameData folder. If the parts are not loading, it could mean that you moved something within the RealChute folders or that you have a bad install somehow.