Jump to content

[WIP] Nert's Dev Thread - Current: various updates


Nertea

Recommended Posts

You are of course correct... I blame bleary-eyed early mornings x_x

XD we all have them.

Nertea, quick bug report and balance suggestion:

The throttle piece in cockpit IVA is backwards.

I suggest moving the extended nacelle, high bypass intake, and Dudley, to the tech node, subsonic flight, instead of high altitude flight (this is with CTT, not stock tree; screw balancing for the stock tree)

Link to comment
Share on other sites

Would you consider using Alcor prop pack to create the IVA? That has the best instruments and panels for IVA actual usage. That would really make the mk4 look amazing inside and out.

Link to comment
Share on other sites

Would you consider using Alcor prop pack to create the IVA? That has the best instruments and panels for IVA actual usage. That would really make the mk4 look amazing inside and out.

Seconded. Some really otherworldly IVA experiences could be had, if you're up for it Nert.

Link to comment
Share on other sites

Would you consider using Alcor prop pack to create the IVA? That has the best instruments and panels for IVA actual usage. That would really make the mk4 look amazing inside and out.

RPM IVAs are already in the workflow, they just take time. One does not create a full 4-kerbal RPM IVA overnight.

Link to comment
Share on other sites

RPM IVAs are already in the workflow, they just take time. One does not create a full 4-kerbal RPM IVA overnight.

Of course no rush from me :) I just wondered if nertea was open to using the Alcors props as they are very nice and very functional.

Link to comment
Share on other sites

Apologies if you've covered this earlier in the thread, but the attachment nodes are a little low to attach 3.75m parts inside the cargo bays. The parts clip slightly through the floor while having lots of space above them. Its pretty easy to just surface attach the docking port a little higher though.

Link to comment
Share on other sites

Apologies if you've covered this earlier in the thread, but the attachment nodes are a little low to attach 3.75m parts inside the cargo bays. The parts clip slightly through the floor while having lots of space above them. Its pretty easy to just surface attach the docking port a little higher though.

It has to do with wing attachment, centerline, and other things. It'd be cool to see the nodes higher up, but I don't think that'd work well.

Actually now I wanna test it. Brb's peeps.

UPDATE: Okay . . . it doesnt look bad.

oz4OvRh.png

Those aren't the small squares, those are full length wing segments attached via the 3.75m can in the bay (which I offset up to fit properly). THe lower wing was set at a 5* offset down so I could see if it was possible to still mount the wings on the center of the blisters (which I know is a design consideration Nertea makes). Turns out it can be quite well.

Nert, thoughts? I know moving the node lines and CoMs up would be tedious, but this shows that it wouldn't work out terribly at all. Perhaps something to consider for a future release?

Edited by Captain Sierra
Link to comment
Share on other sites

It has to do with wing attachment, centerline, and other things. It'd be cool to see the nodes higher up, but I don't think that'd work well.

Actually now I wanna test it. Brb's peeps.

Wing attachment is only dependent on the part's origin, not the location of stack nodes. Those can be moved at will.

Link to comment
Share on other sites

Yeah, but doesn't the NEEDS statement itself default to a certain pass? A huge amount of mods only ever call NEEDS and don't bother specifying a pass...

No, NEEDS only determines if a given patch is going to be applied. In my thinking having a pass specifier would imply a NEEDS, except for FOR. I think the trick may be that any "fix" would probably break some valid patches and with little benefit. And yes, tons of mods don't specify a pass.

As for the issue with B9, that's probably a bug you should report to sarbian. By logic, a call of :FOR[ModName] should not even run if ModName is not present. You can bet that this would have created tons of problems long before the development of Nertea's MkIV system, so it may be unintended behavior introduced only recently in MM v2.6.6.

The problem is that ModuleManager can't properly validate a FOR, in at least two cases: 1) A mod that doesn't have a plugin (DLL) and wants to be known as something other than the directory name it lives in. 2) Individual mods that live under a common directory, such as UmbraSpaceIndustries/Kolonization. I expect this does create subtle hard-to-diagnose problems, that either are unresolved or inadvertently fixed as the interacting mods evolve. I'm planning to mention it to sarbian, but I'm a bit out of touch the next two weeks. I at least want to write a ModuleManager self test to exercise the behavior for ease of discussion and, in lieu of a change, that will provide a proof of the current implementation.

Link to comment
Share on other sites

Mmmkay, I think I've fixed the FAR bug, a few IVA problems, the cargo tail bugs, a few small texture fixes (I will not change the attach node location, surface attach to load 3.75m cargo). Think I'm done? Any other issues?

Link to comment
Share on other sites

Mmmkay, I think I've fixed the FAR bug, a few IVA problems, the cargo tail bugs, a few small texture fixes (I will not change the attach node location, surface attach to load 3.75m cargo). Think I'm done? Any other issues?

Well that answers that question.

Nothing glaring, certainly nothing that cant wait until the next release. Judging by your sentiments in this thread I'm guessing returning to pure modeling (plugin coding be damned) is mildly therapeutic for you. How many versions of Mk4 are you going to go through before returning to the mess of NFP/NFE/HC? 2.0, 2.1, 2.2?

Link to comment
Share on other sites

The DRP-120 Mk4 Ventral Cargo Bay has the same drag cube as the DRP-60, and its about half the CRG-120. Not a big deal. Only other comment I would have is that the drone core's name begins with "Mark IV" and the cockpit is "Mk4", so they don't end up near each other in my giant parts list, but feel free to ignore that.

Thanks for all your work, this is one of the coolest mods by far. Tested on Duna and Kerbin and it handles great.

Link to comment
Share on other sites

  • 4 months later...

Digging the dev thread out of the depths to discuss an issue and get some feedback :) I'm going to brainstorm a bit here. So beware, behind this spoiler there's quite a wall of text waiting, and I can't promise that it'll be particularly coherent :P What I'd like people to do is telling me where my thoughts are not logical, and whether they agree with me or not.
 

Spoiler

 

So, the current situation is this:

Xenon, argon and liquid hydrogen tanks in Near Future Propulsion all have different fuel/mass ratios. This is not yet accounted for in engine balance, resulting in some engines being as much as 8% above the baseline.

Also, the fuel/mass ratio of liquid hydrogen tanks affects the HydrogenNTRs patch negatively. Because of dry mass differences between stock tanks and Near Future liquid hydrogen tanks, the LV-N loses at least 35% of its performance and thus becomes so weak that in most use cases it delivers less dV than common chemical engines. Other NTRs are similarly affected when patched.

Unfortunately, changing tank masses to fix the first issue makes the second worse - and vice versa. And *then* there's CryoEngines, a wholly different mod which also uses LH2 tanks, but with different dry masses again. A fundamental review of the whole setup is required.



Currently, tank dry masses look like this:
- Stock liquid fuel, 8:1 across the board
- Near Future LH2, from 2.56:1 to 3.54:1 depending on tank size class
- CryoEngines LH2, 2.02:1 across the board

- Stock xenon, 1.27:1 across the board
- Near Future xenon, from 1.43:1 to 1.48:1 depending on tank size class
- Near Future argon, from 1.37:1 to 2.00:1 depending on tank size class

Higher values mean less dry mass per fuel, which results in more TWR and more dV. That's why the LV-N dies such a horrible death when switching from stock LF to NF LH2.

This also illustrates another issue: installing Near Future together with CryoEngines currently lets the player use Near Future's lighter hydrogen tanks to get noticably better performance out of the engines than the mod intended.

 

Ignoring other mods for the moment and focusing fully on Near Future Propulsion, the way I see it, there's two main approaches we can take.

Option 1: ignore the tanks, balance the engines. Dropping performance by ~4% for argon thrusters and ~8% for hydrogen thrusters brings all electric engines back onto the same baseline.

Problems with Option 1: HydrogenNTRs will require absurd stat changes to restore stock performance, such as increasing Isp to twice what their inspirations had IRL, and lots of testing. Also doesn't fix disparity between stock and NFT xenon tanks, which does exist.

Option 2: leave the engines, fix the tanks. Bringing Argon and Xenon together on one baseline ought to be easy, since they aren't far apart. Could even tweak the three stock tanks to match with little to no effort.

Problems with Option 2: What to do with hydrogen tanks? You cannot pick a value for them that satisfies both electric engine balance and NTR balance.



Additional considerations:

- Is it worth keeping the HydrogenNTRs patch in the first place? Sure, it is a nod to realism, but is it strictly necessary from a game design perspective? Since stock KSP removed the need for oxidizer, NTRs are already differentiated from normal engines more than they were in the past when the patch was first conceived. Dropping the patch would eliminate the most severe issues in *both* options above.

- Do the hydrogen tanks have to copy values directly from real life? A thought I recently had was: KSP has entirely unrealistic dry masses on tanks and engines alike to account for needing less dV to orbit, but the math still comes out heavily in favor of the player, as is apparent from ~15% payload fractions in KSP compared to ~3% payload fractions IRL. This probably makes chemical engines a better alternative to realistically statted NTRs and tanks than they would be IRL. As such, maybe the hydrogen tanks need artificially elevated numbers over what you'd find IRL. After all, the stock LV-N does benefit from tanks with no boiloff yet significantly better dry mass ratios than NASA's zero-boiloff hydrogen tank concepts, which I suspect are the inspiration for the current numbers.

- Large disparities between the tank dry masses that are compensated for by adjusting engine stats look fairly interesting at first glance and work out perfectly fine in the spreadhseet, but are extremely intransparent to the player in practice. He will unlock different engines in the tech tree, and the engines running on fuel A will constantly have significantly better stats across the board than the engines running on fuel B. The player doesn't realize that tank dry masses are so much better for fuel B that fully built ships offer comparable performance to ships built with fuel A, because this would require looking at the tanks to compare engine performance, not at the engines. That's not only counterintuitive from a user experience design standpoint, but the fuel/mass fraction of a tank is also not directly displayed, and needs to be figured out by hand. While these considerations definitely exist IRL, for a game it would appear to make perhaps more sense to have very similar dry mass ratios for all fuel types, so that the player can actually compare different engines directly - unless you want to add hints to every single engine description about how good its available fuel tanks are.

- The same intransparency problem exists for fuel costs, which are currently very far apart from each other and only tenuously factored into engine design. But since it is a far less pressing issue, I'm not going to bother with it right now until we've figured the dry mass thing out.

- Should tanks really scale their mass ratios with size class? Neither stock KSP nor most other mods do this. It may be worth settling on one value across the board.



Overall:

I still haven't entirely formed an opinion on everything, due to its sheer complexity, but I'm tending towards the following:
- You will have to either drop the HydrogenNTRs patch entirely, *or* give all the NTRs super-inflated stats. I see no other option right now, even if I'm open to be proven wrong.
- Engines should have very little stat adjustments to help balance tanks, because this is intransparent to the player.
- I would recommend not scaling dry mass with size. Instead, dry cost can scale with size, like stock does it. This still leaves a small incentive for using larger parts, while keeping balance relevant values tightly under control.
- Fuel/mass ratios on xenon and argon tanks, including stock tanks, are best adjusted upwards, instead of adjusting hydrogen down. Ironically this will make them more realistic... ;) Or perhaps, if xenon, argon and hydrogen could all meet around the 2:1 point, then NF can be fixed while simultaneously achieving parity with CryoEngines and fixing the current cross-mod exploit.

 

Now the question is... who agrees with me, and who tells me I'm crazy? :P

 

 

Link to comment
Share on other sites

3 hours ago, Streetwind said:

- You will have to either drop the HydrogenNTRs patch entirely, *or* give all the NTRs super-inflated stats.

I prefer the latter. As you pointed out earlier in your post, chemical engines are significantly more effective in KSP than on Earth. It's only logical that other engines require advantages over their real-world counterparts in order to be balanced relative to chemical engines and to maintain a gameplay niche. For example, KSP ion engines have tremendously greater thrust than real ion engines. I see no reason why NTR ISP should be held sacred. However, NTRs running on kerosene just seems silly.

 

Quote

- Engines should have very little stat adjustments to help balance tanks, because this is intransparent to the player.

I think I mostly agree, or I at least don't strongly object. However, we do need to have meaningful differences between fuel types (e.g., density, cost, maxTemp), because otherwise we might as well just have a single fuel type.

 

Quote

- I would recommend not scaling dry mass with size. Instead, dry cost can scale with size, like stock does it. This still leaves a small incentive for using larger parts, while keeping balance relevant values tightly under control.

Strongly agree. I have never liked NFT's divergence from the stock paradigm on this issue.

 

Quote

- Fuel/mass ratios on xenon and argon tanks, including stock tanks, are best adjusted upwards, instead of adjusting hydrogen down. Ironically this will make them more realistic... ;) Or perhaps, if xenon, argon and hydrogen could all meet around the 2:1 point, then NF can be fixed while simultaneously achieving parity with CryoEngines and fixing the current cross-mod exploit.

Hmm, I don't immediately have a strong opinion one way or the other. There is a certain elegance in the latter solution, I suppose.

Ultimately, I think agreement between NFT and CryoEngines should be regarded as a necessity. Fundamentally, there's no reason why the two mods shouldn't be able to co-exist in a balanced manner, without either one overwriting the configs of the other. Whether that ought to involve NFT conforming to CryoEngines, or CryoEngines conforming to NFT, I don't know. One additional point of consideration (and the principle thorn in my side when I wrote the current CryoEngines fuel-switching patch): LH2/OX configurations of stock tanks need to be included in the balancing process, and - logically - the LH2 portion of these tanks need to be consistent with pure LH2 tanks in terms of the density and dry mass ratios.

Edited by Fraz86
Link to comment
Share on other sites

Quote

- Fuel/mass ratios on xenon and argon tanks, including stock tanks, are best adjusted upwards, instead of adjusting hydrogen down. Ironically this will make them more realistic... Or perhaps, if xenon, argon and hydrogen could all meet around the 2:1 point, then NF can be fixed while simultaneously achieving parity with CryoEngines and fixing the current cross-mod exploit.

That sounds very promising. It wouldn't be too invasive, because NFP already tweaks stock ion engine, so xenon tanks would fit right into the mix.

Scaling tank dry mass ratio with size? better go with stock.

As for hydrogen, I've already flown a couple of nuclear tugs with hydrogen NTR patch installed in previous versions. It was fun to assemble.

What would we get if we take the shift between IRL LF+OX engines/tanks and KSP Stock LF+OX engines/tanks and apply something roughly similar to IRL Hydrogen NTR?

Edited by Psycho_zs
Link to comment
Share on other sites

Sierra's mod senses are tingling.

Oh hey an NFP discussion, something worthy of bringing me back. Glad to see you 'round Nert. Your mod suite is what has kept me playing even in the face of being driven from the community by Squad's console port fever. I will always keep coming back for your work.

 

Testimonial aside, allow me to address the issue.
Fuel Ratios
I agree with the solution of standardizing dry mass/full mass across all tanks of a given fuel type. It seems the most elegant way to do things and means that X units of any given fuel feeding Y engines will always provide the same delta V regardless of the tanks used to provide those X units.
I would balance the value of one over another by cost and by mass (say: argon propulsion setup is, when all is said and done, heavier than an LH2 setup but cheaper, and a xenon setup may offer the most delta V by weight but also has the highest cost per delta V)
Hydrogen NTRs
I honestly think we should deprecate it. At least from my quick head math, I can see no way to make it not lose a ton of performance, and if we can by boosting ISP to the ridiculous, it may begin to compete with the ion engines a bit too favorably. (I sense this may be the case already when paired with the fuel switch patch in Cryo-Engines). I dont see too many options for fixing this without either throwing realism to the wind (which I dont object to) or completely rebalancing the stock tank/engine paradigm (which is far out of the scope of this mod)
Cryo Engines
If NFP hydrogen tanks cannot be properly balanced to encourage vacuum-only use (low impact tolerance, low heat resist, higher drag if possible), then the next best option in my opinion is to simply not enable fuel switching on those tanks. They're not meant to be used on launch vehicles, so why should they be able to be? Instead of trying to make the two mods collaborate gracefully, simply make them coexist indifferent to the other's presence.

Lithium
Lithium is a solid, so would that not give MPDTs a hard limit on their effective lifespan by having an internal solid fuel? I also think that would make them a good bit stronger (perhaps too strong) because of losing most of their tank mass requirement. As for VASIMRs, I played with this mod before they even had the hydrogen mode so I'd really be indifferent to such a change.


Requisite Thermal Questions
I know Street was the one that brought this up, but if you're going to be bringing NFP back from the dead (again :P) then does that mean by any extension that the NFE/HC package will be seeing some love? (the stock game is progressively including more and more stuff to make it easy on you to add these things into it with less and less code work, which as far as I can tell is a very good thing).

Link to comment
Share on other sites

4 hours ago, Captain Sierra said:

Cryo Engines
If NFP hydrogen tanks cannot be properly balanced to encourage vacuum-only use (low impact tolerance, low heat resist, higher drag if possible), then the next best option in my opinion is to simply not enable fuel switching on those tanks. They're not meant to be used on launch vehicles, so why should they be able to be? Instead of trying to make the two mods collaborate gracefully, simply make them coexist indifferent to the other's presence.

Higher drag is possible (though a bit tedious to implement), as I outlined in this post.

Link to comment
Share on other sites

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...