Dunbaratu

Yes but the point is there should BE no overlapping polygons in which to even HAVE Z-fighting. I suspect that the coordinates of the attachment points are slightly INSIDE the mesh model, causing the two parts to overlap a bit. Except it's not a new problem. There are two entirely different problems being reported: 1 - part just vanishes with no explosion, causing things to become detached. 2 - there is an explosion When I mentioned the possibility of intermingled parts clipped into each other, that was for trying to find an explanation for problem 2, not problem 1. The exceptions in the log correspond to problem 1 - they are causing the part to fail to be finished being created so KSP skips creating the part. KSP is not very fault-tolerant of exceptions thrown by PartModules. They tend to abort the creation of the part itself that they're attached to.

Yes that. If program 1 does "SET X TO 5." and then runs program 2, and program 2 does a "SET X TO 10" then, there was only ever 1 "X", and Program 2 just changed Program 1's X from 5 to 10. I mean global in that sense. However, is there is ALSO a variable X on a completely different SCS part, then it shouldn't be affected.

Thanks for this. Not for the mod itself (which is slick) but for introducing me to the fact that the API has calls to return the current Waypoint data, and where they are. I want to let people writing kOS scripts make rover drivers that can seek the waypoint as a goal and I had no idea how to read the latitude and longitude directly from contracts. After digging around the API for a while trying to find it, I noticed this thread and went "oh yeah duh". It never occurred to me to just ignore the contracts system and instead just let users select the waypoint and then have kOS read the current Waypoint.

I've suspected for a while now that there's something off about the SCS part model's coordinates. I've noticed that when I attach two of them stacked together, there's visual texture "garble" at the spot where they join, as if their join point was actually being overlapped. The problem is that when we took over from Kevin Laity when he went missing, the only thing that was checked into the GPL3'd source code was the EXPORTED model file for the SCS part, not its original Unity source file. This makes it a bit hard to pull it into the unity editor and have a look at it. (It's a bit like trying to fix a bug in a mod when all you have is the compiled DLL file and not the source CSharp files.) (Basically, KSP uses its own homebrewed model files that it *exports* from Unity and has you put into you plugins. This is generated by a tool SQUAD provides to modders called their "PartTools" unity exension. If all you have is the result of that export, and not the original files unity read, then I'm not sure how to actually look into the problem.) It may be the case that solving it will require just ditching the current part model entirely and making new ones from scratch. My problem is that this gets into an area I know very little about. My training is on the programming end of things, not the graphic design end of things.

But that does not solve the problem I wanted solved. It makes it even worse. The problem is that I want to USE the station I made after I made it.

Variables already should be local to the vessel. If you found a case where a script running on one vessel causes a change to a variable on a different vessel, then that's a really major bug. The only exception to this is the CONFIG: variables, which are written out to kOS/Plugins/PluginData/kOS/config.xml and affect the entire plugin. Every OTHER variable should only exist on the one vessel that's running it (more so, it should only exist on the one SCS part that's running it. Two kOS computers on the same vessel should have their own distinct set of variables from each other). You could if you put two SCS parts on the same vessel. I have not yet tried to see what happens if you try to put both of them in control of their shared vessel, and give them opposing commands (like having one LOCK STEERING TO PROGRADE while the other one does a LOCK STEERING TO RETROGRADE.) I have no idea what that would do. I never tried it. I'm thinking most likely both would try to tell KSP how to set the ship controls, and KSP would end up obeying whichever set of controls it was told about last, effectively ignoring whatever the first one said to do. One program can call another program (you can use the RUN command from inside a program). And that's a LITTLE bit like having function calls...uh.. sort of. All variables OTHER than the parameters passed to the RUN command are global, though, which is the thing I thought you were talking about.

The big problem with the 'build a station' and 'build a ground outpost' contracts is that they completely ignore that the whole REASON you make such stations is to *re-use* them. In career mode you just make a station, leave it there, make another one, leave it there, and make another one, etc. What would make a lot more sense is this: 1: Have the game track the fact that you already have an outpost of a particular type (for example, have it know that there already is a Kerbin low-orbit station, a Kerbin high-orbit station, and a Minmus low-orbit station). For the idea outlined here to work it would also have to track if such a station goes away too. It doesn't matter if there WAS a station once, but rather what matters is whether there IS one at the moment. 2: Only generate a "new" station contract when there is no such station already fitting the contract you were about to generate. 3: If there is a station already fitting the contract goals, then instead of generating a new-station contract, generate one of the following stationkeeping maintenence contracts for it: 3.1: Crew exchange mission: Send up a vessel to the station. Add crew from the vessel to the station, and from the station to the vessel. (They don't have to dock. They can just rendezvous nearby and EVA to each other if you like.) As long as the sum of all crew that went from A to B plus all crew that went from B to A is bigger than mission parameter N, it's enough. (That way you can use the mission to add, remove, or change crew - you don't have to just swap one for one and thus keep the crew count identical). Mission contract will only be considered complete when the vessel is landed back on Kerbin again. Crew onboard vessel on its return trip must survive to count. 3.2: Add Fuel Mission: Count total current mass due to fuel in the station. Call it Fmass_old. Keep counting total current fuel in station. Call new fuel level Fmass_new. When Fmass_new >= (Fmass_old + M), consider the contract completed. Don't bother checking anything else - just that. It will mean, add M fuel to the station, by any means you like (which will of course have to mean sending up another vessel full of fuel and docking with it - either to transfer the fuel or to just leave the docked module there as part of the new, larger station.) 3.3: Expand station mission: Look at what the station currently has on it. Make a mission to add some specific parts to it. (i.e. if it's electric capacity is low, ask to add more electriccharge to it (bring up a battery module). If it has no science lab, ask to add one. If it only has one size of docking port, ask to add other sizes of docking port. If it has a small amount of habitation, ask to add more habitation.) Those are the general ideas. Once the station is there, let the player KEEP using it for more missions later rather than just making it once and then throwing it away.

Is reputation affected by astronaut death? If not, it totally SHOULD be. A LOT. It would thematically make sense and be a fun challenge and help that 'roleplay' experience. Killing off a kerbal in a crash landing would then *mean* something concrete, and maybe give you a good reason to fit that escape tower to your launch vehicle. It might make sense to make the amount of effect slide based on difficulty level - make it more consequential in hard mode.

Local to what? I've thought that local variables sort of need function calls first. - - - Updated - - - Well, that's a good point. I remember when college courses were taught in mostly Pascal (that will date me). And that was a terrible language. The problem is that while Pascal made it hard to write bad code, it ALSO made it hard to write good code. The exact reasons why are off topic here. (This is where I just deleted two paragraphs of verbose crud here before posting.) It might be worth thinking about, that's true. One thing that KerbalEDU would make me do is change my thinking about what the nextmost important topic for me to work on would be. Up until now I've thought that once 0.90 is fully squared away the next enhancement to kOS I should devote time to should be the remotable terminal, which also brings with it keyboard input/output (they're sort of tied together into the same code). But if kerboscript were to become an educational tool, then maybe proper function calls really should come next. But yeah, the more I think about it, one of the big problems with trying to teach kids to program is how early textbook examples are all doing something really really boring to a kid. No kid gives a darn about averaging numbers, or finding the areas of circles, or balancing a checkbook. But I started learning on my dad's Commodore 64 in the basement in the 1980's (again, dating myself here) and one of the first major things I made was a BASIC program to do a little Zork-like text adventure. Granted it wasn't a very good text adventure, but it caused me to learn some programming design patterns that I didn't even realize HAD already been well described and had been given names (i.e. I first made the rooms map as a giant 2D array where most of the locations were dummy (i.e. to go north from room(4,5) you end up at room(4,4), decrementing the second index of the array). But this was really inefficient and ate up all the memory fast as I grew the adventure and made the map bigger and bigger. Most elements of the array were dummies representing "there is no room here" (this was in early basic, where you really can't have null placeholders). So I reworked it into a set of parallel 1-D arrays, one called "N", one called "E", one called "S" and so on. If S(4)=7 what that means is going south from room 4 will land you in room 7. E(5)=-1 meant that you can't go east from room 5. I had no idea that what I'd just done was actually a design pattern that had a name and was called "implementing the edges of an N-way graph packed inside parallel arrays." I also didn't know that implementing an array of structures, in a language that doesn't really have structures, by instead making a lot of parallel arrays each to hold one of the fields of the "structure" is also what I was doing, and was a known technique. I'd never heard of 'nodes and edges' and I'd never heard of a 'struct'. My 12 year old brain was just trying to make the game work and it looked like a way that might work, and I had naively thought I'd just come up with something brand new all on my own. As I think back on that.... I am starting to think that it could be pretty cool for a grade school to be teaching some basic programming by having the kids do something FUN with it like fly a Kerbal Space rocket. "Tricking" a kid into learning while doing something fun is a great idea, and yeah, having kids play around with a problem for a while trying to find their own solution before you hand them one makes it stick a LOT better. You'll remember the teaching better if it was dealing with an area you were just trying to think your way through on your own. Then you better understand why the solution is doing what it's doing.

I thought about it but deliberately left it out because it's JUST a vector subtraction, and it's a better teaching tool to make people understand how to do vector subtraction and how useful it is for translation to new "origins". All you have to do is subtract myship:velocity:orbit from othership:velocity:orbit to get the relative velocity vector between the two. I can't speak for erendrake here but I'm reluctant to add something like a target:relvelocity just because I see the ability to make TARGET have special abilities that other ships don't get to have as really being in the realm of manual piloting to help give visual aids to the pilot. To the autopilot, why give TARGET any special abilities that the other VESSEL("some name")'s don't get to have too? Just make it part of the generic interface you can use on ANY vessel. There may be a use for VESSEL:RELVELFROM(otherVessel), but that would *really* just be subtracting one vessel's velocity from the other. - - - Updated - - - While it would really be cool... at the same time I don't know if kerboscript is a good enough language for that purpose. Maybe it could become such, but at the moment the fact that you can't even write a callable function sort of limits how much it can be used to teach children about good programming practices.

I waffle back and forth on this one. On the one hand I like that approach, but on the other hand there's a lot of stock contracts that by all rights SHOULD be the sort that would need computer control and the only reason you can accomplish them manually is because the KSP simulation doesn't track signal delay. By all rights "try to land an unmanned probe on Duna" should be just like "try to maintain altitude within 5m error" - without explicitly saying it, it would be nearly impossible without a computer to help. But maybe that's more in remotetech's baliwick rather than ours. But I think where the most 'help' is needed in the contracts is really for the low-level building blocks that go into making the autopilot software - the early stuff. What I'd like to see is to allow you to, say, practice your landing software on Kerbin with a small test craft, with a chance of getting some of that money back that you spent on launching a test vehicle and trying it again and again until it worked. For things like that, it's almost mandatory that there be a test for "make sure you're not doing it manually" - because otherwise they're trivially easy to do. This is why I put it out for public comment. I'm really indecisive about it. I can see the arguments both ways. - - - Updated - - - The controls are fed to the vessel as a whole, not just to one of its parts. So we'd need a rule for what it means for one SCS part on a vessel set to lock and the other set to unlock.

Yeah it's really really annoying, because the ability exists for it to have been implemented to split out the string display from the actual number under the hood (i.e. a thermometer saying "120C" would have the number 120, with the field's unit label set to "C"). I know this because I did that for LaserDist - when it says something like "1,200,102m" in the display, the number is actually just an integer 1200102, and the conversion of that into a display string happens in a side routine. But sadly, it looks like the ModuleEnviroSensor was never implemented that way. The ugly thing is that it's not JUST a matter of parsing the string to an int. We also have to know about units because the same sensor could switch units (i..e it would have to be smart enough to know that 4.5km is a bigger number than 50m despite the fact that 4.5 < 50).

That's due to incorrect documentation. There is no suffix called :readout. There is a :display but sadly it returns a STRING not a NUMBER, making it next to useless for scripting. There needs to be a numeric suffix added to it. I'm not fond of the idea either. I'm just thinking of ways to solve the "detect that no manual control happened" condition for a contract, without penalizing you for accidentally tapping a key.

I may come back to this to look at the raycast-to-ship-parts problem. The main reason I haven't is that kOS needs my attention first. Given what little I've understood, I think that I need to move my ray cast check from Update to LateUpdate, despite the fact that Unity's documents show it happening in Update. I noticed a little hint in the docs for LateUpdate() that you use it to deal with the camera because of objects that might have moved during Update() calls.... and that got me very suspicious, because I thought objects moved during FixedUpdate's rather than during Updates. But if they move during Updates, then that means putting the call in update or fixed update will BOTH be the wrong place for it. I need a guarantee that the game has stopped updating object positions for the frame before I call the ray cast. if I'm calling it when updates may be half done, that's why I sometimes miss objects. I thought that object positions only update during FixedUpdate, but that one-off comment in the Unity docs hints at them being updated potentially within Update()'s as well.

The difference between this: archive/testflybywire.ks 2:1 0158 addtrigger false archive/testflybywire.ks 2:1 0159 push throttle archive/testflybywire.ks 2:1 0160 push True archive/testflybywire.ks 2:1 0161 call toggleflybywire() archive/testflybywire.ks 3:1 0162 call stage() (no pop) and this: archive/testflybywire.ks 5:17 0165 push prograde archive/testflybywire.ks 5:29 0166 push True archive/testflybywire.ks 5:29 0167 call toggleflybywire() archive/testflybywire.ks 5:29 0168 pop <<--INSTRUCTION POINTER-- (has a pop). May be how one was called indirectly by the code in kOS (i.e. in the first one the script never said "toggleflybywire" - the script said "lock throttle to 1" and the lock command itself chose to call toggleflybywire as a result) while the other was called directly as a function in kOS (the script said "toggleflybywire(...)"). It occurs to me this may be a bug in general with people calling built-in functions with the parenthesis syntax. When I made them interchangeable, not only does it mean you don't need parentheses to call MYLIST:CLEAR but it also meant you CAN add them to things like PRINT and so on, which never occurred to me. I suspect you'll get the same exact POP problem if you try to do PRINT("hello") as opposed to PRINT "hello". I'll have a chance to look into this later today. In the meantime you can try that little test. Try these two things: PRINT "one". PRINT("two"). And see if you get the same POP error on the second one as you got with flybywire. It may have nothing to do with your change, and have everything to do with this.

I think you're reading what I said 100% backward. What I was suggesting in what you quoted of me was the other way around - Don't make probe cores gain the functionality of kOS computers, but make kOS computers gain the functionality of probe cores. This would allow you to build a craft that contains JUST a kOS computer and no stock probe core. Of course this is hypothetical anyway. I don't know if this is possible yet.

The problem is that the computer unit isn't a probe core. If you have no probe cores, and no manual pilot capsules, and just the kOS computer, then KSP considers the craft to be debris. Probe cores can be made into kOS computers with ModuleManager rules, but going the other way and making a kOS computer into a probe core is a bit messier as there's multiple PartModules that a probe core has to have to function like a probe core. I get what you're saying with a "don't touch the controls" condition being way too easy to fail by mistake: "Oops I forgot that the terminal window wasn't focused when I started typing, now those key presses count as manual piloting and I failed the mission", or "my fat fingers pressed the 'z' key when I meant to hit 'alt' ... now I failed the mission because that counts as manually controlling the throttle". There would need to be a better way to avoid that problem, you are correct. Perhaps the way to avoid it would be to provide an actual manual lockout button on the terminal or in the KSP app launcher panel? As long as it's enabled then kOS will suppress all attempts to manually pilot until it's turned off again? Or, alternatively, since we're bundling ModuleManager with kOS now anyway, maybe we can turn our kOS computers INTO probe cores with our own ModuleManager configs we ship with the mod? That way people would no longer have to include BOTH a probe core AND a kOS computer on their craft. Then the rule could be that you have to complete the mission using ONLY a kOS computer on the craft with no stock probe cores. (Then we could make it so that a kOS computer does not allow manual piloting, but does everything else a probe core does.) These are just two ideas. Which works best will depend on experimentation. But I do get your point that "don't touch the controls" is just waaay to easy to fail by mistake or fat finger typing. Okay, for the time being, for this and future suggestions in this thread, let's assume that we will use *one* of the ways mentioned above to solve that problem, so people can feel safe in adding "don't manually pilot" to their conditions of proposed contracts.

Let's brainstorm. Contract Ideas from YOU If we added kOS contracts to the game for career mode, what contract conditions would be good? (This is a post I ran by @erendrake first before I put it out here. You can consider it to be, essentially, from both of us.) As it is, if you're playing career mode and you come up with a cool script, you get no credit for it - no funds, no science, and no rep. This means that effectively all your scripting tests really have to be done in sandbox mode only. This really should be changed so that roleplaying a space agency trying to experiment with autopilots and pay the expense of the testing program for them becomes a viable option. So before we start designing potential approaches to this, we should really hear from you, the user community, about what contracts you think would be fun and what would not be fun. We're interested in both ideas of single interesting contracts, and ideas of general contract-making strategies. Any opinion you have. This is brainstorming here, no ideas are final, and all ideas should be considered. One general strategy I'm wondering about is whether the contracts should explicitly require computer control, or if they should just mention the applied goal, and we pick goals that would be really hard to try achieving by hand. (i.e. "fly due north for 20km, keeping your altitude between 3500m and 3505m the whole time. If you're insane enough to want to try doing that without an autopilot script you go right ahead and try.") Contrast that with a contract like "obtain science from the mun with an unmanned craft, and without ever touching the manual controls after launch" - which would be a contract that does explicitly require the computer control. A third option might be to take the existing contracts the game already has, and modify them to award an additional bonus if they can be accomplished without manual control. I do not know yet if this would be hard to implement. For one thing I haven't seen examples of 'optional' goals in the stock contracts system yet. To get the ball rolling, here's some of my own I've been knocking around, along with a tag for whether I envision them as being early-game, mid-game, or late-game contracts. (early) land at Kerbin within a tolerance of location FOO, in which during the last 2000m of descent, all the following were true: No pilot controls, no parachutes are currently deployed. (you can manually pilot everything up to the last part and then have to let the software do the final landing, basically). (mid) Like the "land at Kerbin" above, but with much narrower tolerances, tight enough for things like "land on the helipad of the VAB" to work. (mid) stick a landing at location FOO on Mun (where FOO would be like the contract survey locations). (mid) Perform a surface scan mission (like the 'seismic surveys'), but once landed you cannot touch the controls directly - thus you have to autopilot drive the rover between the Alpha, Beta, and Gamma locations of the contract. (mid) hold altitude in a plane (as per description above). (only listed as "mid" because of the ridiculous fact that the stock game doesn't let you make airplanes in the early game). (late) Planetary transfer to another planet and back again, never touching the controls the whole time. Okay I'll stop there. I have some other ideas but I should hold off because we want to hear ideas from YOU, not just rattle on about our own. As of right now we haven't looked in extreme detail yet at what the contracts API will allow us to do and what it won't. But it looks quite flexible and I suspect it will let us specify quite a bit of unusual conditions. Future plan: This is all part of our upcoming desire to make a future release that fits the THEME of 0.90, and doesn't just merely WORK with it. First there will be a full (not pre-) release soon, probably called 0.15.5, in which it has bug fixes for 0.90 compatibility but none of the thematic changes to make it FEEL like a 0.90 game now feels. Then, Second, and much later, will be a release that adds the right stuff to thematically FEEL like 0.90 is supposed to feel, including checking for building upgrade tech levels before some stuff will work, and adding the aforementioned contracts, and so on. Again, NONE of this is a promise - this is what we'd LIKE to do, not what we're CERTAIN we'll do. So, let's see those contract ideas rolling in.

Just a warning about upcoming releases. (About KSP 0.90 career mode and the Building upgrades) The current pre-release, and possibly the first 'real' release after that (i.e. the first release supported by CKAN) had as the goal "the minimum to get it to work in KSP 0.90 without breaking bugs". When SQUAD introduced the limitations of building upgrades in career mode, they did it in a way that ONLY affects the user interface and not the underlying API that mods can call. That's why kOS 0.15.4.0 still lets you set maneuver nodes before you can do it manually in a career. This is not the *intent*. It's just that we haven't finished making kOS fully in agreement with KSP 0.90's new style of thinking. KSO 0.90 hit us as a bit of a surprise. We knew there would be upgraded buildings and the like, but not that this would mean some of the data you can get from kOS would retroactively become a 'cheat'. For example, whether your script can call SHIP:OBT:NEXTPATCH or not really SHOULD depend on whether or not your tracking center has been upgraded to do patched conics, but at the moment it doesn't perform that check. Of course, in a sandbox game, everything should work from the beginning - this is only for a career mode game. I just wanted to mention this to help manage expectations, after seeing @amiavamp's post above. The ability to use kOS to set a maneuver node when your career game isn't supposed to be able to do that yet is a problem we do intend to fix eventually.

Yeah, we were heading to that conclusion ourselves, but it's good to get confirmation from you that you've hit the same problem. Technically since you can now launch either kind of ship from the runway, there's no real benefit to keeping the two editors' upgrade levels separate and I'm not sure why SQUAD chose to do so.

Has anybody dealt with GameVariables.Instance.UnlockedActionGroupsCustom and GameVariables.Instance.UnlockedActionGroupsStock? Here's my problem: I want to limit the use of them in kOS depending on whether or not the career has unlocked them... but the problem is that they are unlocked separately for the SPH as for the VAB. So will I have to do it on a per-vessel basis (this vessel was made in the SPH so check it against the SPH's editor level, while THAT one was made in the VAB so check it agaisnt the VAB's editor level)... and that opens up the second question - how on earth do I detect whether a vessel was made in one or the other once it's already been launched ages ago?

On the first page of this thread, Sarbian mentioned a list of capability checks looking like so: I just spent quite a while looking and looking and eventually figured out where the heck these actually are, and what on earth sarbian was talking about with them. I couldn't find them anywhere. I finally found them. I thought I'd share. They're found under GameVariables.Instance. So, for example to call GetPartCountLimit for the VAB, it would look like this: float upgrade_level_VAB = ScenarioUpgradeableFacilities.GetFacilityLevel(SpaceCenterFacility.VehicleAssemblyBuilding); int part_limit_VAB = GameVariables.Instance.GetPartCountLimit( upgrade_level_VAB );

Nope. I'm within the area, the screen hints say "you have now entered such and such area", my altitude is above the requirement, I take the temperature scan and it says I can't do that at the moment, and the contract is not fufilled. I tried that twice before giving up on it. Normally the contract temperature milestone is completed when the little popup window appears with the science report (where you can recycle, or keep the report) - if you don't have permission to perform the temp scan, then that popup never appears, and the contract parameter isn't satisfied.

You get a contract for "take surface sample at Heinrick's Folly Beta", and when you hover the mouse over the spot, you can't see any data about its location. It would be very handy if you could. If I could see that my own rover is at 20o12'2" S, 45o0'41" E, and the target location is at 20o11'0" S, 45o0'44" E, then I know that I need to go nearly due north to hit the spot. As it is once you get close it's hard to tell exactly which way you need to drive to get there. If this is a thing that a later tracking station upgrade gives you that I just haven't unlocked yet, then never mind.

Instead of random chance of failure, which I agree with SQUAD is a Very Bad Idea, you can still have deterministic failure conditions in which the conditions vary by several settings. For example, you can have the crash tolerance of rover wheels be improved/degraded by the Engineer level of the Engineer who fixed them. It's still deterministic, but based on a value that can change based on in-game activity. I also think that something akin to kerbal attachment system should be in stock so that Engineers have more to do - it would be thematically perfect if an Engineer could attach struts but nobody else is allowed to.