Let's have a "modders warn each other about mod-breaking 0.24 changes" thread.

[Dunbaratu]

I figure there must be some things that the 0.24 API changes will break here and there in various mods, and over the next several days there's going to be a lot of modders discovering them the hard way.

To help ease the pain, I thought it made sense to start this thread where modders can post anything they discovered in their own mods that they had to change for 0.24 - to help other modders get their mods updated faster without having to do the same trial-and-error discovery themselves.

I don't have anything to post yet - I'm going to play stock 0.24 for a while first to get the feel for how it works, so I know which changed behaviors in a mod are correct and which aren't.

(To clarify: This thread isn't for making use of brand new features - like adding a button to the stock toolbar or adding customizations to the contracts. This is for "this code used to do X in 0.23.5, but now in 0.24 it does Y instead, and I had to change it in this way to get it to do X again."

Edited July 18, 2014 by Steven Mading

[Virtualgenius]

You mean a thread like this http://forum.kerbalspaceprogram.com/threads/55401-Community-Mods-and-Plugins-Library that shows you whats updated to 0.24

[FlowerChild]

You mean a thread like this http://forum.kerbalspaceprogram.com/threads/55401-Community-Mods-and-Plugins-Library that shows you whats updated to 0.24

No. The thread you just linked to is largely for players. It looks like this thread is intended for modders to give each other a head's up about what's changed internally with KSP, which sounds like a good idea to me.

I'll post anything I come across here as well. So far the only compile error I ran into with BTSM was due to a the onGUIRecoveryDialogSpawn GameEvent being renamed or removed (for obvious reasons), but I've just temporarily disabled that bit of code for the time being while I work on other stuff, as it was non-critical.

[NathanKell]

I know crew objects got changed a fair bit, but I'll let TaranisElsu (who knows about that) chime in.

I do know, though I forget who discovered this, that MonoBehaviour defaults to having its bool enabled member be false. You need to set it = true in Start() or various methods (including OnGUI!) won't be called.

[Diazo]

I do know, though I forget who discovered this, that MonoBehaviour defaults to having its bool enabled member be false. You need to set it = true in Start() or various methods (including OnGUI!) won't be called.

I must be misunderstanding what you mean. I use monobehavior like this:

 [KSPAddon(KSPAddon.Startup.Flight, false)]
    public class TWR1 : MonoBehaviour

Source code link

to start my Vertical Velocity mod and I did not have to change my code anywhere to set any sort of enabled bool. All my methods seem to work fine, including the GUI, so I'm not sure what this enabled bool is supposed to do.

Having said that, to actually contribute:

FlightControl: Seems to be no changes. RCS, pitch/yaw/roll, and throttle control all worked without any code changes.

PartModules Save/Load: Seems to be no changes. Note that I always explicitly call SetValue and GetValue inside the OnSave and OnLoad commands though as I was never able to get the automatic saving of KSPField values to work correctly even back in 0.23.5 (I retract this statement, see my new post.)

ActionGroups: Seems to be no changes to how action groups are saved to a part and how they are invoked.

What I've found so far for what it is worth.

D.

Edited July 29, 2014 by Diazo

[blizzy78]

I do know, though I forget who discovered this, that MonoBehaviour defaults to having its bool enabled member be false. You need to set it = true in Start() or various methods (including OnGUI!) won't be called.

This seems to be wrong. I have never used MonoBehaviour.enabled, and OnGUI() is still called.

[Greys]

There are two new overloads of Part.RequestResource(), now offering a third argument to override flowMode; thus negating the reason for flowMode to have been defined at the resource level.

RequestResource(int resourceID, double demand, ResourceFlowMode flowMode)RequestResource(string resourceName, double demand, ResourceFlowMode flowMode)
public enum ResourceFlowMode{	NO_FLOW,	ALL_VESSEL,	STAGE_PRIORITY_FLOW,	STACK_PRIORITY_SEARCH,	NULL}

This change was made to allow the Verner engines to override the flow mode of LFO and the option is provided by ModuleEngineFX, but ModuleEngine uses one of the four other RequestResource()s that does not offer this third argument.

[Padishar]

AvailablePart.cost used to be an int and is now a float.

Not sure if it is new but PartResourceDefinition.unitCost gives the cost per unit (as a float) of a resource for working out how much partially filled fuel tanks cost.

[Dunbaratu]

Some kOS users just found one today. I don't think I'd ever heard of this complaint before 0.24 so it might have been introduced with the Unity engine update underneath 0.24.

In 0.24, the Unity engine underneath is returning the wrong values for some keypresses when you examine their unicode char values.

When processing a Keydown event, Event.current.character is supposed to be the unicode character corresponding to the keypress. But on specifically the Linux build, and the Linux build only, the RETURN character, which should be producing the unicode character 0x000d (ascii 13, CR, with leading zero high byte to turn it into unicode), is actually being returned as 0xff0d instead of 0x000d. (the padded high byte of the unicode character is all 1 bits instead of all 0 bits). Thus checks like this:

if (Event.current.character == 13) { do stuff }

don't work right on the Linux build. Because the character is coming back as 0xff0d instead of 0x000d, it's not the value 13(decimal), it's the value 65293(decimal).

I made the workaround of detecting if the high byte of the unicode is exactly FF, and if it is, then replace it with 00 instead, figuring that none of the unicode characters from 0xff00 through 0xffff are actually characters that would ever correspond to a key on any keyboard in any language. (They're full-width line-drawing font characters for use when you want to print characters that touch each other edge-to-edge without any space between them, like for box drawing. They're not characters that exist on any keyboard, unless you've somehow managed to run Kerbal Space Program on a Commodore 64.).

[Diazo]

I'm going to retract my statement about partModules being unchanged.

In my actions group mod I have several users reporting issues that logging shows is tracked back to the mod's partModule being missing.

As I use the partModule for data storage this is a critical issue and I've gotten enough reports that I am moving my data storage to a scenarioModule for the next version I release.

I am unable to replicate this on my machine, but it seems to be that KSP's partModule loader is fragile and once too many mods start messing around with partModules, especially adding/removing them in code rather then with ModuleManger (so they are not in the protoModule library) seems to cause partModules to be lost.

The specific example that brought me to this is that I use ModuleManger to add my AGXModule to every part on game start, this has worked fine since KSP 0.22 and been rock solid until 0.24 came along.

Now, when people reporting this problem post there log files, the log files show that my AGXModule is not present on the part when my plugin goes looking for it. Therefore I believe KSP's partModule loader is screwing up, or being screwed up by another mod.

Either way, I can't trust a partModule for data storage at the moment so I'm moving everything to a scenario module.

Does anyone else do extensive work with partModules that is seeing something similar? Notably things resetting to default (which would be the partModule going missing, then being re-added back in by code during the loading process).

D.

[Padishar]

I'm going to retract my statement about partModules being unchanged.

I thought the bugs in module loading/reordering was what Squad fixed in 0.24.1...

[Diazo]

I saw that in the patch notes myself and was hopeful it would tighten things up. (There are some other, minor issues I'm having with partModules that I worked around that I was hoping had been fixed.)

However, whatever they did has resulted in my partModule where I store my data going missing. As-in, the module is just gone from the .craft and persistence file, not reset to defaults.

This is reliably reproducible by different people using my action groups mod (although I am unable to replicate it on my machine, it seems to require a certain number of mods installed that conflict with each other) so I am certain enough in what is going on that I posted about it here.

D.

[DMagic]

Does anyone else do extensive work with partModules that is seeing something similar? Notably things resetting to default (which would be the partModule going missing, then being re-added back in by code during the loading process).

I've had a few reports of partModules not being applied to parts with an IVA the way they are supposed to be. I'm fairly certain this is due to the module manager config and load order issues. Normally this just throws an error and prevents saving of SCANsat map data from IVA screens, but a few people have seen crashes that seem to be caused by this.

I think you're right that using partModules for persistence storage when the partModule isn't actually integral to the part is a bad idea. I intend to transfer all of this storage over to the SCANsat scenario module and hopefully get around this whole problem.

[Diazo]

I think you're right that using partModules for persistence storage when the partModule isn't actually integral to the part is a bad idea. I intend to transfer all of this storage over to the SCANsat scenario module and hopefully get around this whole problem.

I'm not sure the integral partModules are immune either. There are reports in the bug forum of ships magically refilling their fuel tanks which I would suspect is caused by the resources module being wiped and recreated. (Not tested or anything, but sounds logical to me.)

Either way, I'm moving to the scenarioModule for data storage also, that should be more reliable.

D.

[Dunbaratu]

It's possible that Squad did do something to fix the PartModule loading problem in 0.24, but that what they did might require a code change that wasn't properly explained to modders when it was released, so the problem is improved in the stock game's PartModules, but is ironically actually making the problem effectively worse in mods that still do things the old way.

However, whatever they did has resulted in my partModule where I store my data going missing. As-in, the module is just gone from the .craft and persistence file, not reset to defaults.

Sadly, because kOS has always had messy problems with the kOS computer state (i.e. variables in the pretend computer's memory) not reloading correctly, the fact that it doesn't work right after 0.24 tells me nothing - because it was buggy before 0.24 already.

Does it only seem to affect cases where people dynamically added the PartModule at runtime to the part? Does it work okay for cases where the part.cfg file itself is hardcoded to use the PartModule? (that's the case for kOS and LaserDist - the two mods I've had my fingers in - kOS CAN be added to a part with ModuleManager, but only if the user does it themselves - the mod no longer ships with those configurations enabled because we had too many problems with it even in the past.)

[Diazo]

For adding the partModule, I took the brute force approach and use a modulemanager script that adds my data storage module to every part in the LoaderDatabase.

Because of that, I don't add my partModule in code because I know every part will have it already.

Which is how I know the partModule is vanishing, the log files have what are effectively "partModule not found" errors all over the place from the people reporting this. That includes people who the mod worked on KSP 0.23.5 so I know they have modulemanager and the part.cfg script file installed correctly.

I have speculation about what is going on, notably the fact that there are messages in the log about a partModule not being found and replaced, but the bottom line is I can't trust a partModule to save data anymore so I'm moving it all to a scenarioModule.

D.

[Dunbaratu]

Has anyone reported this as a bug to SQUAD? It seems pretty major, given that PartModule has API methods to be called for OnSave and OnLoad, to have a situation where you can't actually persist the data.

Have you tried looking at the persistence save file on disk to see what it's actually writing out when you save and quit the game? That might give clues about what's going on, since it's normally supposed to store the PartModule's data that way when you load/unload a vessel.

For example, here's a snippet of a vessel in the savefile that has a kOS part on it - this is the part of the file storing the kOS computer part:

			PART
			{
				name = kOSMachine1m
				uid = 3130583856
				mid = 3160650642
				launchID = 0
				parent = 1
				position = 0,-0.461709976196289,0
				rotation = 0,0,0,1
				mirror = 1,1,1
				istg = 0
				dstg = 0
				sqor = -1
				sidx = -1
				attm = 0
				srfN = None, -1
				attN = bottom, 3
				attN = top, 1
				mass = 0.12
				temp = -175.5791
				expt = 0.5
				state = 0
				connected = True
				attached = True
				flag = Squad/Flags/default
				rTrf = kOSMachine1m
				modCost = 0
				EVENTS
				{
				}
				ACTIONS
				{
				}
				MODULE
				{
					name = kOSProcessor
					isEnabled = True
					diskSpace = 10000
					MaxPartId = 100
					RequiredPower = 0.1
					EVENTS
					{
						Activate
						{
							active = True
							guiActive = True
							guiIcon = Open Terminal
							guiName = Open Terminal
							category = Open Terminal
							guiActiveUnfocused = False
							unfocusedRange = 2
							externalToEVAOnly = True
						}
						TogglePower
						{
							active = True
							guiActive = True
							guiIcon = Toggle Power
							guiName = Toggle Power
							category = Toggle Power
							guiActiveUnfocused = False
							unfocusedRange = 2
							externalToEVAOnly = True
						}
					}
					ACTIONS
					{
						Activate
						{
							actionGroup = Custom09
						}
						Deactivate
						{
							actionGroup = None
						}
						TogglePower
						{
							actionGroup = None
						}
					}
					harddisk
					{
						capacity = 10000
						volumeName = 
					}
					context
					{
						variables
						{
							gt0 = 1000
							theta0 = 0
							gt1 = 50000
							theta1 = 90
							maxq = 7000
							solidthrust = 1000
							liquidthrust = 430
							b = Kerbin
							mu = 0
							rb = 600000
							soi = 84159286
							ad0 = 1.2230948554874
							sh = 5000
							ha = 69077
							lorb = 80000
							euler = 2.718281828
							pi = 3.1415926535
							tset = 0.0339023084802981
							ralt = 31.9084739685059
							tign = 158.499999999858
							t0vsm = 1592.02330798716
							t0 = 1753.00213134636
							drag = 3.55079036339349
							theta = -89.9998993748686
							ar = 53151.25
							dt = 51.054667705775
							vsm = 1595.21901562825
							exp = -10.6302496743923
							ad = 2.95665986071201E-05
							q = 37.619412217597
							vl = 6300
							vh = 7700
							dv = 25.317020411188
							da = 3.15866273197437
							ta = 26.155287415735
							ga = 8.28037904523618
							dc = 0.0107218905712116
							arr = 0.999326849489796
							pda = 1.11805701491496E-06
							alt = 80000
							vom = 1709.09521461651
							r = 669089.06619147
							ra = 680070.156316288
							va = 1658.47870757092
							a = 462533.177782449
							r2 = 680070.319430686
							a2 = 680035.159715343
							v2 = 2278.73482559418
							deltav = 620.256118023264
							x = NODE(1875.23204280658,0,0,620.256118023264)
							nd = NODE(1875.23204280658,0,0,620.256118023264)
							maxda = 26.2232454284736
							dob = 23.6528898527336
							t1 = 1863.40559788021
							oldwp = 0
							rt = 0.232024883524446
							wp = 0
							tvar = 0.101480078682016
							np = R(0.024,194.344,0)
						}
					}
				}
				RESOURCE
				{
					name = ElectricCharge
					amount = 4.99933333330167
					maxAmount = 5
					flowState = True
					isTweakable = True
					hideFlow = False
					flowMode = Both
				}
			}

In your case, is it not even saving the MODULE section at all to the file? If so then that's the bug, and that's how it needs to be complained about to SQUAD, I think.

Edited July 29, 2014 by Steven Mading

[Starwaster]

I saw that in the patch notes myself and was hopeful it would tighten things up. (There are some other, minor issues I'm having with partModules that I worked around that I was hoping had been fixed.)

However, whatever they did has resulted in my partModule where I store my data going missing. As-in, the module is just gone from the .craft and persistence file, not reset to defaults.

This is reliably reproducible by different people using my action groups mod (although I am unable to replicate it on my machine, it seems to require a certain number of mods installed that conflict with each other) so I am certain enough in what is going on that I posted about it here.

D.

This sounds like a similar conversation we've had in the past.

How is the PartModule being added and what version of Module Manager? Versions of MM pre-2.2.0 will delete PartModules that were dynamically added regardless of what data they were storing.

Admittedly there might be a problem going on with 0.24.x's new module fixing code but you don't even have to look there for potential problems as Module Manager has been a culprit in that regard long before 0.24

Edit: I strongly advise removing Module Manager from the equation when testing for this if you really think it's Squad's new code that's at fault. Use a testing environment that doesn't even include Module Manager and only add PartModules via edited part files. I really cannot understate the capacity for Module Manager to destroy persistant data (prior to version 2.2.0)

Edited August 1, 2014 by Starwaster

[Diazo]

Okay, here is the logic process that I followed to cause me to decide I can't trust partModules for critical data storage any more.

KSP 0.23.5

Using moduleManager I add my AGX partModule to every part using a simple @PART[*] wildcard. This is rock solid and I never have any issues with the partModule itself.

I require Modulemanager 2.0 or newer since several weeks before KSP 0.24 is released.

KSP .24 is released and I see an upsurge in people reporting data loss and other weird behavior in my mod. I try troubleshooting and add more and more logging to figure out what is going on, until in version 1.12 I finally add enough logging to make me realize the fact that my partModule is missing.

These reports include people who have been running my mod on 0.23.5 for weeks without issue, so I know they have moduleManger version 2.0 or newer and the correct part.cfg for moduleManger to process.

To be clear, the partModule I add to every part via moduleManager with a part.cfg has been working for months is not present when I try to refer to it in my code.

I can state this with 100% certainty because of the fact that I add my partModule to every part means that I assume my partModule is present and I never run .addModule() in code in any version of my mod.

Therefore at some point between the initial game load where moduleManager adds my partModule, and actually using that partModule in the flight or editor scene, my partModule is being deleted.

Therefore I can not use a partModule for reliable data storage. Even if I go and add an error trap to add my partModule back in via an .addModule() I still lose all my saved data as adding the partModule back in will reset the partModule's data values to defaults.

(I suspect this issue is partially masked by mods that check for the partModule and if is not present add it back in. In this case the partModule would still be present, it would just have its values reset to defaults which looks like a "did not save correctly" error, rather then a "partModule was deleted and recreated" error.)

I don't know what Squad has done to their partModule loader module, but even on their own partModules I think they are having problems. I saw a bug report about a vessel's fuel tanks refilling to full when returning to it after a while, that I would strongly suspect is caused by the FUEL module being lost and then being re-added with the default of full tanks.

So, that's where I'm coming from. I don't trust partModules for data storage any more and I'm switching over to scenarioModules for that.

D.

Edited August 1, 2014 by Diazo