Jump to content

[1.12] Explodium Breathing Engines v1.8.0: "Jet" engines for use on Eve and Jool [10 OCT 2021]


Gordon Fecyk

Recommended Posts

If anyone asking about Jool wants to try these engines there, you just need to clone the planetary resource configuration from Eve to a new one for Jool. I have no idea how the engines and harvesters will behave though, but the chemistry would be weird, and the thrust to ISP won't make sense.

The last time I sent a probe to Jool's lower atmosphere, I saw pressures close to one atmosphere but then climbed very quickly.

Link to comment
Share on other sites

v0.1.5 now available from GitHub repository. Increased engine ISP values to 45% of originals and adjusted resource ratios based on a changed Kerbin baseline. Chemistry described here.

Also includes additional planetary resource definitions supplied by JadeOfMaar for Outer Planets, Galileo's Planet Pack and Gameslinx's Planet Pack.

Edited by Gordon Fecyk
Forgot to include OPM
Link to comment
Share on other sites

On 25/04/2017 at 3:06 AM, Gordon Fecyk said:

Also includes additional planetary resource definitions supplied by JadeOfMaar for Outer Planets, Galileo's Planet Pack and Gameslinx's Planet Pack.

Thou hast my attention!

(Thanks!)

Link to comment
Share on other sites

Welcome, @Gameslinx. That was Jade's idea, not mine. :wink:

What do you think? Is any of this design making sense gameplay or realism-wise to you? Because at first I was worried Razorforce7 was right and that these engines would belong in the world of EM drives and other miracle engines, and then seeing the chemistry involved plus some play testing made me wonder if this sort of thing would be feasible on Titan some day.

Link to comment
Share on other sites

v0.1.6 now available from GitHub repository. Retuned the harvesters and engines so resource abundance now has a direct impact on engine performance. Also changed three engine plumes to use the Stock blue shock diamond, to represent an ethane-oxygen flame. Finally changed Eve's resource abundance to match the KSP Wiki suggestion of 10% ethane.

I've tested this on Kerbin with a temporary planetary resource config for there, with abundance set to 1.5%, and the engines will still experience combustion failure before a resource shortage. I'm starting to wonder if this is a proof of concept for jet engines on Titan!

Link to comment
Share on other sites

v0.2.0 now available from GitHub repository. Added colourized textures to identify these parts separate from stock parts. As I'm using modified versions of Squad's textures, I added a copyright and usage permission notice to the repository.

This should be the last pre-release before posting to Add-On Releases as a beta. Please test. While it might not be practical to use the Alien Space Programs mod to test this on Eve, you can add a resource definition for Kerbin to test it in a normal game, or use HyperEdit to park test craft on Eve. You can get away with as little as 1.5% abundance for this, or lower if you want to test the edges of resource constraints.

There are inconsistencies with the texturing. For instance, the circular intakes / harvesters have their colour band on the connection node edge where other intakes have the band around the dark edge of the intake. The Mk1 tanks and nacelles don't follow the FL-T series colour scheme for LFO tanks, but the Mk2 and Mk3 tanks follow the LFO colour schemes. These were decisions made on the fly as I was learning how to colourize the textures.

I also can't figure out how to edit text used for some reason. I can colourize things, but the "Warning: Flammable Liquid" labels really need to change to use the Oxidizer WHMIS symbol, and I want to use "Warning: Liquid Oxidizer" or some text like that. Perhaps GIMP isn't the right tool for the job, or I'm not using it right. Some textures just don't take to colourization such as the shuttleWings and the radial ramp intake ones. And the Goliath texture is just odd; I'm getting a NRE when trying to load the part with all other parts using the same texture work fine.

Edited by Gordon Fecyk
Link to comment
Share on other sites

While I haven't published a new pre-release, I have added RealPlume configurations to the repository. I think you'll also need fresh copies of the engine configurations to make sure the RealPlume patches apply after the modified parts do. The L.U.C.I.F.E.R. looks especially cool, changing from blue to red when transitioning between cycles. And I sure missed the RealPlume sound effects; glad to see them in place.

This is almost done for a beta release. If I could just make colourization work on the Atlas engine and Big-Ox wings, I'd be set.

Link to comment
Share on other sites

Posted first beta to GitHub repository, and requested to move this thread to Add-On Releases. I think this is safe enough for general use now.

CKAN and SpaceDock help wanted. I think I can figure out SpaceDock, but I'd like a CKAN expert to propose a metadata file for this. Please do not post to CKAN directly; I want to review the metadata first.

Link to comment
Share on other sites

3 hours ago, Gordon Fecyk said:

Posted first beta to GitHub repository, and requested to move this thread to Add-On Releases. I think this is safe enough for general use now.

CKAN and SpaceDock help wanted. I think I can figure out SpaceDock, but I'd like a CKAN expert to propose a metadata file for this. Please do not post to CKAN directly; I want to review the metadata first.

Hey Gordon Fecyk,

Very nice work!! :wink:

 

 

For CKAN you can ask here:

They are very nice people, that are very good at helping! :wink:

Link to comment
Share on other sites

  • 2 weeks later...
On 2017-5-8 at 3:08 AM, Gordon Fecyk said:

Posted first beta to GitHub repository, and requested to move this thread to Add-On Releases. I think this is safe enough for general use now.

CKAN and SpaceDock help wanted. I think I can figure out SpaceDock, but I'd like a CKAN expert to propose a metadata file for this. Please do not post to CKAN directly; I want to review the metadata first.

Hi Gordon, If I put a PR up to the CKAN repo and tag you on it, you can review it there. Does that sound Ok?

Link to comment
Share on other sites

@politas @N3N Don't think I'm unaware of the support conflicts going on over CKAN. It's also rather creepy receiving private messages to the effect of, "Join CKAN. You'll like it here." Please lay off the PMs to this effect.

I put this add-on together to scratch an itch. To make Alien Space Programs more accessible. Can't I just leave it at that without being solicited to join something? And it's still a beta; the engines and harvesters need tuning.

Besides, it isn't that hard:

{
	"spec_version" : 1,
	"identifier"   : "ExplodiumBreathingEngines",
	"$kref"        : "#/ckan/spacedock/1362",
	"depends": [
	{ "name": "ModuleManager" }
	],
	"suggests": [
		{ "name": "RealPlume" },
		{ "name": "SmokeScreen" }
	]
}

Is this what I'd need?

Link to comment
Share on other sites

On 2017-5-17 at 3:08 PM, Gordon Fecyk said:

@politas @N3N Don't think I'm unaware of the support conflicts going on over CKAN. It's also rather creepy receiving private messages to the effect of, "Join CKAN. You'll like it here." Please lay off the PMs to this effect.

I put this add-on together to scratch an itch. To make Alien Space Programs more accessible. Can't I just leave it at that without being solicited to join something? And it's still a beta; the engines and harvesters need tuning.

Besides, it isn't that hard:


{
	"spec_version" : 1,
	"identifier"   : "ExplodiumBreathingEngines",
	"$kref"        : "#/ckan/spacedock/1362",
	"depends": [
	{ "name": "ModuleManager" }
	],
	"suggests": [
		{ "name": "RealPlume" },
		{ "name": "SmokeScreen" }
	]
}

Is this what I'd need?

In relation to that post from last year, we at CKAN have had a change of leadership and significant policy changes that have (I believe) resolved the issues that were coming to a head last June. We now have a universal opt-out policy for modders, and our processes for adding mods requires good faith attempts to contact the mod author.

I am very sorry if you are feeling pressured in any way. I was responding to your request above, "CKAN and SpaceDock help wanted. I think I can figure out SpaceDock, but I'd like a CKAN expert to propose a metadata file for this."

As you say, it isn't that hard, and that appears to be a perfectly functional Netkan file to me. I have tested it locally and it installs. It has pointed out an issue with the RealPlume metadata that I'll have to look into. 

Link to comment
Share on other sites

15 minutes ago, politas said:

I am very sorry if you are feeling pressured in any way.

No worries. I was going to address that, but then got a little creeped out with the private messages. I did ask for help.

If that configuration works, then I'll go with it. Though maybe RealPlume-Stock is a better suggestion than RealPlume. Have a lot going on this weekend though, so this will take a back seat to that.

Link to comment
Share on other sites

5 hours ago, Gordon Fecyk said:

No worries. I was going to address that, but then got a little creeped out with the private messages. I did ask for help.

If that configuration works, then I'll go with it. Though maybe RealPlume-Stock is a better suggestion than RealPlume. Have a lot going on this weekend though, so this will take a back seat to that.

RealPlume-Stock is just the RealPlume configuration for Stock Engines

Link to comment
Share on other sites

  • 2 weeks later...

v0.3.0 pre-release available from GitHub repository only. I'll keep the 0.2.1 release on SpaceDock until I know there aren't any new bugs from introducing localization. English - United States dictionary provided only, but the framework should be in place to add languages.

Edited by Gordon Fecyk
Grammar and lack of sleep
Link to comment
Share on other sites

  • 3 weeks later...

For the 0.3.1 release there will be Spanish localization thanks to Fitiales and his KSP-in-Spanish project, and some harvester re-tuning because of how atmospheric harvesters changed in 1.3. Atmospheric harvesters apparently behave more like air intakes.

But I want some tech tree advice. There are two ways to use these parts: One is in a 'normal' Kerbin-based space program where you visit Eve and you develop the technology to go there in the late game. The other way is in a modded Eve-based space program via GregorxMun's Alien Space Programs where it would be more likely to develop hydrocarbon-breathing engines first before oxygen-breathing ones. In each of these cases, where should the engines and intakes go in the tech tree?

I would guess that from Kerbin the normal jet engines would stay and the explodium engines would move to later in the tree, and these would swap places if playing from Eve. I could just emulate OhioBob and move everything one tier up, but I wouldn't see anyone wanting to use Eve engines from Kerbin if they can't reach Eve yet, or Kerbin / Laythe engines from Eve if they can't reach Kerbin yet. Maybe higher up the tree, then?

Link to comment
Share on other sites

14 minutes ago, Gordon Fecyk said:

But I want some tech tree advice. There are two ways to use these parts: One is in a 'normal' Kerbin-based space program where you visit Eve and you develop the technology to go there in the late game. The other way is in a modded Eve-based space program via GregorxMun's Alien Space Programs where it would be more likely to develop hydrocarbon-breathing engines first before oxygen-breathing ones. In each of these cases, where should the engines and intakes go in the tech tree?

I've been wondering when you'd post something. :) 

There's an easy answer to your problem. Set your parts up first with Kerbin as homeworld in mind, then create a patch for each part or bundle of parts as

@PART[this]:NEEDS[ABC]
{
	@TechRequired = ?
}

where ABC is the folder name for the Eve Space Program and ? is the new tech node the part should appear in. The name of a tech node as seen in the R&D building (its title) may not always be the same as the name in the tech tree config (just like the name and title of a part). Every folder inside GameData is potentially considered a mod by KSP. When Eve Space Program is detected, your parts will move around accordingly.

 

Link to comment
Share on other sites

5 minutes ago, JadeOfMaar said:

I've been wondering when you'd post something. :) 

There's an easy answer to your problem. Set your parts up first with Kerbin as homeworld in mind, then create a patch for each part or bundle of parts as


@PART[this]:NEEDS[ABC]
{
	@TechRequired = ?
}

where ABC is the folder name for the Eve Space Program and ? is the new tech node the part should appear in. The name of a tech node as seen in the R&D building (its title) may not always be the same as the name in the tech tree config (just like the name and title of a part). Every folder inside GameData is potentially considered a mod by KSP. When Eve Space Program is detected, your parts will move around accordingly.

 

Nice tutorial - but you completely missed his question.  :wink:  His question wasn't about *how* to do it, but about *what to do*:  Which nodes in the tech tree do you think would be appropriate for these parts, and should it just be the same for both situations or should it be different?

 

Personally, I'd have it be different - and have them be much further up the tech tree, not just one level up.  I might even create a new tech tree node especially for them.

Link to comment
Share on other sites

@DStaal Oops. :D Well I can open up KSP right now and peek at the stock tech tree. If @Gordon Fecyk intends to plug into Community Tech Tree, then I'm sure the end-of-row node Experimental Aircraft Engines would be an appropriate place for the engines, and an appropriate node (created by you) one or two levels after the CTT node Resource Exploitation for the intakes, or in that node itself. Truth be told, these nodes are very far apart.

Link to comment
Share on other sites

24 minutes ago, DStaal said:

His question wasn't about *how* to do it, but about *what to do*: 

"How" was important, too. With Jade's suggestion, I can have one set of configurations, and Module Manager would pick the right tech tree patches based on whether Eve Space Program was loaded or not. I already do this to add RealPlume configs if RealPlume Stock is present.

Now where to put these engines in the stock tech tree... I guess there are a couple of different applications too: There's low altitude flight for probes and maybe crewed runabouts for the foolhardy, then for making craft to escape Eve back into space. Maybe make the basic jet engines available under a non-aviation node. Could the Hades belong with the EoE version of the Spark, the Asp, for instance, as an engine for a probe?

By the time folks reach High Altitude Flight and Hypersonic Flight they're already thinking about space planes. Here's one idea: I could put the Sphinx in Hypersonic Flight, and the Beelzebub and L.U.C.I.F.E.R. in Aerospace Tech alongside the R.A.P.I.E.R. That's along OhioBob's line. The tanks can stay where they are as they have uses outside of these engines. I'd match the harvesters with their engines. Then if someone is playing Eve Space Program I can swap the stock parts' positions with these ones. I just need homes for the Zephyrus and Atlas engines.

Definitely open to suggestions here.

As for Community Tech Tree, that does have more logical tech nodes for these sorts of experimental engines. Is there a barebones CTT install available that doesn't require fifty other mods that I can experiment with? I better read that CTT thread some when I get home.

Link to comment
Share on other sites

24 minutes ago, Gordon Fecyk said:

As for Community Tech Tree, that does have more logical tech nodes for these sorts of experimental engines. Is there a barebones CTT install available that doesn't require fifty other mods that I can experiment with? I better read that CTT thread some when I get home.

Installing just the CTT should work fine - you'll have empty nodes, but they should all be there.

Or there's some sort of online org-chart that's linked in the CTT thread someplace - I've looked at it once or twice, but it was faster to just open KSP...

Link to comment
Share on other sites

OK, @JadeOfMaar and @DStaal, there are updates to the repository that include new tech tree placements, and also a tech tree swap if Eve Space Program is detected.

Surprisingly, @GregroxMun's Kopernicus mod does work with a KSP 1.3 compatible version of Kopernicus, but Eve shows up as "The Kerbin" in the map and tracking station views. All of Eve's normal properties are still there, including 9-10% ExpVapour in the air. You can still add a resource definition for Kerbin for testing. The harvesters still need a non-zero surface speed to work, but the harvesting rates are a much closer match to the 1.3 air intakes.

I haven't produced a release yet, but you can download a copy of the repository for testing. The next release will be based on these changes if they seem logical. Release 0.3.1 now available on SpaceDock. CKAN support added, I think. No CTT integration yet; I think I'll take that on next weekend.

The tech tree placements are based on two assumptions: You need the technology to get to Eve (or Bin) in the first place before you can make use of these parts. Then after technology's progressed far enough, the remaining parts are just one tier up from their normal placements like in Eve Optimized Engines.

Edited by Gordon Fecyk
KSP 1.3 general release
Link to comment
Share on other sites

  • 4 weeks later...

GregroxMun just released an Alien Space Programs 1.0! As in, it's feature-complete and not terribly buggy.

I have to adjust the tech tree swapping mechanism to accommodate his changes though, because 'EveSpaceProgram' will always be present with any home world setting and this will cause my tech tree swap to take effect. Oxidizer engines won't work on Laythe or Kerbin. If you play with my add-on and Alien Space Programs 1.0, consider deleting or hiding EveSpaceProgramTechTree.cfg unless you have Eve as the home world, or until I release an update.

Link to comment
Share on other sites

12 hours ago, Gordon Fecyk said:

If you play with my add-on and Alien Space Programs 1.0, consider deleting or hiding EveSpaceProgramTechTree.cfg unless you have Eve as the home world, or until I release an update.

@linuxgurugamer has an new, self-made mod coming that could fit right in and deal with this problem. Check it out. I have plans for it as well.

 

 

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

×
×
  • Create New...