Jump to content

[1.2] Procedural Fairings 3.20 (November 8)


e-dog

Recommended Posts

Hi e-dog,

with SQUAD's release of the World Cup addon, we got the new ModuleBounce module. Do you think you could create a Bouncy Procedural Shell with that? We could land on Duna like that: :cool:

It doesn't have to expand like the real thing, just something that bounces (which is cool) and has a higher tolerance to lithobraking than the other parts :wink:

Link to comment
Share on other sites

is it career mode or sandbox? i know diameter is limited by tech. is length also?

HRMM, that's a good point. I'm just using this new version after upgrading from 2.4.3 and knew about the size issue but figured that was for diameter not length. Well, if that's the case no biggie, I can do separate interstage fairings to cover the rover and the landing struts

Link to comment
Share on other sites

Hi e-dog,

with SQUAD's release of the World Cup addon, we got the new ModuleBounce module. Do you think you could create a Bouncy Procedural Shell with that? We could land on Duna like that: :cool:

It doesn't have to expand like the real thing, just something that bounces (which is cool) and has a higher tolerance to lithobraking than the other parts :wink:

Did you just asked what I asked before and just added video?... lol

Link to comment
Share on other sites

even if thats correct about ksp.exe there are two dlls that contain KSP code, the game code and modules. they are 32 bit. unless there are 64 bit versions you have access to?

To be honest there is no KSP code in any dll. File you are talking about is 64 bit Mono library (the only actual dll being replaced), and afaik, Mono is already pretty much platform independent, with 64 bit lib just allowing to address all memory, but function and codewise - it's same lib.

I believe right now you can get any Unity player game (like, i dont know, Blizzards Hearthstone for example), copy Hearthstone.exe, change the name of Hearthstone.exe to KSP.exe (so player will know where to look for assets and actual data, since KSP_Data folder could be also just renamed to Hearthstone_Data without changing .exe name) and there you have fully working KSP.

Since the version that unified part modules, all game data and assets are being kept in, well, KSP_Data folder. Only "real KSP" data in KSP (duh) is contained in level, mainData and .assets files, and also in GameData files (for parts and plugins). And all the dll libraries contained in Managed are universal, not bound in any specific way to KSP only. So, just as i said before - making a 64 bit "hack" would require some asset repacking and modification, or bytecode injection via some memory managing software (Like game "trainers", or other soft directly overriding memory). That's not the case.

It's really like getting HTML5 game working on 64 bit browser, and that is the reason why it works so well so far.

Edited by koksny
Link to comment
Share on other sites

To be honest there is no KSP code in any dll. File you are talking about is 64 bit Mono library (the only actual dll being replaced), and afaik, Mono is already pretty much platform independent, with 64 bit lib just allowing to address all memory, but function and codewise - it's same lib.

I'm referring to Assembly-CSharp.dll and yes, it does contain game code. Have you done any plugin coding for this game at all? That file is where the PartModule modules are actually implemented. It's where KSP specific physics (orbital, planetary, etc) are implemented.

There's also Assembly-CSharp-firstpass which is KSP, non-game utilities.

Link to comment
Share on other sites

I'm referring to Assembly-CSharp.dll and yes, it does contain game code. Have you done any plugin coding for this game at all? That file is where the PartModule modules are actually implemented. It's where KSP specific physics (orbital, planetary, etc) are implemented.

There's also Assembly-CSharp-firstpass which is KSP, non-game utilities.

But neither files are being modified to run 64bit player, i wasn't really speaking about libs needed to compile solution or run the game, but sure, you are right - that lib actualy contains game code, my bad, have overlooked it since every Unity game contains it too. Point stands - no "hacking" involved, and no code is being tampered to address 64bit.

And as i said, i'm not expecting any modder to support 64bit (hell, i dont expect them to support even x86, these are mods after all), just hoping for someone also using x64 player and mods with decoupling incompatibility to maybe stumble upon this thread and help with forking hotfix.

Edited by koksny
Link to comment
Share on other sites

To be honest there is no KSP code in any dll. File you are talking about is 64 bit Mono library (the only actual dll being replaced), and afaik, Mono is already pretty much platform independent, with 64 bit lib just allowing to address all memory, but function and codewise - it's same lib.

I believe right now you can get any Unity player game (like, i dont know, Blizzards Hearthstone for example), copy Hearthstone.exe, change the name of Hearthstone.exe to KSP.exe (so player will know where to look for assets and actual data, since KSP_Data folder could be also just renamed to Hearthstone_Data without changing .exe name) and there you have fully working KSP.

Since the version that unified part modules, all game data and assets are being kept in, well, KSP_Data folder. Only "real KSP" data in KSP (duh) is contained in level, mainData and .assets files, and also in GameData files (for parts and plugins). And all the dll libraries contained in Managed are universal, not bound in any specific way to KSP only. So, just as i said before - making a 64 bit "hack" would require some asset repacking and modification, or bytecode injection via some memory managing software (Like game "trainers", or other soft directly overriding memory). That's not the case.

It's really like getting HTML5 game working on 64 bit browser, and that is the reason why it works so well so far.

KSP code is mostly in KSP_Data/Managed/Assembly-CSharp.dll, so you're wrong. It's C# assembly of course, not real DLL, but it still can be compiled for 32, 64 bit or "any CPU".

On the issue, I call decouple(0) - that is with zero force and apply forces to rigid body directly, in the impulse mode (so independent of warp). If there's an issue, it's either in Unity itself, or in something KSP does differently in the 64-bit hack that affects physics rigid bodies. I'm not going to fix anything until Squad releases the official 64-bit version though. They didn't because there are issues with 64-bit Unity on Windows, and the hack shows that - some people just get black screen when trying it.

Link to comment
Share on other sites

Any ideas? Using the latest 3.03. It doesn't seem to like the trusses for some reason

Looks like a bug. It would be useful if you can reproduce that with stock parts and PF, and post the .craft files.

Link to comment
Share on other sites

Hi e-dog,

with SQUAD's release of the World Cup addon, we got the new ModuleBounce module. Do you think you could create a Bouncy Procedural Shell with that? We could land on Duna like that: :cool:

It doesn't have to expand like the real thing, just something that bounces (which is cool) and has a higher tolerance to lithobraking than the other parts :wink:

There's a mod with inflatable bags, but I never used it and don't know if it's bouncy.

Link to comment
Share on other sites

But neither files are being modified to run 64bit player, i wasn't really speaking about libs needed to compile solution or run the game, but sure, you are right - that lib actualy contains game code, my bad, have overlooked it since every Unity game contains it too. Point stands - no "hacking" involved, and no code is being tampered to address 64bit.

And as i said, i'm not expecting any modder to support 64bit (hell, i dont expect them to support even x86, these are mods after all), just hoping for someone also using x64 player and mods with decoupling incompatibility to maybe stumble upon this thread and help with forking hotfix.

Clearly there are definitional issues between us as to what constitutes 'a hack'. Neither Softweir nor I said there was any sort of tampering with of the code, or any code insertion. In fact that aspect of hacking is relatively 'new' if you can think of 2-3 decades as new. If you can't accept that, fine, no problem. I will accept your definition of hacking even though I consider it unnecessarily restrictive. Now then.

You came here because you think there's a problem between PF's plugin and the '64-bit-KSP-that-is-totally-not-a-hack'.

If it can be argued that a mod's plugin could have compatibility issues with '64-bit-KSP-that-is-totally-not-a-hack' is it really unreasonable to consider the possibility that the fault could actually lie wifh KSP's own dlls? Which were not meant to run with the 64 bit player and are not currently supported to do so by Squad?

There's a mod with inflatable bags, but I never used it and don't know if it's bouncy.

They were! Are? I think they are part of the Lionhead probe pack.

Edited by Starwaster
Link to comment
Share on other sites

The PF parts do not appear in the tech tree. Bellow shows the Precision Engineering tech node which should have some PF parts but does not. Also is a list of my mods. I am using specifically the Interstellar Mod tech tree (via tech tree loader at the beginning of my career mode) but that hasn't stopped me from installing/uninstalling any other mods. For some reason PF is the only mod that has not worked. Any help? I searched the thread and one other guy has the same problem but it was never resolved.... He tried to edit the saved game file, the tree file but nothing...

zEnfLdP.jpg

PcY2pNc.jpg

Link to comment
Share on other sites

Since upgrading from 2.x to the latest (3.03) I can't get the fairing to separate cleanly. They don't move away from the base any more. They kinda rotate around the base and destroy the upper stage engine any anything close to the base?

Link to comment
Share on other sites

The PF parts do not appear in the tech tree. Bellow shows the Precision Engineering tech node which should have some PF parts but does not. Also is a list of my mods. I am using specifically the Interstellar Mod tech tree (via tech tree loader at the beginning of my career mode) but that hasn't stopped me from installing/uninstalling any other mods. For some reason PF is the only mod that has not worked. Any help? I searched the thread and one other guy has the same problem but it was never resolved.... He tried to edit the saved game file, the tree file but nothing...

Since PF 3.0 the bases are resize-able (they are new parts actually). So they are in Flight Control tech, the first where you get a probe core (Stayputnik).

The maximum/minimum sizes are limited by tech though, but that's not reflected in the tech tree. I guess I'll add fake parts not visible in VAB so people will stop running into this issue.

Since upgrading from 2.x to the latest (3.03) I can't get the fairing to separate cleanly. They don't move away from the base any more. They kinda rotate around the base and destroy the upper stage engine any anything close to the base?

Right-click the side fairing and set ejection torque to 0, that'll remove rotation. I think I'll add lines to visualize fairing ejection motion because it's not easy to get it right. Also the default value for torque and its range might need adjustments.

Link to comment
Share on other sites

Right-click the side fairing and set ejection torque to 0, that'll remove rotation. I think I'll add lines to visualize fairing ejection motion because it's not easy to get it right. Also the default value for torque and its range might need adjustments.

Thank You :)

Link to comment
Share on other sites

Since PF 3.0 the bases are resizeable (they are new parts actually). So they are in Flight Control tech, the first where you get a probe core (Stayputnik).

The maximum/minimum sizes are limited by tech though, but that's not reflected in the tech tree. I guess I'll add fake parts not visible in VAB so people will stop running into this issue.

SOLVED!!!!! You were right, they are in Flight Control. Normally a little green number would appear on the tech node indicating unresearched parts (sometimes happens if you have duplicate parts for w/e reason) and so didn't think to check out Flight Control. THANKS!!!

Link to comment
Share on other sites

You came here because you think there's a problem between PF's plugin and the '64-bit-KSP-that-is-totally-not-a-hack'.

If it can be argued that a mod's plugin could have compatibility issues with '64-bit-KSP-that-is-totally-not-a-hack' is it really unreasonable to consider the possibility that the fault could actually lie wifh KSP's own dlls? Which were not meant to run with the 64 bit player and are not currently supported to do so by Squad?

First and foremost, i dont think there is problem with PF/KAS or any other mod. I thought this is the case before discovering general decouple() incompatibility. And that's clearly on the Squad side to fix. But.

What i'm looking into is making some kind of hotfix for it. A mod for the "64-bit-KSP-that-is-totally-not-a-hack" that would deal with the issue before Squad does (Like, most of the mods do already in other fields), since i'm not only one using 64 bit "hack". By no means i'm expecting mod authors to do anything - just hoping to get other people with same problem look here and maybe get some workaround ideas. I just don't want to wait passively until Squad or someone else fixes it (If ever at all), and since i don't see other people working on it, i'm desperate enough to try working on fix myself hoping it will help other 64 bit users.

On the issue, I call decouple(0) - that is with zero force and apply forces to rigid body directly, in the impulse mode (so independent of warp). If there's an issue, it's either in Unity itself, or in something KSP does differently in the 64-bit hack that affects physics rigid bodies.

Is there any way to debug closer what's happening there? Or just straight code some decouple() replacement? Or is it just out of reach without changing source code itself?

Link to comment
Share on other sites

Is there any way to debug closer what's happening there? Or just straight code some decouple() replacement? Or is it just out of reach without changing source code itself?

decouple() detaches parts into separate vessels, among other things, so it's quite complex and I doubt coding a replacement is reasonable.

The problem is the decoupling force though, not vessel breaking, if I understand it correctly.

Here's what I use to add ejection force/torque in PF:


part.Rigidbody.AddForce(tr.TransformDirection(forceVector)
*Mathf.Lerp(ejectionLowDv, ejectionDv, ejectionPower),
ForceMode.VelocityChange);
part.Rigidbody.AddTorque(tr.TransformDirection(torqueVector)
*Mathf.Lerp(ejectionLowTorque, ejectionTorque, torqueAmount),
ForceMode.VelocityChange);

part.Rigidbody is Unity component for physical bodies which interfaces with PhysX, I suppose.

So either those calls don't work, and it's Unity fault.

Or they aren't called in the first place, probably because there's an exception before execution gets to that code.

Or the body isn't in the right state for some reason (kinematic, "on rails", like when non-physical time warp is active). That's strange though, why would it be in flight?

Or someone (Squad code?) resets any effects of those applied impulses for some reason.

You can check error log for any exceptions at the time of decoupling, to start with.

Link to comment
Share on other sites

SOLVED!!!!! You were right, they are in Flight Control. Normally a little green number would appear on the tech node indicating unresearched parts (sometimes happens if you have duplicate parts for w/e reason) and so didn't think to check out Flight Control. THANKS!!!

It happened to me with other mods too, it's better to check all tech nodes just in case.

Link to comment
Share on other sites

Looks like a bug. It would be useful if you can reproduce that with stock parts and PF, and post the .craft files.

Ok, I think I nailed it down to sub-assemblies. In the first example image, the trusses, landing gear, RCS fuel, thrusters and decoupler were all one subassembly. When I attached it to my rover and tried putting a fairing base on the bottom the fairing would only cover a single truss(as show in the image). When I took off both trusses (just the trusses and attached landing gear) and rebuilt them with parts straight from the part catalog, when I attached the fairing base to the bottom it properly created a fairing to cover the entire craft (including the mirrored sub-assembly at the top I didn't touch).

Link to comment
Share on other sites

I've lost track of what was installed in what order. I was just surprised that the NERVAs would heat up the plate but not other engines. Its not crazy so if this is the intended effect, that's fine.

When did you install Deadly Reentry? It lowers the maximum temperature of parts across the board. And if you attached multiple engines to the plate then they're all dumping heat into it.
Link to comment
Share on other sites

I've lost track of what was installed in what order. I was just surprised that the NERVAs would heat up the plate but not other engines. Its not crazy so if this is the intended effect, that's fine.

Other engines aren't putting out as much heat. You didn't say what other mods you might have, so let's just look at stock values.

The LVN has a thrust of 60 and heat production of 600

LV-909 has a thrust of 50 and heat production of 300

'Poodle' has a thrust of 220 but 300 heat production

'Mainsail' has a thrust of 1500 but only 400 heat production

That's just a sampling to give you an idea of what engines do what. The nuclear engine puts out A LOT of heat. Too much IMO.

Try this:

Make a config file named LVN_heat_tweak.cfg (name doesnt matter; name it what you want)

Edit it and paste the code below into it.

Drop it somewhere in your GameData folder (or do what I do and make a Tweaks folder in your GameData and then drop this in there)

I'm just guessing at the heatProduction; I think 300 is probably good enough. That's about what other engines are and it's also what Real Fuels sets it to for that engine.

Really there's no reason for an NTR to put out any more heat than a chemically fueled rocket when it's in operation. (talking about the solid core rockets like NERVA or Pewee)


@PART[nuclearEngine]:Final
{
@MODULE[ModuleEngines]
{
@heatProduction = 300
}
}

Edited by Starwaster
Link to comment
Share on other sites

For some reason, the tweakable size bar for all of the bases, except for the interstage fairing adapter, is not showing up. And that one is giving me a bar that only goes up to 1.15screenshot93.png

Edited by ABZB
Link to comment
Share on other sites

The maximum/minimum sizes are limited by tech though, but that's not reflected in the tech tree. I guess I'll add fake parts not visible in VAB so people will stop running into this issue.

Sorry if you've answered this already, but currently I can only resize up to 1.5 metres, even though I have 3.75 metre parts. It is slightly annoying. Could you please be a bit more specific how the tech limits the size?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...