Jump to content

Sigma Binary


Sigma88

Recommended Posts

I figured as much in the meantime :) So you set the orbital eccentricity of the primary based of the orbital eccentricity of the secondary?

Exactly. The orbital parameters are the same, except for sma and argument of periapsis

Link to comment
Share on other sites

what will never change is the ratio between the primary distance from the barycenter and the secondary distance from the barycenter

Imagine my confusion when I managed to break it:

szFf1t9.png

Restarted, checked configs, checked again, checked logs, recalculated masses and semi major axes by hand, to no avail. Basically, the primary appears to be rotating much faster than it should, even though the displayed speed and all values associated with barycenter and bodies seem to be perfectly fine, as are the logs. It stopped when I uninstalled 10xKerbol (which does not touch the bodies in the screenshot), but I did tons of experimenting on that install so it might be tied to something else too... You haven't seen something like this before by any chance?

Link to comment
Share on other sites

You haven't seen something like this before by any chance?

Never, It depends on what the 10x does I guess. I'll have a look into that.

is this is?

http://forum.kerbalspaceprogram.com/threads/90547

could you send me the cfgs of the planets (and everything else needed to load them) so I can try reproduce the issue?

Link to comment
Share on other sites

Never, It depends on what the 10x does I guess. I'll have a look into that.

is this is?

http://forum.kerbalspaceprogram.com/threads/90547

could you send me the cfgs of the planets (and everything else needed to load them) so I can try reproduce the issue?

It occurred with DunaIke as well, and I just managed to reproduce it with nothing more than 10x (only the 10x folder, no compatibility stuff), Kopernicus, SigmaBarycenter with DunaIke and ModuleManager. I just remembered having some trouble with 64k a while back, it was specifically related to SOI settings not making it into the game - that was related to having finalizeOrbits set to true. I bet that this is the case here too.

Edit: Yeah, its finalize. You might want to include a notice for users of rescale packs, all the ones I played with use it (and I think RSS does too).

Link to comment
Share on other sites

It occurred with DunaIke as well, and I just managed to reproduce it with nothing more than 10x (only the 10x folder, no compatibility stuff), Kopernicus, SigmaBarycenter with DunaIke and ModuleManager. I just remembered having some trouble with 64k a while back, it was specifically related to SOI settings not making it into the game - that was related to having finalizeOrbits set to true. I bet that this is the case here too.

Edit: Yeah, its finalize. You might want to include a notice for users of rescale packs, all the ones I played with use it (and I think RSS does too).

I don't even know what finalize is :D

Link to comment
Share on other sites

I don't even know what finalize is :D

Some Kopernicus configs use a Finalize {} node after the usual stuff in which modifications to PQS are done, among other things. I guess it has something to do with the order in which certain parameters are parsed, but don't quote me on that. Inside the Finalize node, finalizeOrbits can be set to true or false, and while I am not sure what that does exactly, one thing was that it used to keep SOIs from dropping below a certain minimum before we could set them manually. Now on the other hand, having it set to true seems to overwrite all the manual specifications of those, and mess with your binary solution for some incomprehensible reason...

But tbh, I don't how it works either - Lacking documentation my approach to Kopernicus consists of a quick forum search followed by childlike trial and error :D

Link to comment
Share on other sites

Sigma Binary[v1.0.2] is now available

Download

[TABLE=width: 100]

[TR]

[TD]

2I2mqzY.png

@KERBALSTUFF

[/TD]

[/TR]

[/TABLE]

ChangeLog

[TABLE=width: 700]

[TR]

[TD]


[B]v1.0.2[/B]
- Hotfix updating .version file for KSP-AVC compatibility

[B]v1.0.1[/B]
- Hotfix for RSS compatibility

[B]v1.0.0[/B]
- [s]Added compatibility with RSS and other Rescale Mods[/s] not 100% yet
- Added an exception for ISRU contracts on barycenters
- Other minor changes to the code

[/TD]

[/TR]

[/TABLE]

Edited by Sigma88
hotfixed 2
Link to comment
Share on other sites

I'm getting weird things with this and the new version of PluronKhato; could this MM patch have anything to do with it?

@Kopernicus:NEEDS[OPM]:AFTER[OPM]
{
@Body[Pluron]
{
@Orbit
{
@referenceBody = Helios
}
}
}

I don't think that would affect PK in any way.

Pluron and Khato are created as

:FOR[sigmaPK]

so when you apply your patch, (:AFTER[OPM]) there is no Pluron yet

try using :FINAL

should not cause any problems since helios and the sun are identical

Link to comment
Share on other sites

Would this mess up my save if I installed it with the Duna/Ike config right now?

it has the potential

back up the save and check everything before and after installing the mod.

It shouldn't be apocaliptical, but I would need to know what's in your save to be 100% sure.

Link to comment
Share on other sites

The version file included with 1.0.1 is still showing as 1.0.0 and therefore AVC is throwing up that it isn't the latest version upon KSP launch. Nothing breaking but may be confusing for some.

thank you, didn't notice that.

seems like I was a little sloppy on my latest releases :)

I'll put up a fix. Thank you for reporting the issue

- - - Updated - - -

Added an hotfix for KSP-AVC compatibility.

:)

here

Link to comment
Share on other sites

No problem. I use CKAN and it was showing the latest release was downloaded but AVC kept on saying otherwise. I didn't want to touch the files in case CKAN stopped auto-updating it so I'm glad to see you released the hotfix as 1.0.2 on KerbalStuff as CKAN should now pull this down to fix it.

Link to comment
Share on other sites

I have also noticed that contracts generated from RemoteTech contract packs have trouble determining the "Coverage %" when aimed at a Binary System. For example, using:

RemoteTech

Contract Configurator

Contract Pack: RemoteTech or Contract Pack: RemoteTech-Lite

If you try to complete a contract that either points at DunaIke, or for myself with OPM, PluronKhato, the contract dependency of gaining i.e. 20% coverage of that system stays at 0% even when covered by a suitable antenna in Kerbin's SOI. Could this possibly be to do with the Barycentre's 'ghost' size being so large that the antenna is not actually covering any of the Barycentre? I'm not quite sure of the ins and outs of this issue but you may be able to have a better idea of what could be causing the coverage of the Barycentre to stay at 0% coverage, and thus causing the contract to not complete.

I can always go into the debug menu and force complete the contract right now however by using Alt+F12 (Right-Shift+F12 for Linux) for anyone having a similar issue.

Edited by Poodmund
Link to comment
Share on other sites

I have also noticed that contracts generated from RemoteTech contract packs have trouble determining the "Coverage %" when aimed at a Binary System. For example, using:

RemoteTech

Contract Configurator

Contract Pack: RemoteTech or Contract Pack: RemoteTech-Lite

If you try to complete a contract that either points at DunaIke, or for myself with OPM, PluronKhato, the contract dependency of gaining i.e. 20% coverage of that system stays at 0% even when covered by a suitable antenna in Kerbin's SOI. Could this possibly be to do with the Barycentre's 'ghost' size where the antenna is not actually covering any of the Barycentre because it is so large? I'm not quite sure of the ins and outs of this issue but you may be able to have a better idea of what could be causing the coverage of the Barycentre to stay at 0% coverage, and thus causing the contract to not complete.

I can always go into the debug menu and force complete the contract right now however by using Alt+F12 (Right-Shift+F12 for Linux) for anyone having a similar issue.

The barycenter has 1 meter radius, so I have no idea where the problem could be.

The major problem I could see is that you can't ever get a ship inside the barycenter's Sphere Of Influence. So if a contract requires you to go orbit the barycenter you'll need to delete that contract. I am not aware of a way to do that in sigmabinary. If anyone has more experience with this kind of stuff I would be interested in knowing what to do to avoid such contracts being generated :)

If the contracts you are talking about require you to just point an antenna to that body, I don't know why it shouldn't work.

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