Closed arekbulski closed 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.
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.
File tree: https://github.com/arekbulski/FTLDriveContinued/tree/8368ff3afc4c9e3f67c47dd406eb96cefa7d3d5c/GameData/FTLDriveContinued/Parts Part used on screenshot is S1 drive.
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;
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;
I dont think its possible to missplet it because attributes are statically typed. Would not compile. But I will double check it.
Ok, I was able to verify it was spelled correctly in the code
So, isPersistant defaults to false, and you've set it true, maybe that's causing the issue
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?
Well, yes, I knew that. But the old fields weren't persistant, you made them so.
Wrong, those fields used to be persistant. I didnt make them so. https://github.com/linuxgurugamer/FTLDriveContinued/blob/dev/Source/FTLDriveModule.cs#L38
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.
This describes it better than I can: https://forum.kerbalspaceprogram.com/index.php?/topic/123859-partmodule-initialization-sequence-and-order-of-events-interlinking-modules/
and you're correct, i was looking at a different piece of code on my phone.
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.
I found out that KSPField guiname cannot be changed in flight, only its value. Are you aware?
Correcting myself, guiname can be changed. I... had a stupid bug in stupid code...
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.
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.
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?
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
Yay seems this was a bug I caused in my own code during refactoring. You are correct.
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.
But if they are persistent, then changes to the config won't propogate to the existing ships, and thereby preserves upward compatibility
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.
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: