stupid_chris

RealChute does not support that.

I was mostly arguing the point of paid mods not being the spawn of satan, but Creator DLCs are very different yes. Integrating a mod is a very different process and has very different expectations as far as quality is concerned, yet again.

Well yes, but I am not sure how this applies to an independent paid mod.

That's just the concept of a free market, and it's fully expected. As I mentioned, a significant step in quality, support, and content is to be expected from a paid mod, otherwise people will just... not pay for it. No one will pay for a cash-grab cheap mod. The Unity Asset Store is the same idea. There are plenty of free cheap packages to use. But no one expects them to be free, we're simply thankful when they are. Those that aren't free have an increase in quality and support. The paid one without the quality uptick simply do not sell.

This argument is both a hasty generalization and slippery slope fallacy. Donations are not a platform that the average modder can survive on. Modders do not owe anyone free labour if they do not wish so. If a modder wants to use his platform to make ends meet, he should not be crucified at the stake for trying to earn a living. The concept that modders are undeserving of pay because the concept of community is bigger than us is flawed. Feel free to not reply if you do not want to participate, no one is forcing you to. Portal is a good example of successful paid mods through Aperture Tag and Portal Stories: Mel. A free mod and paid mod has different expectations on to what is expected as far as support is concerned, and that is normal.

Modding absolutely does not deserve do stay free. Beggars cannot be choosers. Modders are humans and content creators that deserve to make ends meet, and if modding is the way forward for them they should have a support system to put their skills to use. Most modders will be glad to do this in their spare time and for their own enjoyment, but expecting from them to do this completely for free is honestly quite insulting to the sheer amount of work that goes into most mods. Modders do not owe the community the mods they create.

I do not want nor need RealChute to be monetized, because I am fortunate enough to have a career that takes care of that. I also do not care how many people use RealChute, I wrote it for myself. However, this is not the case for everyone. Modders are content creators, and everyone's life situation is very different. Dismissing so easily the the idea of them being able to be compensated for hundreds to thousands of hours of work is quite silly.

What a terribly bad take.

Hello everyone! Small announcement, RealChute 2 is back on the menu I will be doing a development stream on Twitch tomorrow at 10AM EST, everyone is more than welcome to join! https://www.twitch.tv/stupid_chris Cheers!

There is literally a documentation section in the OP of this thread.

Make sure the canopy and cap names are the correct ones, as well as the correct animation names. For the ProceduralChute module, don't use texture libraries unless you configured one for these parachutes.

Yes, that should do it. MM shouldn't be creating conflicts that break the parachutes, you probably have something else going on, but it's not really possible for me to diagnose just from this. Yes and no. The parachute icons will tell you pretty clearly if it is safe or not to deploy by their colour in the staging list. Thing is, even on pretty fast reentries, you should be going at safe speeds to deploy Kevlar chutes (usually on drogues) by 18km, and Nylon chutes (usually for Mains) by 15km. Thing is, the earliest you would probably want to deploy drogues is probably 6-7km, wile main chutes are fine to only start deploying at around 4-5km, if not much lower. There's very little chance this will cause the parachutes to break, and if it does, you have other problems tbh. If you want to just arm them and forget about them, you can simply set the predeployment alt that low and arm when entering the atmosphere.

The stock parachute modules are replaced by RealChute modules, so all your in flight vessels with parachutes will be broken. Edit: To make it more clear, stock parts have their default behaviour replaced by RealChute, so it cannot be reverted once in flight. RealChute is meant as a complete replacement of stock parachutes, as it has the same behaviour and base features with extra advanced features and more realism.

Well what I'm saying is that from a quick first impression, you shouldn't be able to deploy these chutes at all. Parts have a property called "hiddenFromAirflow" which lets me know if the part is hidden in a fairing, cargo bay, etc. The reason the action group fails is because of this check returning true, meaning the parachutes should not be able to deploy. Now obviously from this perspective, they should be able to deploy, but this check is in Squad's hands, and I have no control over it, so if they do wonky stuff with this detection, not much I can do about it. The parachutes do however deploy normally when staged manually. This is leading me to believe that in fact I'm not doing the check for manual staging. Which means this is likely the bug in the code. So I can either leave it as is for the next small update or RealChute when KSP 1.12 releases, or I can fix it, and the weird stock check will prevent you from staging them at all even manually.

The action group arm parachute does just that, it immediately deploys the parachute. If it cannot deploy it, it does not go into arm mode. The arm action group does what you are looking for, deploying, and arming if not possible at that moment. Probably should have a warning message about it, but I'm not exactly doing QoL changes to RealChute atm. Just tried it out, turns out whacky stuff is going on. First off, it is giving out error messages The parachute's icon even flashes red. However it does deploy if manually staged. One of them is wrong, and since I'm using the part system to know if a part is shielded from airflow (hence the "in a fairing" error message), I'm pretty sure the manual deployment is wrong and is skipping the check. Point is, if I fix it, you'll have no way to deploy at all in this situation.

You can already use the stock MM patch bundled with RealChute as a template

There isn't. Parachutes have to be patched manually with ModuleManager.

It's been mentioned a couple of times already, but I'm not actively working on RealChute at the moment. If StageRecovery is causing issues by interacting with RealChute, I can't do much about it even if I wanted to.

Because the update is not compatible for KSP 1.8. If you are on 1.8, stay on the previous version of the mod. It doesn't say it's compatible. I'm not currently developing RealChute in it's current state, and I'm sure as hell not touching the rat's nest that is the current UI code. RealChute 2 is on indefinite hold as of right now, but new UI is within the scope of it. Make sure you have the right version of RealChute installed, and updated versions of the other mods.

The update for KSP 1.11 is released Changelog: January 21st, 2021 v1.4.8.2 -Updated version filter to not include versions prior to 1.11, recompiled as such January 18th, 2021 v1.4.8.1 -Recompiled for KSP 1.11 Cheers all, hope everyone had good holidays

Read the last page. There is no ETA

I've been at this for nearly 8 years now, so it's not my first rodeo. What was rather unusual this time is that I also got harassed on my personal Discord server dedicated to my WIP game. Kinda shortens the fuse. The tl;dr is that I now code for work. While I love my job and what I do, I've also just finished my penultimate Uni semester, and I'm on Holidays vacation, so I'd much rather avoid programming while it lasts and I'll get back to it after.

When I have the time.

That is exactly what I said.

The warning reads that the mod may not work or be disabled. In my case, it is always disabled completely on new version. It's not that it doesn't work, it's that it won't work, because it's designed to shut itself off. If you see that warning pop off and the mod suddenly appears to be not present at all, that's a pretty good indication that you should wait for an update.