linuxgurugamer / FTLDriveContinued

Other
4 stars 4 forks source link

NEED HELP WITH LOADING CFG #13

Closed arekbulski closed 6 years ago

arekbulski commented 6 years ago

I need your support ASAP.

I cant load the properties from CFG anymore and cant find what is the problem there. The cfgs have renamed properties but load as 0, or maybe not load at all.

Code: https://github.com/arekbulski/FTLDriveContinued/blob/8368ff3afc4c9e3f67c47dd406eb96cefa7d3d5c/Source/FTLDriveModule.cs#L82

Screenshot: screenshot4

arekbulski commented 6 years ago

I also found out that KSPField cannot display multiple lines, so info must be split into several KSPFields. If you know this can be done, let me know too.

linuxgurugamer commented 6 years ago

I would need to see the cfg file as well And now you've found out why it isn't a good idea to put so much data into the context menu :-) As you found out, you can't do it,and it get very messy, very quickly.

arekbulski commented 6 years ago

File tree: https://github.com/arekbulski/FTLDriveContinued/tree/8368ff3afc4c9e3f67c47dd406eb96cefa7d3d5c/GameData/FTLDriveContinued/Parts Part used on screenshot is S1 drive.

linuxgurugamer commented 6 years ago

It might just be the isPersitant, but try this: // data loaded from CFG, constants after loading [KSPField] public double generatedForce;

    [KSPField]
    public double chargeRate;

    [KSPField]
    public double chargeCapacity;
linuxgurugamer commented 6 years ago

Or, you might have something misspelled:

// data loaded from CFG, constants after loading [KSPField(guiActive = false, guiActiveEditor = false, isPersistent = true)] public double generatedForce;

    [KSPField(guiActive = false, guiActiveEditor = false, isPersistent = true)]
    public double chargeRate;

    [KSPField(guiActive = false, guiActiveEditor = false, isPersistent = true)]
    public double chargeCapacity;
arekbulski commented 6 years ago

I dont think its possible to missplet it because attributes are statically typed. Would not compile. But I will double check it.

linuxgurugamer commented 6 years ago

Ok, I was able to verify it was spelled correctly in the code

linuxgurugamer commented 6 years ago

So, isPersistant defaults to false, and you've set it true, maybe that's causing the issue

arekbulski commented 6 years ago

Found it. The problem is that these fields are persistant (as set in code) so when you build a ship template in Hangar, those properies are persisted in .craft files. They are NOT reloaded if CFG changes. You get it?

linuxgurugamer commented 6 years ago

Well, yes, I knew that. But the old fields weren't persistant, you made them so.

arekbulski commented 6 years ago

Wrong, those fields used to be persistant. I didnt make them so. https://github.com/linuxgurugamer/FTLDriveContinued/blob/dev/Source/FTLDriveModule.cs#L38

arekbulski commented 6 years ago

Can you tell me how OnLoad OnStart OnAwake differ, when do they fire? There are no tags on Unity classes. I assume OnUpdate happens on every frame.

linuxgurugamer commented 6 years ago

This describes it better than I can: https://forum.kerbalspaceprogram.com/index.php?/topic/123859-partmodule-initialization-sequence-and-order-of-events-interlinking-modules/

linuxgurugamer commented 6 years ago

and you're correct, i was looking at a different piece of code on my phone.

arekbulski commented 6 years ago

Thats so nice, thank you much for that one.

Just FYI found a bug in old code: it seems that gravity forces were sumed over all bodies (eg. mun+planet+sun) but EXCEPT the body over which the vessel orbits (ie. mun). Which is sucky considering that one provides most grav force of all.

arekbulski commented 6 years ago

I found out that KSPField guiname cannot be changed in flight, only its value. Are you aware?

arekbulski commented 6 years ago

Correcting myself, guiname can be changed. I... had a stupid bug in stupid code...

linuxgurugamer commented 6 years ago

Which code did you find this:

Just FYI found a bug in old code: it seems that gravity forces were sumed over all bodies (eg. mun+planet+sun) but EXCEPT the body over which the vessel orbits (ie. mun). Which is sucky considering that one provides most grav force of all.

linuxgurugamer commented 6 years ago

I'm concerned you might be misreading the code. The CalculateGravitation code starts off with the body around which the vessel are orbiting, and then goes up the tree. The orbit.referenceBody which is passed in from TunnelCreationRequirement IS the body around which the vessel is orbiting.

arekbulski commented 6 years ago

Look at the code, and imagine you orbit a Mun. https://github.com/linuxgurugamer/FTLDriveContinued/blob/dev/Source/VesselExt.cs#L120

CalculateGravitation on first depth has body=Mun, so body.orbit.altitude is Muns altitude over planet, not vessels altitude over Mun. Right?

linuxgurugamer commented 6 years ago

The original code initially starts with getting the value for the current orbit here: https://github.com/linuxgurugamer/FTLDriveContinued/blob/b0393504195fb4b3768564f901b611690c31b0b1/FTLDriveContinued/Source/VesselExt.cs#L138 You seem to have removed the retValue line which does the initial calculation

arekbulski commented 6 years ago

Yay seems this was a bug I caused in my own code during refactoring. You are correct.

arekbulski commented 6 years ago

I found something interesting. The fields that are loaded from CFG do not need to be persistent, you just need to not load from using node.getvalue(). This way even existing ships can have their parts updated when CFG are updated.

linuxgurugamer commented 6 years ago

But if they are persistent, then changes to the config won't propogate to the existing ships, and thereby preserves upward compatibility

arekbulski commented 6 years ago

Instead of preseving compatibility it will prevent updating existing ships should such a need arise. You can preserve compatibility by simply not making changes to existing parts CFG.