MFT issue with configure containers
taterkerman opened this issue ยท 26 comments
Tried making that russian lander, and wanted to use MFT-R tanks. They place and switch shape OK, but when i tried to configure container on them to add some MP, they made a popup window of a bunch of MP sliders (way more than the 4 tanks), and then all right click in the game ceased to work.
New Test/Ships/VAB/rusiian lander.craft
[ERR 19:56:39.143] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:39.145] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:39.145] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:42.073] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:42.241] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:42.242] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:42.527] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:42.528] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:42.529] Cannot find module 'ModuleKISInventory' (-1809747277)
[LOG 19:56:45.900] SSTU-SC-TANK-MFT-R added to ship - part count: 15
[LOG 19:56:45.901] SSTU-SC-TANK-MFT-R added to ship - part count: 16
[LOG 19:56:45.901] SSTU-SC-TANK-MFT-R added to ship - part count: 17
[LOG 19:56:45.901] SSTU-SC-TANK-MFT-R added to ship - part count: 18
[ERR 19:56:48.633] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:48.634] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:48.634] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:48.634] Cannot find module 'ModuleKISInventory' (-1809747277)
[ERR 19:56:51.885] Cannot find module 'ModuleKISInventory' (-180974727
I can upload the craft file if you like.
Works with other tanks as well.
Place tank (i was in 2X symmetry). Configure container, and add MP.
Problem ensues.
Not sure if its related, but I've been seeing a lot of that ModuleKIS spam in my log too, (I don't have KIS installed at the moment). I have no idea if it is related to SSTU though.
The issue isn't the missing KIS bits, it is that all right-clicks cease to function after configuring containers.
That is usually a sign that something is wrong with fuel definitions (or one is defined twice).
Hmm... While it didn't mess up when I added MP to it.... it did mess up when I added EC.
It also appears that the Buttons at the top work fine, it is something with how the text-input boxes are handling the change in resources.
Only appears to happen when using the text-input boxes, and only when adding a new resource that was not previously present.
It happens with all tanks.
Select tank, then use the text field to add something in configure containers. Say a LFO tank, then you add 2 MP (so it's 11, 9, and 2 units of each). It freaks out, and right click stops working.
Is this part even relevant anymore since the spherical MFT tanks were introduced?
Yeah, I have a feeling something changed in 1.3.1 and I'm just finding out now. Not sure that I've touched anything with the fuel tanks/VolumeContainer stuff in many months.
What I really need tested -- is to find out exactly what SSTU + KSP version the problem first manifests in.
When stepping back to KSP-1.3.0 (if possible), does the problem exist with the 1.3.0 compatible SSTU versions?
With that knowledge I can run a diff on the current code vs. the legacy code, and see if it was potentially anything changed in SSTU (doesn't seem likely), or if it is a new quirk introduced to the stock code (for more likely).
(I don't really expect you to do that; but if you felt up for it, that would give me a lot more info to work with).
I have a 1.3 build actually, just not sure what version I have going. Using configure containers is pretty typical for me, so I would have noticed. What are the versions you want tested? I think I have. 1.3 with the early pbr test tank on there... I need to pull it up.
The last KSP 1.3 - SSTU release would probably be the best place to start:
https://github.com/shadowmage45/SSTULabs/releases/tag/0.6.38.142
Indeed, that one little boolean value makes all the difference. No more null-ref spam in the editor on symmetry part updates.
Interesting. Wonder when exactly it broke then? Seems... odd... that it had gone unreported for so long.
I have a couple ideas of things to investigate -- notably, it doesn't have a problem if you use the MP button to add the ratio -- it is only the text-box input that causes problems. I'll have to compare what those two bits of code are doing differently, and likely push the text-input to use the button-based update methods. (I'm pretty sure they all do the same thing on the backend, which is quite boggling as to why there would be a difference between the button/text-box inputs)
Yeah, it's probably just rare to use symmetry to make a service module. I was trying to make that Russian lander, and since I used the Soyuz orbital module, I had no choice but to add the MP that way. I've never even used the buttons, I always use the text fields (because I will sometimes keep the ratios and use different numbers to get what I want for MP/EC, etc.
I'll check 1.2.2, I have one of those, too.
1.2.2 as well.
Loading 1.1.3, lol. (slow as my old versions on on my external, backup drive (USB2---least it's an SSD)).
Hmm... that seems.... odd... but I believe your findings. Wonder just how far back it goes?
(More than likely some stock code changed in one of the KSP updates, as the VolumeContainer system really hasn't seen any changes since it was first developed)
Please let me know what you find out, and thanks for doing testing on it.
Edge case, I've been using SSTU rather a long while, and I never found it until trying to make that russian thing. Given I usually use SSTU crew vehicles that have their own RCS propellant, it just never came up.
Hahaha, I think I may have found the cause. Quite a stupid (and minor) error on my end, if it turns out to be what I think it is.
Basically, when doing development I wrote a method container.updateResourceRatios(resource, newRatio, bool updateSymmetry = false).
Note the default parameter on the end. If the parameter is not specified at the place where it is called, it will use the default value. I probably tacked the parameter on later after the method was written, but added the default value to 'not break existing code using the method' (which was where it went wrong; had I broken the existing code, I would have gone to the place where it was called, and put in the proper boolean value). Normally I don't use default values (to avoid precisely this problem).
Will do some testing on it later this evening to see if it is cleaned up.
One small line of code, missing one word, is probably causing all of this fun :)
container.module.setResourceFillPercent(container, resourceName, fillPercent);
becomes
container.module.setResourceFillPercent(container, resourceName, fillPercent, true);
And I believe the problem should be solved.