Dunbaratu

Is it supposed to be nearly impossible to find a safe place to mount the 2HOT thermometer where it will be occluded from heat and therefore not blow up? In the screenshot below I placed several of them atop the command pod, and a few on the side, hoping that at least ONE would survive re-entry but none ever do. They always blow up even when well occluded by the rest of the craft. (As a result I had to take a penalty and fail a temperature scan contract for a location "under 17000m" on the other side of Kerbin from the KSC. It's impossible to make a thermometer survive the re-entry, as far as I can tell. Other items can be occluded and survive. I can put a battery on top and it survives. I can put parachutes on top and they survive, but the thermometer just can't be saved, it seems. Did something change about how the occlusions are calculated?

I'm having problems doing the first contract because the game keeps freezing when I hover the mouse over the Applauncher toolbar to bring up the contract parameters. Sometimes the game freezes for about 10 seconds then comes back to life and other times it freezes for good and I lose my progress because I have to kill it and re-run the game. This only happens when I've accepted that first commsat contract (the one where you have you put up 3 equidistant satellites > 600,000m all in contact with each other. If I hover my mouse over the contracts button when that contract is not currently active and thus not in the list, it doesn't freeze. Newcomm_02 Debris Unloaded (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.findLocalCenterOfMass () [0x00000] in <filename unknown>:0 at ProtoVessel..ctor (.Vessel VesselRef) [0x00000] in <filename unknown>:0 at Vessel.Unload () [0x00000] in <filename unknown>:0 at Vessel.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.findWorldCenterOfMass () [0x00000] in <filename unknown>:0 at Vessel.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.findWorldCenterOfMass () [0x00000] in <filename unknown>:0 at Vessel.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.findWorldCenterOfMass () [0x00000] in <filename unknown>:0 at Vessel.FixedUpdate () [0x00000] in <filename unknown>:0 I keep getting that message over and over and over at about the time there's a hang. I should point out that Newcomm_02 has not crashed, and is not "debris" so I don't understand where that first message is coming from.

Am I the only one getting this message constantly spewing to the log? NullReferenceException: Object reference not set to an instance of an object at Clouds.Clouds.Update () [0x00000] in <filename unknown>:0 I'm assuming that with a class called Clouds.Clouds, it must be coming from this mod and not some other (although it won't tell me the filename so I don't know for sure). It happens all over the place, especially after any scene change (i.e. flight to space center to VAB etc).

I believe the problem is intractable in the current release of kOS. I've made an issue for it here: https://github.com/KSP-KOS/KOS/issues/575 - - - Updated - - - Can you make an issue requesting the enhancement over on the github?

Imagine code that's doing this: Up front, it queries FlightGlobals.vessels, and goes through it looking for a subset of the list of vessels matching a criteria. It stores that list. Now the mod has some variables which are references to vessels. In the next update, it starts working on that list of vessels. But there's a timing issue. One of them might have just gone away and been blown up. But the vessel handle won't be null. It will now refer to a stale vessel which SQUAD has cleaned of most of its useful stuff (so most method calls on it will blow up with exceptions), and the only reason the vessel is even still there is because of my code's reference keeping it from getting orphaned. I'd like to drop the vessel from the list by detecting that it now refers to a vessel that's been disconnected from the rest of the data structures and is now floating off in space wanting me to orphan it. What's the API to detect that state? To detect "this vessel isn't a real vessel anymore. Don't try to use it." Is it Vessel.state == Vessel.State.Dead? Is that the meaning of "dead" there or does "dead" mean something else?

can you show what the error is, preferably from the output log? - - - Updated - - - by the way, put the wait 0.01 before the LIST TARGETS IN contacts. You are getting the list in a different update from when you query its members

@VentZero: This may be an intractable problem. As a further debug test, try printing out contact:name at the top of each run of the loop, then you can see which one it was working on when it bugged out (i.e. was it the debris, was it the missile, etc).

Actually, looking at the code again I'm surprised it ever worked at all even prior to the vessel blowing up. VESSEL is the name of a function call. Function calls in kOS are allowed to skip the parentheses and it means the same thing as having no arguments in the parentheses. (so VESSEL:FOO is the same as VESSEL():FOO). So when you say FOR VESSEL IN RADAR you create an ambiguous override where VESSEL means two things at the same time. It apparently is taking it to mean the variable first, but ...it is weird that it works.

Weirdly I also just did this from gitbash: $ find C\:/Program\ Files\ \(x86\)/Steam/steamapps/common/Kerbal\ Space\ Program/ -name '*.dll' -exec grep -i 'unit test' '{}' ';' And got zero hits. (Translation - none of the DLL files I have anywhere under KSP's folder contain the phrase "unit test" in any case-insensitive combo (i.e. not "Unit Test", nor "UNIT TEST", etc). I have no clue where it comes from. I did the same check on all the EXE's (KSP.exe) and also found no hits there either.

I'm pretty sure no. The phrase "unit test" never appears in the kOS source code. (Although it has some unit tests, it never mentions them in a string anywhere like that so it can't be what's printing them to the screen.) - - - Updated - - - I have the message. I do NOT have B9 installed.

I found a way around it, but it's weird that I have to do this: Without remotetech installed: There are two different user interface ways to tell it to transmit science: 1 - When looking at the popup for "review report" click the blue "transmit" button. <or> 2 - Right click the antenna part, click "transmit" from there. With Remotetech installed: Technique #2 goes away. But technique #1 still works, I just discovered. So it's not changing a thing about what is and isn't possible - just removing one of the two ways the user interface lets you get to it. That just seems weird to me.

I've only just started using remotetech after a long hiatus. This may be a really basic question: Is remotetech *supposed* to prevent antenna from being used to transmit science data? Early in a career game I put up a satellite with a goo container to get one of those "transmit any science from space around kerbin" contracts, figuring I could piggyback my first comm sats with that contract by sending a thing with a goo canister and some antennae. But once in space, even when I have a connection to the ground and am allowed to control the craft, the "transmit science" option is missing from the antenna part menus.

Hmm. It's probably the fact that the FOR loop takes longer than one update to run. So you query the list of targets, put it in radar, and then start working with those targets one at a time, and in the meantime one of them is gone but you still have a reference to it. Does the Vessel:LOADED check work as a protection check? Hmm. That's still an awful lot of places to have to check it even if it does. I'd recommend using WAIT 0.01 to force an update sync right before you take your readings, then take all your readings at once into variables (i.e. SET BEARING TO VESSEL:BEARING, and so on, rather than mentioning VESSEL:BEARING over and over). So maybe this would work? FOR VESSEL in radar { WAIT 0.01. IF VESSEL:LOADED { SET VDIST TO VESSEL:DISTANCE. SET VBEAR TO VESSEL:BEARING. SET VALT TO VESSEL:ALTITUDE. SET VAIR TO VESSEL:AIRSPEED. SET VNAME TO VESSEL:NAME. // /|\ // | // put the rest of your loop in here, using the values above instead of direct queries. // | // \|/ } I can't guarantee that working, because I don't know how Vessel:LOADED will behave here, but it might work as a check. We may need to create an additional suffix for vessel if it doesn't - Vessel:EXISTS. (Because I can see a scenario where the vessel exists but as a far away object (packed into a single point on the map view, not loaded as a full list of parts), so some suffixes still work (like distance), but not others (like :PARTS). It may be necessary to let a script differentiate those two conditions.)) Behind the scenes, because your script causes us to have a C# reference pointing to the vessel, that means the vessel object doesn't really get orphaned and go away when it crashes. It's still in memory, but now many of its methods won't work right. We might need a way to detect that situation and report it to the script. - - - Updated - - - Another idea I'd been tossing around a while is to just make an "ATOMIC" keyword, or some sort of equivalent, like so: line 1. line 2. ATOMIC { line 3. line 4. line 5. line 6. } line 7. line 8. line 9. And what it would mean is "Force the section containing lines 3,4,5, and 6 to occur within the span of one Update, even if that means exceeding CONFIG:IPU by a bit." It would cause a wait 0.001 just beforehand, then start a new fresh update at line 3, then stick with it until like 6, even if it goes past config:ipu instructions to do so. The reluctance I have with that is that it may create infinite hang of KSP if a script is designed badly, or we might have to enforce that no looping is allowed inside such a section. But at any rate the name would have to be something besides "ATOMIC". "Atomic" means something to experienced programmers that communicates exactly what the section would do, very well, but would be quite confusing to a typical player who's going to think it's got something to do with atomic engines. One of the kOS design goals is to make it easy for a person new to programming to get ramped up to speed without having to be an expert. I fear that throwing around terminology like "atomic section" might be contrary to that goal.

Your whens could interrupt your main code at any time, even in the middle of those for loops where you are incrementing flout. So you could have a case where two iterations of the same loop do a flout = flout +1, and have one trigger kick off in between the two, thus making the second flout = flout + 1 trigger the second trigger. example: there are two flamed out engines. you do the for loop. On one iteration you do SET flout to flout +1, and flout is now 1. Then the first trigger catches this and fires turning flout back to 0. Then on your second iteration of the SAME loop you do the second SET flout to flout + 1, and a second trigger catches that. It would be inconsistent behavior because it would depend on exactly when you've exhausted CONFIG:IPU instructions and thus a new Update interrupts your flow. If that happens exactly in the middle of the for loop, the scenario I describe can happen. In general, you should be thinking like "threaded" programming when using WHEN triggers. Remember they could get called any time. If they read a variable your main program fiddles with, try to keep your main program's alteration of it instantaneous and all at once. for example, have the for loop work on a temp variable, say, tempFlout. Then after it's done adding it all up at the bottom of the loop, then in one single statement say SET flout to tempFLout.

I've always seen it, even in a stock install.

Yes. There is no upper limit, other than what framerate you can tolerate working with. (There is a 'diff' algorithm at work that gets more expensive the more characters wide the screen is. I haven't profiled its expense yet, but having about 5 different 80x24 terminals open at once seemed fine, so it's probably not a problem.) This is impossible to diagnose with just looking at the whens only. The code that turns on the flout condition isn't shown making it impossible to see why the existing behavior is supposedly wrong. If flout was turned on exactly twice it would make sense.

I didn't see anything in your list that wasn't possible already with kOS, although since we didn't want to make it specifically JUST for IR, but for all mods, we did it in a generic API way. 1. Part Naming: kOS provides this for any part in the VAB (not just IR parts) http://ksp-kos.github.io/KOS_DOC/general/nametag.html 2. position, speed, and loading. Anything any mod (including IR) decides to show you on at part's rightclick menu can also be read by a kOS script. It won't let you look at something not on the display panel, but that's because we can't read the minds of other mod makers and guess what internal data they are okay with exposing. Making it appear on the display menu is proof that they're okay with exposing it. I think the things you want to see can easily be shown on the part menu if IR wants them to be. 3. Well, the fact that kOS can do these things is sort of proof that a plugin can do them, isn't it?

Yes. If you scan the video to the very last few seconds of it and freeze frame it there you can see a still screenshot of me doing just that. Not yet. Not directly. It's a future idea I have but I wanted to get it released with the minimum functionality first. The minimum goal I had was "Make the telnet window able to do exactly what the in-game terminal already can". Color requires a bit of thought because it means deciding whether or not the in-game terminal should have it, whether we want to consider terminal capability to be a tech-tree upgradable thing, etc.

kOS Telnet. The pull request is in and now we're working on getting it all merged in nicely:

*clap**clap**clap*. Very helpful to have these.

The cost of the access via the suffix chain varies depending on the suffixes in question. It's sometimes quite expensive, and sometimes negligibly small, but it's never quite zero. (Due to the way suffix calls are built at the moment, the more suffixes a term has the more expensive it is to create it. One of the more expensive calls is VESSEL("vessel name here"), because any creation of a vessel object needs to build up about 30 suffixes to attach to it, and also getting the vessel from KSP in the first place means doing a sequential walk of all the vessels in your saved game and checking each name. In a new saved game that's quick, but by the time you have hundreds of "flights" in progress (Flags and debris laying on the ground aren't "flights", dammit SQUAD!) it gets more expensive to say Vessel("name") and you should really just do it once up front and then keep it in a variable from then on. It's almost always more efficient to store a long suffix chain into a single variable, but often not by enough to matter. Most of our examples show the whole chain just because they make more legible examples that way. You can see in a glance where the thing we're talking about is found in the API that way. But beware of premature optimization. Often the legibility you are sacrificing is worth more, in the long run, than the speed you get by doing it. Especially since KSP is doing an enormous amount of work 30 times a second or so anyway. The extra cost you're putting on it by your kOS script is often tiny. The only really expensive thing relative to the rest of KSP is the act of initially parsing and compiling the script. If you have a longer script you may have noticed KSP's animation hiccup a moment when you first type the RUN command for it. kOS is, literally, trying to perform an entire parse and compile within the span of one single animation frame. It doesn't have the sophistication to split that activity up into more than one animation frame to smooth it out. (That's a lot of work. You'd have to retain the whole state of the parser and partly built ML code halfway through and resume it where it left off. It's unlikely that we'll ever fix that soon, as there's bigger fish to fry.) To give an example of why the expense of your kOS code probably doesn't matter too much, consider this: Roughly 10-15 times a second (*), kOS has to re-draw the *entire* screenful of characters in each open terminal. It's going through an entire 2D array of 50x36 chars (more after my terminal resizing stuff is released) and individually looking up each one for its matching subset of the font image file to find the right picture for that character, then tiling that part of the image to the right position for it on the terminal, even when it hasn't changed since last animation frame, its still re-doing that. This is how Unity requires that GUI's be made. They have to be re-drawn over and over or they disappear (in fact that's how you erase a button or a bit of text - just skip over the part of the code that's been drawing it.) Compared to that, what your code is doing is going to probably be small potatoes. (*) - GUI windows are drawn less frequently than your framerate, but still quickly enough to be responsive to user actions. - - - Updated - - - As for the problems with vectors, I admit I haven't looked at that part of the conversation too carefully over the last few days. I've been sort of glossing it over, spending my kOS time on the cool thing I want to add about telnet instead. Partly its because I'd like to have a working version of it around to be able to let the people at /r/ksptomars/ use it, as I think it would be perfect for what they're trying to do. If the problem isn't solved by the time I finish with that I'll come back and have a look at it in more detail.

Just a heads-up to people writing kOS scripts. I'm sure we can all understand that given some of what SQUAD wants to do with aerodynamics in the next release, that it will affect some calculations. Here's one thing that affects people even if they're not making airplanes but are just making rockets. http://forum.kerbalspaceprogram.com/threads/110229-Thrust-scaling-with-atmosphereic-pressure-instead-of-Fuel-Flow-rate-Yay!?p=1726681#post1726681 (nutshell: a throttle of 0.5 will no longer necessarily mean 50% of maxthrust anymore.)

Looks like people using kOS will probably have to redesign the logic of some of their scripts. (not that it's a bad thing). Currently, the knowledge that, say, 30% throttle means you get 30% of your max thrust has made certain calculations a lot simpler than they realistically would be.

A Teaser. This stuff isn't ready yet. There's a lot of weird edge cases I have to work out (like having the telnet open when you switch scenes back to the space center, tends to keep the server still connected to the now missing kOS computer). But I'm getting close. I can feel it's sooooo nearly done.

Yeah I'm a bit unclear myself about whether that's good or bad. On the one hand consistency across all of kOS is a good idea and degrees are used everywhere else to keep things easy for the non math-nerds. On the other hand radians are usually mathematically better for most things.