steedcrugeon

[1.3] REKT Escape Pod Mod - v0.4.5.1 (more fixes)

Recommended Posts

hey guys, I got an issue. I downloaded REKT from CKAN and also tried to manually install from github and merged, and both times, I do not have the OTAV parts in my game. all I have are the dock ring, clamps and inline adaptor. all other parts not related to OTAV is showing up.

let me know what files you need to see to help me with this issue. I really like how this mod looks and want to use it!!!

Current KSP Version is: KSP for Windows x86 1.2.2, Build 1622.

 

EDIT:

I found this issue with another person in this thread. im going to try to fully unload REKT via CKAN, verify the file is gone, and reattempt a manual install from my zip file.

 

EDIT:

manually installing this mod has indeed worked. I bypassed the issue by directly placing the folder labeled "SHED" into the GameData folder. so far, this seems to have fixed the issue, as I now see all the parts as listed on the mod page. now, to figure out how to fly it better that a rock with a death wish... :)

Edited by Kamiyosha
Found similar issue in this thread and found temp fix

Share this post


Link to post
Share on other sites
9 hours ago, Kamiyosha said:

EDIT:

manually installing this mod has indeed worked. I bypassed the issue by directly placing the folder labeled "SHED" into the GameData folder. so far, this seems to have fixed the issue, as I now see all the parts as listed on the mod page. now, to figure out how to fly it better that a rock with a death wish... :)

@Denko666 Has posted this as a problem on the Github page. It's to do with how the OTAV core and related parts are addressed in their configs. I will be rectifying this on the next release. For the interim the fix you described is the best bodge fix to get the parts to show up.

Share this post


Link to post
Share on other sites

This mod is awesome! Please continue your development of it! Now for suggestion box. Is there a way to have a parachute BUILT IN the standard pod? Air brakes work great! All the way to a bad case of hill disease. Big issues so far are: not enough batt to make it to the ground, no mount points on most sub modules (i.e. fuel cell, batt, ect.) to mount a parachute, very much needed auto module for multiple pod ejections (intergration of some landertron components, with permission, highly suggested), and a port addition to the dock ring (not very realistic to dock and then have to eva to a airlock...). Other suggestions! Perhaps a docking ring to fit mk2 and mk3 stockalike command pods? Mayhaps hexagonal frame design for larger pod configurations? 

So, theres my suggestions. Still an awesome mod. I cant wait for updates to this. Keep up the awesome work. 

Share this post


Link to post
Share on other sites

Great mod! keep up the good work.

Small issue I found: After deployement the paracute part model becomes slightly bigger. I don't know if its just me, I just wanted to let you know.

Share this post


Link to post
Share on other sites
1 hour ago, Zutt said:

Great mod! keep up the good work.

Small issue I found: After deployement the paracute part model becomes slightly bigger. I don't know if its just me, I just wanted to let you know.

Hmm, interesting i think i may have seen this bug before. Which version of the mod are you running?

Share this post


Link to post
Share on other sites
16 hours ago, steedcrugeon said:

Hmm, interesting i think i may have seen this bug before. Which version of the mod are you running?

v.0.4.3.1

I've tried reinstalling the game, reinstalling the mod, tried with and without CKAN, but the bug is still there. Do you want me to post a log file?

Edited by Zutt

Share this post


Link to post
Share on other sites
20 hours ago, Zutt said:

v.0.4.3.1

I've tried reinstalling the game, reinstalling the mod, tried with and without CKAN, but the bug is still there. Do you want me to post a log file?

No log file should be necessary, this is a model scaling issue within the animation for the parachute. I noticed it during the testing phases but (mistakenly) thought I had fixed it before release. I'm prepping another release Soon™ and as this isn't a game breaker I'll capture it then.

Thanks for bringing it back to my attention though, otherwise it would have slipped through another release.

Share this post


Link to post
Share on other sites
1 hour ago, steedcrugeon said:

I'm prepping another release Soon™ and as this isn't a game breaker I'll capture it then.

Allright, good luck. Looking forward to it!

Share this post


Link to post
Share on other sites

I have looked through the thread and i did not see any download links for this mod and i want to play with the mod a lot.

Also where do i find it?

Edited by McGillicuttyyoutubing
Forgot to ask for link or area of where

Share this post


Link to post
Share on other sites
7 hours ago, McGillicuttyyoutubing said:

I have looked through the thread and i did not see any download links for this mod and i want to play with the mod a lot.

Also where do i find it?

In the First post, scroll down the heading marked: DOWNLOAD then pick your source!

Share this post


Link to post
Share on other sites

Hi just a question, do I have to manually land this pod, or can I just fire it towards kerbin with a parachute and continue to control another vessel?

Share this post


Link to post
Share on other sites
43 minutes ago, funkcanna said:

Hi just a question, do I have to manually land this pod, or can I just fire it towards kerbin with a parachute and continue to control another vessel?

Unfortunately I haven't managed to make a StageRecovery compatibility patch, Yet™ so as it stand if your pods leave physics range then they are treated like debris (burn up, all crew lost). You can launch multiple pods together and if they all stay in physics range, ~2km, and you have set them up for it:

an example kerbin station pod I'd use:

has a mono prop fuel cell and the mini chute (set to go off @0.7 atmosphere and 1000m altitude) attached.

point prograde, (all rekt pods with inbuilt RCS are designed counter intuitively) and fire the monoprop engines until you have a periapsis about 30Km. If 'clustering' your deorbit then you need to try and get all the pods to the same velocity and trajectory. 

The have the chute and airbrake stage together so you can fire them all and they should roughly descend together (the staging of the chute and airbrake is best done at around 50-30Km) you need to stage each one and move on to the next quickly as to not move out of physics range of the furthest pod. The advantage of the airbrake firing is that you don't need to have SAS engaged after the airbrakes deploy, Plus the mk1a pod is built very tough (hence its mass) and is quite thermally efficient so will withstand a lot of heat.

An alternative  approach is to have them de-orbit about 10-15 minutes apart, that way you can fly them in one by one with little risk to running out of Life support (if used).

Share this post


Link to post
Share on other sites
3 hours ago, steedcrugeon said:

Unfortunately I haven't managed to make a StageRecovery compatibility patch, Yet™ so as it stand if your pods leave physics range then they are treated like debris (burn up, all crew lost). You can launch multiple pods together and if they all stay in physics range, ~2km, and you have set them up for it:

an example kerbin station pod I'd use:

has a mono prop fuel cell and the mini chute (set to go off @0.7 atmosphere and 1000m altitude) attached.

point prograde, (all rekt pods with inbuilt RCS are designed counter intuitively) and fire the monoprop engines until you have a periapsis about 30Km. If 'clustering' your deorbit then you need to try and get all the pods to the same velocity and trajectory. 

The have the chute and airbrake stage together so you can fire them all and they should roughly descend together (the staging of the chute and airbrake is best done at around 50-30Km) you need to stage each one and move on to the next quickly as to not move out of physics range of the furthest pod. The advantage of the airbrake firing is that you don't need to have SAS engaged after the airbrakes deploy, Plus the mk1a pod is built very tough (hence its mass) and is quite thermally efficient so will withstand a lot of heat.

An alternative  approach is to have them de-orbit about 10-15 minutes apart, that way you can fly them in one by one with little risk to running out of Life support (if used).

Another method i have used is using the tri-mount, and designing it to work as a main deorbiter, thus providing a bit of power (so the chutes open) and ensuring all pods make to the ground roughly with in a few hundred meters of each other. At about 12km, you should be through the hot part, and then stage the pods to deploy at the same time (i prefer to do this with an action group, as this deploys the pods, deploys their airbrakes and arms their chutes.) The main core pod can then deploy its own chute, and carry survival equipment, if you have the mods for such things installed. 

Share this post


Link to post
Share on other sites
3 hours ago, steedcrugeon said:

Unfortunately I haven't managed to make a StageRecovery compatibility patch, Yet™ so as it stand if your pods leave physics range then they are treated like debris (burn up, all crew lost). You can launch multiple pods together and if they all stay in physics range, ~2km, and you have set them up for it:

an example kerbin station pod I'd use:

has a mono prop fuel cell and the mini chute (set to go off @0.7 atmosphere and 1000m altitude) attached.

point prograde, (all rekt pods with inbuilt RCS are designed counter intuitively) and fire the monoprop engines until you have a periapsis about 30Km. If 'clustering' your deorbit then you need to try and get all the pods to the same velocity and trajectory. 

The have the chute and airbrake stage together so you can fire them all and they should roughly descend together (the staging of the chute and airbrake is best done at around 50-30Km) you need to stage each one and move on to the next quickly as to not move out of physics range of the furthest pod. The advantage of the airbrake firing is that you don't need to have SAS engaged after the airbrakes deploy, Plus the mk1a pod is built very tough (hence its mass) and is quite thermally efficient so will withstand a lot of heat.

An alternative  approach is to have them de-orbit about 10-15 minutes apart, that way you can fly them in one by one with little risk to running out of Life support (if used).

Cool thanks.  Ive been using the REKT pods on my Rescue ship and have been attaching 8, going around the planet collecting lost Kerbals and landing them in the pods individually. It works well but obviously would be nice if I could just fire them into the atmosphere and forget them haha :)  

Share this post


Link to post
Share on other sites
3 hours ago, funkcanna said:

would be nice if I could just fire them into the atmosphere and forget them haha :)  

That is on the longer term plan of the REKT mod.

Share this post


Link to post
Share on other sites

From "non-rechargable batteries" discussion here

55 minutes ago, steedcrugeon said:

Thanks @cake>pie I'm going to be testing to see if this 'quick fix' can be used to resolve my 'one-shot' electricity consumption issue on the REKT cryopods.

@steedcrugeon As I said in the non-rechargeable batteries discussion, what I posted there is really quick and dirty. It definitely needs work (feature completeness, user-friendliness, mod compatibility) before being released or integrated into a general release mod. It may not even be the best way to solve your problem! But I'd be glad to help with figuring out your issue and how best to apply those ideas here.

 

I guess your issue is this, which I found earlier in this thread:

On 12/24/2016 at 7:31 PM, steedcrugeon said:

Cryo Pod - I'm still trying to figure out how I can consistently get this to behave as I want (It is supposed to be a 'one-shot' freeze when its stand-alone and not be able to thaw out be itself. I want to keep the 3000 EC freeze/thaw but not have to give the pod a 3000 EC 'internal battery' as well as the RTG).

I don't use deep freeze so can you please confirm my understanding on the following:

a. You want your mk1C to have 5 glykerol and 3000 EC on hand to perform one freeze
b. This 3000 EC needs to be somehow "reserved" so that it cannot be accidentally consumed for other purposes
c. The mk1C would lack the ability to thaw due to insufficient EC

 

I also have a couple of questions:

Looking at your part config, I see that you've used a hack of sorts (Resource: EC; amount=3000; maxAmount=50) to try to enforce (c) above.
Q1: Does this actually work? i.e. will not charge up beyond 50EC once the charge level has dropped below that.

I see that the mk1C has a 0.8501EC/s generator (RTG). I'm guessing this is for powering the reaction wheels (SAS).
Q2: Does the RTG serve any other purpose? Is the RTG essential to maintain a frozen Kerbal, or would it possible to consider doing away with the RTG?

 

Couple of initial thoughts:

- there is a potential gotcha in that you might still need to have a 3000EC capacity buffer for the "nonrechargeable battery" to dump the EC into so that DF cryo module can consume it.

- would still be UX clumsy in that user would have to "plug in the nonrechargeable battery" and then "activate cryofreeze"; not seamless.

- still doesn't provide strong guarantee of requirement (b)

 

Let me know and I'd be happy to assist with whatever I can.

Share this post


Link to post
Share on other sites
21 minutes ago, cake>pie said:

From "non-rechargable batteries" discussion here

@steedcrugeon As I said in the non-rechargeable batteries discussion, what I posted there is really quick and dirty. It definitely needs work (feature completeness, user-friendliness, mod compatibility) before being released or integrated into a general release mod. It may not even be the best way to solve your problem! But I'd be glad to help with figuring out your issue and how best to apply those ideas here.

 

I guess your issue is this, which I found earlier in this thread:

I don't use deep freeze so can you please confirm my understanding on the following:

a. You want your mk1C to have 5 glykerol and 3000 EC on hand to perform one freeze
b. This 3000 EC needs to be somehow "reserved" so that it cannot be accidentally consumed for other purposes
c. The mk1C would lack the ability to thaw due to insufficient EC

Yep.

21 minutes ago, cake>pie said:

Looking at your part config, I see that you've used a hack of sorts (Resource: EC; amount=3000; maxAmount=50) to try to enforce (c) above.
Q1: Does this actually work? i.e. will not charge up beyond 50EC once the charge level has dropped below that.

I see that the mk1C has a 0.8501EC/s generator (RTG). I'm guessing this is for powering the reaction wheels (SAS).
Q2: Does the RTG serve any other purpose? Is the RTG essential to maintain a frozen Kerbal, or would it possible to consider doing away with the RTG?

IIRC - sorta on the first.  There are random interactions that can destabilize it.

On the second: The primary purpose of the RTG is to provide the maintenance power for Deep Freeze, which can (configurable, but by default I believe) draw a small current to keep the freezer running.  So it's needed.  (The EC/s is even set to just barely over the amount needed by default - barely over to account for math effects.)

26 minutes ago, cake>pie said:

Couple of initial thoughts:

- there is a potential gotcha in that you might still need to have a 3000EC capacity buffer for the "nonrechargeable battery" to dump the EC into so that DF cryo module can consume it.

- would still be UX clumsy in that user would have to "plug in the nonrechargeable battery" and then "activate cryofreeze"; not seamless.

- still doesn't provide strong guarantee of requirement (b)

I've actually tried this approach with an MM patch (it's earlier in either this or the dev thread someplace).  It worked with the previous version of DeepFreeze, but doesn't with the current version (without the large buffer) - The previous version allowed the charge to be drawn over time, while the current version needs it all in one block.  I mentioned this to JPLRepo, and he said the change in behavior was non-intended - but no fix was incoming at the time.  (Actually, just checking the thread: He'd edit-replied to my post (which I didn't see...) and it likely has something to do with a change in the behavior in stock.)

Share this post


Link to post
Share on other sites

- { Snip } -

@DStaal Beat me to the response, his statements are accurate.

@cake>pie to elaborate on the function of this pod you are correct, the single shot emergency freeze is just that. It is envisaged that you would only opt to jettison and freeze your kerbal in the most dire circumstances so whilst I understand it would appear clunky to operate I don't see it as too much of an issue?

As correctly stated, the problem at present is DeepFreeze used to be able to 'trickle' charge in order to freeze but now it requires in pretty much in one big chunk and there is not a proper way in stock to implement a temporary 3000 EC 'buffer'.

Share this post


Link to post
Share on other sites

Thanks @DStaal for the info.

5 hours ago, DStaal said:

The primary purpose of the RTG is to provide the maintenance power for Deep Freeze, which can (configurable, but by default I believe) draw a small current to keep the freezer running.  So it's needed.  (The EC/s is even set to just barely over the amount needed by default - barely over to account for math effects.)

Got it.

5 hours ago, DStaal said:

I've actually tried this approach with an MM patch (it's earlier in either this or the dev thread someplace).  It worked with the previous version of DeepFreeze, but doesn't with the current version (without the large buffer) - The previous version allowed the charge to be drawn over time, while the current version needs it all in one block.  I mentioned this to JPLRepo, and he said the change in behavior was non-intended - but no fix was incoming at the time.  (Actually, just checking the thread: He'd edit-replied to my post (which I didn't see...) and it likely has something to do with a change in the behavior in stock.)

Found your attempt in the dev thread. Yeah, it's fundamentally the same thing, so if it didn't work before...

Long shot: would it work if we supply all 3000EC at once?

OUTPUT_RESOURCE
{
	ResourceName = ElectricCharge
	Ratio = 3000
	DumpExcess = false
}

 

If 3000EC buffer is still absolutely necessary then a pure cfg / MM solution is probably out of reach.

 

Edited by cake>pie

Share this post


Link to post
Share on other sites

@steedcrugeon @DStaal \o/ Good news: solved by supplying all 3000EC at once, no buffer needed. Using a solid fuel power cell as per DStaal's original (pre-KSP1.2) solution. PR

Per JPLRepo another thing we can do is to lower the ChargeRate on the DeepFreezer module so that available power generation can keep up with it. I've verified that this can also work (e.g. in random testing I was able to support ChargeRate=3 with 1000EC/s) and it has nice potential to be used for flavor / nerf (i.e. emergency escape cryopod charges up slower than normal cryo parts).
However, the ChargeRate setting is apparently per physics frame, which can be rather unreliable -- depends on user's computer specs, simulation complexity (e.g. huge loaded craft) etc and can be even changed by a user setting. This is awkward because all other resource generation/consumption is per second.

P.S. steedcrugeon for flag transparency on the OTAV see this thread.

Edited by cake>pie
info from DF thread

Share this post


Link to post
Share on other sites

Version 0.4.4 is now out for release.

With great thanks to input from  @cake>pie who built on @DStaal previous module there should now be a working solution to the 'one shot' emergency freeze for the Cryo pod.

I also extend my thanks to @CobaltWolf and @dboi88 who helped me with re-texturing the OTAV's and got me on the straight and narrow with normal maps.

Edited by steedcrugeon

Share this post


Link to post
Share on other sites

I note the 2.5 ring decoupler doesn't have CLS support - you need help writing the config?

Share this post


Link to post
Share on other sites
1 hour ago, DStaal said:

I note the 2.5 ring decoupler doesn't have CLS support - you need help writing the config?

Good spot, I meant to implement a patch, i just didn't.

Share this post


Link to post
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.