Dunbaratu

I can save you a little wasted time trying to find out what "you" are doing wrong by pointing out that we've discovered you might be hitting a bug in the kOS code that we've had a very hard time reproducing with enough regular consistency to be able to track it down and find the exact cause of it. It has something to do with KSP firing off one of its automated "quicksave" events while a kOS program is running code. The code that KSP fires off in kOS during the autosave is the same code that it triggers when you save&quit, but there's something about it happening during autosave that makes it trigger the problem, but not consistently, and not all the time, which is why we've been having a heck of a time tracing it down to fix. You seem to have a case where the problem actually does happen all the time, but it's wandering around exactly *when* during the code it happens because of precise timing alterations. We're trying to fix it, or at least find a way around it. In the meantime, can you save us a snapshot of what your stuff looks like right now while the problem is still reproducible so we can use it to try to solve the problem? The inability to reproduce it regularly has been the problem on our end and you seem to have a case where it reproduces all the time. Oh, and changing this setting temporarily might help you work around the problem until we get it fixed: Open your settings.cfg in your KSP folder, and change this line: AUTOSAVE_INTERVAL = 300 Setting a really big number there instead. This is the number of seconds between autosaves and setting it really big is the only way to effectively disable KSP's autosave, since they didn't put that setting on the user interface screen.

@MaxP, Can you look at your log file (on windows it's under KSP_Data or KSP_Data_x64 if you run 64 bit, and in either case it's called "output_log.txt" It has a different name on Mac and Linux for some weird reason (ask Unity why, it was their idea to change the name depending on OS for .. some reason). This specific error message ("reference not set to...") *probably* indicates some problem that's not your fault but is the mod's fault *usually, not always* that is the case with the "reference not set" error. Can you either post the log, or if you don't want to because it's enormous (it usually is), can you show the... ohh.. say 100 lines or so above and below all the places where it has the string "NullReference" somewhere in the log? And on another note, not at all related to the crash (probably): you don't really need to keep re-issuing the LOCK commands over and over again in the "until periapsis > 640000" loop. That's sort of the point of a lock is that they are always reset to the formula all the time, dynamically on the fly. You could probably issue those commands once, and then just wait until periapsis > 640000 doing nothing, and it would have the same effect.

v0.3 Now ready for kOS when kOS Fields released? A lot has been fixed up and redone about the low-level numeric approximation algorithm (the "PQS raycast solver"). That's the bit that deals with the fact that none of KSP's built-in APIs actually find raycast intersections with the terrain when the terrain is far away and thus not "fully" loaded. (Even though some are named as if they would, they don't. They only find intersection with the sea level sphere under the terrain.) Changes to the homebrewed PQS raycasting algorightm: **tighter +/- error level**: When the terrain is far enough way not to be fully loaded, so that my PQS aproximater raycaster has to be used, the new "epsilon" is 2 meters. (This is the accuracy level for the numeric approximizer. When it gets a value within 2 meters of the right answer it quits and gives you that. It used to be 5 meters). **less hogging of the limited CPU time**: When it has to fallback to the PQS approximate raycaster, it now limits its CPU usage based on how LONG it's taking rather than on other guesses. It actually watches a stopwatch and limits itself to a thin slice of the total time one physics update is meant to take - so other mods and the main game can have their time too. **algorithm can now spread across updates**: To allow less hogging of the CPU time, it now can store its state in the algorithm and then come back to it in the next update tick. So when the time is exceeded and it doesn't have a good answer yet, it now waits for the next update to pick up where it left off. This means that getting an answer can sometimes now take a few updates to obtain. A manual player won't see the difference, but an autopilot script needs to know about this. New fields on the rightclick panel: **CPU hog** - a number from 2 to 20 - editable - This lets you set the balance between getting answers fast versus being nice to the rest of the game and trying not to take too much time during an animation frame. If you want faster updates to the Distance readout, set this higher. If the mod is stealing your framerate and becoming a problem, set this lower. If you want to permanently change this value and not constantly adjust it, change the setting ```CPUGreedyPercent``` in the part.cfg file for the laser. **Update Age** - integer - readonly - How many animation frame updates has it been since the value in the Distance field was up to date? If this value is bigger than zero, then that means you are looking at slightly stale data. In normal operation it should be zero when near the terrain, and then when higher up it will spin from 0 to 1 to 2 to 3 to 4 or so and then back to 0 again - very fast. This lets you know how slow your updates are from the solver. If you want quicker updating, you have to set **CPU hog** higher.

I strongly suspect that the reason the "X" key is handled differently is in some way related to the fact that you can use it from the Map View even when the navball isn't showing. (Normally to use ship controls from the map view, you need to enable the navball tab on the map first. But the "X" key will kill throttle from anywhere, anywhen, as an emergency measure.) To do that SQUAD had to keep the "X" key out of the ControlTypes.THROTTLE set of keys, but then they appear to have forgotten to include some other control flag somewhere that does include it. It seems to be utterly outside of any of the ControlType bitflags.

The biggest argument against using Steam Workshop is the fact that I heard is one I totally agree with, and that is that it allows a mod developer to develop for ONLY the Steam portion of the KSP userbase if they so choose, and that's not an option that SQUAD wants modders to have as it splits the community into haves and have-nots, and worse yet the ones who are the "have-nots" in that division include all the *earlier* adopters who were loyal customers who got into this fun quirky little startup game from the early days before it was on Steam. Steam Workshop isn't like Curse or KerbalStuff or any other hosting method that's allowed because it's specifically only for people who have the game via Steam and isn't an open-ended site that can be used by all owners of KSP universally. Sure a lot of people don't like using Curse and don't want to, but that's not a decision that's attached to *Paying out money* like not wanting to have to re-buy the game on Steam is. I concur totally with this decision and applaud SQUAD for it (despite being a Steam user myself who got the game from Steam). Things would be very different had the game *started* on Steam and stayed there, then it might have made more sense to go with Steam Workshop because there'd be no splitting of the community that way. However, it occurs to me that there *IS* perhaps a solution to that problem that is maybe being overlooked here: Lots of mod hosting sites have rules and checks the mod packages have to pass through to be allowed to be hosted there. Often they have to include a description file with version and so on. Often they have to pass a virus scanner. Often they have to include the license in a certain format. What about the rule "To be hosted on Steam Workshop, a KSP mod must include a URL link to a site where the exact same package file is hosted outside of Steam Workshop and is publicly accessable." Then it could be automatically enforced even, by having the mod package upload process automatically try to fetch the package from that URL and checksum it versus the mod being placed into Workshop to ensure they match. To check against cheating by a mod writer putting up the package on a website just long enough to pass the test and then removing it, it could be part of the regular daily update checks Workshop might perform - keep rechecking that URL and make sure the package is still there and is still checksum-equal to the one on Steam. Such a rule would enforce that if a mod writer wants to use Steam Workshop, they aren't able to try to *exclusively* use Steam Workshop as the only place their mod is available from, which as I understand it was SQUAD's main objection to the idea.

Well, the Game settings keybindings kludge does seem to work, I'm still trying to figure out why I have to resort to it. It's an ugly hack and it seems like it's a band-aid around something in the API that feels a bit broken. Specifically, the game settings hack is to change the user's key bindings from the Settings screen temporarily, then put it back to whatever it was later. Like so: When the terminal window gains focus: rememberThrottleCutoffKey = GameSettings.THROTTLE_CUTOFF; GameSettings.THROTTLE_CUTOFF = new KeyBinding(KeyCode.None); When the terminal window loses focus: if (rememberThrottleCutoffKey != null) GameSettings.THROTTLE_CUTOFF = rememberThrottleCutoffKey; This hack works. It just seems like it shouldn't be necessary. All the *other* keys get trapped properly by normal Unity GUI widgetry, just not "X".

Okay, now I've used the ALT-F12 debug menu to view the lock being created by the terminal. This is the code that does the lock - it's just trying to lock ALL things: InputLockManager.SetControlLock("kOSTerminal"); And yet, it still doesn't lock the "X" key out. "X" still gets seen by KSP and kills the throttle before KOS ever sees it. No other keys have this problem. Here's the screenshot showing the input locks - note all the bits are set to 1: And it still killed the throttle when I typed "X". If "Z" gets implemented the same way "X" was, then this will ruin our mod when 0.25 comes out. Help! I've seem other mods that allow you to type "X" and it doesn't kill throttle. How?? is there no way to do it unless you use a Unity GUI textbox? That's going to be a problem since we're trying to manipulate the terminal manually and can't let Unity's textbox do the work.

Beware, the last time I tried using LOCK WHEELSTEERING to a heading, I discovered a bug in the steering code that caused it to drive in circles when you try to drive exactly due north. I don't remember if the fix ever made it into the code or not, because this was way back when the project was being rearranged and moved to a new github location so it might have gotten lost on the way. Give it a try and see if it works. The problem was, essentially, that it just tried to turn left if the current compass heading was higher than desired, or right if the current compass heading was lower than desired. When you are just a *little* bit to the left of 0 degrees, your heading is not -0.001 degrees. It's +359.999 degrees. The code thought "oh noes, I need to turn 359.999 degrees to the left to correct this. I'm *really* far off."

Yes. wrappers around the various string manipulators like substring, toupper, and so on would be nice. It might be a good idea to wait until there's such a thing as methods wrapping things in kOS (upcoming future feature) so we can make it work like it should (var.toupper() rather than toupper(var)).

Is it possible that the problem is that Orbit is rejecting values that are geometrically impossible because other fields you aren't setting are defaulting to values that contradict your settings? (i.e. imagine if you set the eccentricity to 1.5, but don't set the orbit's periapsis and apoapsis values.) Could it be that instead of altering periapsis and apopasis to match eccentricity, it's actually just rejecting the values you're giving it for being contradictory?) Similar interdependencies between the values exist throughout the Orbit object's fields and properties, and it looks from the API as if it does not enforce the guarantee that you can only set the values in ways that are geometrically possible. Because KSP allows a lot more setting of public fields than it probably should (a lot of things it does with fields should really be wrapped in properties or method calls), it allows users of the API to create logically bogus sets of values.

In the kOS mod, we respond to keypresses when our terminal window is focused. But one frustrating thing is that even when the window is focused, KSP itself still gets first dibs on the 'X' key and it uses it to kill the throttle before allowing the keypress to pass through to our mod. So while someone *can* type a command like "SET X TO 1." in the terminal and it works, doing so will have the side effect of killing the throttle when they get to the "X" key. Currently this only seems to happen with the "X" key and no others. If the user types "SET WASD TO 1.", then the "WASD" part has no effect on the piloting, as we'd prefer, and the spaces don't cause staging, and so on. Only the "X" key has this problem because it seems KSP is doing something different with it than it does with all the other piloting keys. Until now this has been just slightly annoying. But there's rumors that soon the "Z" key will go full throttle in stock, and if that's true then this same behavior would really screw us up big time there if SQUAD implements the "Z" key the same way they've implemented the "X" key (which seems likely). So we need to find a solution before 0.25 is out. Any ideas?

It's literally impossible for it to BE any higher on the TODO list than it *already* is. It's debatable whether or not it's a good idea to announce publicly too much about the inner managing of a software project, as doing so often builds misunderstood anticipation hype in people's minds, but since people have been clamoring for this particular feature for a while now, and I've been talking it up, I figure I owe an explanation for the delay. The reason there's been a delay is that the feature requires adding some language infrastructure underneath that kerboscript was missing, namely the ability to use suffix terms as function calls, like this for example: SET FOO TO LIST(). FOO:ADD("val0"). FOO:ADD("val1"). FOO:ADD("val2"). FOO:ADD("val3"). FOO:ADD("val4"). print FOO:SUBLIST(1,2):LENGTH. The work on the interface for reading part menu fields had to be halted until that underlying language feature was implemented first. Thankfully, as of late last night, I got the first potential experimental version of that language feature ready to merge in (but be warned it hasn't really been fully tested yet so there's a chance it can be found lacking and need more work). Barring any further unforeseen problems with it, I expect to be back to working on the right click menu thing probably this weekend when I'll have all of Sunday free to spend "in the hacking zone" for it. But again, be warned, that's *IF* something serious isn't found to be wrong with the suffix function call feature. I tested it fairly well myself but there may be use cases I hadn't thought of. Long Version, for any computer programmers out there who can follow it: Basically, we were missing the ability to pass arguments into the code that suffix terms run, which would allow them to behave like methods. Adding this required a major change to the grammar definition that shuffled the parse tree layout around. Anyone who's ever written parser code before knows that when you do that it has consequent effects on the code that percolate all down through the system so it's not a small task. It's the sort of change that breaks hundreds of assumptions all over the place that the code was silently making without those assumptions being documented. As the person who actually wrote the grammar parsing system in the first place no longer has free time for the project, this fell to me to do. Since I didn't know where all those secret assumptions were, many of them snuck up on me by surprise. Often a change would cause an error in a seemingly unrelated part of the system because the change violated an unstated assumption the code was making that I was unaware of, so it wasn't a quick thing getting it working.

I like this idea, and the "payload" requirement could be a simple list like so: part type foo, min=1, max=99999 // payload must contain at least 1 instance of part foo. part type bar, min=0, max=0 // payload must contain NO instances of bar. followed by some global properties it must adhere to (sums, rather than just talking about 1 part): resource: ElectricCharge, min=1000, max=9999999 // payload must have at least 1000 electriccharge on it. resource: liquidfuel, min=80, max=99999999 // payload must have at least 80 units of liquidfuel on it. mass: 3 // payload must be at least 3 tons. followed by some orbital properties it must adhere to: apoapsis: min=70000, max=800000 periapsis: min=70000, max=800000 body: kerbin The contract would generate a set of conditions like that for the payload, and give you the contract that says you must launch a ship in which at some point you have detached a piece of vessel that fits those criteria.

You have a few problems here happening at once: 1 - You are trying to do a wait in a trigger body. You can't. The Wait command is just ignored there. Therefore when the first trigger sets the flag "set t to 1." it might get seen by the second trigger during the *same* update, making the two triggers still run without giving the KSP game engine time to change the state of the ship in reaction to the stage command. (In a nutshell, you can't wait during a trigger because a trigger has to end entirely within one animation frame update, and the smallest possible granularity on a wait command is that it will wait at least 1 full animation frame.) A better test to give the behavior you're looking for is to check the current elapsed time TIME:SECONDS and record it during the first trigger and then have the second trigger wait for the condition where TIME:SECONDS is now a bit after it. Like so: set trigTimeStamp to 0. when stage:liquid fuel < 0.001 then { // do staging code here set trigTimeStamp to TIME:SECONDS. } when trigTimeStamp > 0 and TIME:SECONDS > trigTimeStamp + 0.01 then { // do ISP code here. } That will ensure that at least one tick of game engine time has passed between the first trigger and the second, because during the same tick of game engine time, TIME:SECONDS will remain frozen at the same value. 2 - The trigger body must not contain much code because it needs to finish deterministically fast within one update. Adding loops to a trigger condition can be very dodgy for this reason. You aren't showing the main body of your program here - only the triggers. I suggest that you put the looping logic that's inside your ISP calculating trigger into the mainline code instead and have it get triggered by a flag each time the mainline code iterates a loop. Presumably your main code has a loop in it that is always going during the flight. Put the check there, and trigger it like so: set trigTimeStamp to 0. when stage:liquid fuel < 0.001 then { // do staging code here set trigTimeStamp to TIME:SECONDS. } // main body of code presumably has a loop in it that always runs. until something { if trigTimeStamp > 0 and TIME:SECONDS > trigTimeStamp + 0.01 { set trigTimeStamp to 0. // turn this back off again so it won't happen twice. // put all your ISP logic here instead of in the trigger. } else { // your normal flight control stuff here } }

But beware that kOS only actually runs correctly while the ship parts are loaded into the full game engine, not when the ship is *elsewhere* on rails. That makes it hard to both have kOS running the launch of one vessel and at the same time have the other vessels on the pad still running their kOS software to watch for timings.

Please use [ code ] instead of a nested [ quote ] to embed your code examples. It works much better with "reply with quote" that way. Nested quoting doesn't work on this forum. Even when clicking the "multi quote" button it still won't do it. I see one potential problem in that script: if eng:ignition="true" Eng:ignition returns a boolean. Comparing a boolean to a string is a bit of an unreliable result because of issues with case sensitivity (when eng:ignition is converted into a string for the sake of the comparison, does it use the value "TRUE" or "true" or "True"? It matters because string comparison is case sensitive). A more reliable result is to just use the boolean as-is directly. Don't add the term ="true" when that's what using the bare boolean on its own already means anyway (and in fact is more reliable that way because of how boolean algebra works when the value isn't a boolean but is a plain number being treated like a boolean.) A boolean value can be the entire expression, like so: if eng:ignition // delete the = "true" part { .. do stuff .. }

I've narrowed down the "PartModule indexing mismatch" message to only being caused when I've compiled a new DLL for kOS and installed it and then tried running a saved game that already had existing vessels in it with kOS parts on them that are loaded into full physics because they're parked within 2.5km of the launchpad. I think I am seeing two unrelated errors. Because I still get the slowdown even when that message goes away. It seems that launching a new vessel when one already exists within the "physics radius" of the launchpad or runway has both of these two unrelated issues: 1 - It prints messages to the log about mismatched Partmodule indexing if there was a kOS.DLL install update between the launching of the old and the new vessels. 2 - It creates enormous lag and kills frame rate if the old vessel had ever had any kOS commands executed on its terminal, regardless of whether there was a kOS.DLL update or not. Even using the same kOS.DLL as before triggers the problem. Also, if the previous vessel had no kOS commands run on it, there is no lag, even when kOS.DLL was updated between launches. So they seem to be two utterly disconnected things.

Not at the moment, but it is a good idea to take under advisement. A lot of languages let you fill arrays with a syntax a bit like this: v = {23, 371, 5, 17}. maybe kOSscript could be modified a bit to support something a bit similar.

A couple months ago we (current kOS devs who've taken over from the original Nivekk) had a video chat in which the topic of the kOS terminal window and it's strange implementation came up. One complaint had been that the current system is utterly un-remotable. It can't really work with terminal emulators on telnet or ssh because of the simple fact that the terminal "i/o" is implemented in a totally non-i/o way. It doesn't read a stream of keypresses, for example. It reacts to GUI keypress events. It doesn't use any sort of escape sequences to manipulate the screen. It just stuffs values directly into the screen's framebuffer when you do something like "print x at (30,10)." It also manages commandline editing with a sort of second framebuffer superimposed on top of the normal one. We'd been talking about a pie-in-the-sky plan to gut the innards of the system and replace it with a true terminal emulation - a layer that traps keypress gui events going to the terminal and feeds them into a Stream object that the terminal reads from, plus a layer that forces all interaction to go through a Stream that has special control codes for terminal manipulation. That way the input/output Streams could be redirected to hook up with an internet socket and make external terminal programs work over something like ssh or telnet. As a bonus, since we'd be making up the terminal manipulation codes ourselves from scratch, there's no reason we couldn't use codes from an already well known terminal like VT100 or ANSI and therefore allow any one of the plethora of terminal emulators that uses that standard work with kOS. One new potential developer expressed an interest in getting started on part of this but we never heard anything since from him so I don't think that's going anywhere right now. There are a LOT of issues to deal with in kOS and at the moment only two people actively putting major amounts of time into it, so we have to do a lot of triage and stop a lot of pie-in-the-sky "wouldn't it be cool if...." projects while more important things are worked on. When dealing with a mod that is essentially an entire programming language and an entire virtual computer, the number of *potential* features is endless and just about anything that's NP-complete (*) is technically possible. So it would be very easy to get stuck trying to implement 100 different things and only getting each one 1% done. So sadly the desire to have it use a stream-able i/o for internet use, while a valid concern, has fallen down below that cutoff mark. But if you're offering to research the feature yourself and make pull requests to the kOS code to implement it..... I for one would be delighted. Or if you just want to talk about how you see potentially the bridge between kOS and your terminal working if it did something else a bit different from what I've described, that would be cool too. (*) - I originally said "anything is technically possible" until I remembered a recent feature proposal that would have required the mod to know if a script has an infinite loop...

If you want more realism you probably need to be *really* realistic and use raw steering using SHIP:CONTROL and make the steering correction code yourself, instead of relying on LOCK STEERING which is a bit of an unrealistic crutch to help new users along.

More likely an unsupported browser issue. Safari tens to adhere to minimum standards and no more with none of the many extremely ubiquitous but technically nonstandard browser features supported. Often if a website works for all browsers except for one, that one will be Safari. Not because Safari is technically wrong, but because it interprets one of the open-ended parts of a W3C standard in the least useful way possible.

Not as far as I know. It was just plain vanilla Safari/OSX, stock, no mods.

I just tried resetting my password by having it e-mailed to me (New browser. I'd been relying on the old browser's cookies to log me in for too long and had forgotten the password.) I eventually got it reset, but the user interface is *really* broken in the following way: I clicked the button to reset your password. I get a form to type in my e-mail address, and type in a string from a captchca image. I fill in the fields and click the button. I get a response that claims my captchca string didn't match the image. I click the button to try again and enter a new captchca string for the new image I get. Again I get the response claiming my captchca string didn't match. I repeat again. By the fourth time I carefully am typing the string in one character at a time, looking again and again and again to verify it's the same, and it fails again. The fifth and final time I try the audio captchca instead, listen for the string, type it in, and again it claims the string didn't match and now I figure I'm locked out for 15 minutes. But then I notice there was a message in my e-mail. I got the notice the first time, it turns out. It had worked on the first try and accepted my input despite giving me the message claiming it hadn't. As far as I can tell, it appears to be falsely giving a bogus error message about the captcha string being a mismatch regardless of whether it was accepted or not.

3 good wheels plus 1 broken wheel is still 4 wheels.

I get game-breaking lag when there's a vehicle within 2.5km of the space center and I try to launch a second instance of the same craft design on the runway. I'm doing this to try to diagnose a problem in kOS, but I can't get to the part where I diagnose the problem because of the game-breaking lag (My FPS is about 1/10 - That's one animation frame every 10 seconds) that happens whenever there's two instances of the craft both in existence within the loaded sphere (and annoyingly it doesn't happen with two vessels in orbit near each other - only when I launch to the runway does this happen.) The only clue I have what's going on is this utterly inexplicable message in the output_log corresponding with loading the craft into the SPH editor: ("PartModule indexing mismatch at....") I have no clue what a "PartModule indexing mismatch" is supposed to mean or what on earth I do about it. ------------------- initializing editor mode... ------------------ (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) editor started (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [Part]: PartModule indexing mismatch at kOSMachine0m, index 0. Node 'ModuleLight' found in loaded data, but 'kOSProcessor' is defined in prefab. Looking for ModuleLight in other indices... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ...ModuleLight module found at index 1. (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [Part]: PartModule indexing mismatch at kOSMachine0m, index 0. Node 'ModuleLight' found in loaded data, but 'kOSProcessor' is defined in prefab. Looking for ModuleLight in other indices... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ...ModuleLight module found at index 1. (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Modular Rover KOS test loaded! Later on, I get this message when the vessel is actually launched to the runway: "PartModule <modulename> at <part name>, index <number>: index exceeds module count as defined in cfg." And I get it for several different <modulename>'s and several different <part name>'s and several different <number>'s, spamming the log. I've looked and I can't figure out which "cfg" file it's referring to, and which config setting is being exceeded. Here's a small sample of the part in the log where it first starts: [Part]: PartModule ModuleAeroReentry at dockingPort3, index 1: index exceeds module count as defined in cfg. Looking for ModuleAeroReentry in other indices... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ...no ModuleAeroReentry module found on part definition. Skipping... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) PartModule is null. (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [Part]: PartModule ModuleAeroReentry at landerCabinSmall, index 7: index exceeds module count as defined in cfg. Looking for ModuleAeroReentry in other indices... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ...no ModuleAeroReentry module found on part definition. Skipping... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) PartModule is null. (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [Part]: PartModule ModuleAeroReentry at batteryBank, index 0: index exceeds module count as defined in cfg. Looking for ModuleAeroReentry in other indices... Does anyone have a clue what on earth this message is trying to tell me?