Dunbaratu

People haven't mentioned psychological reasons, which *is* a matter of safety too. It's unsafe to send people into a situation where they can't handle it mentally and freak out and do something stupid as a result. The longer flight time to Mars and back means dealing with the sanity issues of boredom, loneliness, cabin fever, etc. And fixing that means way more payload - people will need some *space* in that capsule.

Sadly it's a hard thing for mods to change, given your goal of going 100km away. Some mods change the loading distance, but only by a small amount. A 100km loading distance is probably not going to be doable because of how the main stock game itself works. The big reason there has to be a loading distance limit is because of how floating point numbers in computers store values. Small values near zero can be very precise, but the farther you get from zero the less precise they become. Trying to track the position of two ships that are fully operational with all the physics interactions going, that are located far apart from each other, means that they can't both be using small numbers. At least one of the ships has to be performing its position and velocity calculations using imprecise larger magnitude floating point numbers. The SQUAD devs found that when they tried to run the part versus part interactions (detecting collisions) on parts using numbers that big which cannot be precise, the system kept miscalculating the magnitude of their interactions due to the impossibility of storing their positions accurately with those big floating point numbers. Thus the parts kept being calculated as having "collided" with each other and your ship would explode very unfairly for no apparent reason. This is what everyone's talking about with the "space Kraken" - its the mysterious monster that explodes your craft if you stray to far away from the origin of the frame of reference of the mathematics of your universe. SQUAD fixed it by recentering the universe origin to always be near your craft, not on the sun as was originally designed. But if there's two different vessels both loaded that are not near each other, then you can't have them BOTH be near the center of the universe, thus the loading limit being so small by default. That's problem 1. With rovers specifically, there's a second problem - terrain polygons. When you are near the ground you see the terrain as being made up of polygons in a giant surface mesh. Each polygon being about 3 to 10 meters across (depending on your graphics detail settings). Now, imagine viewing the surface from space, high up - seeing entire continents in view. Try calculating how many polygons that is if each one is only covering 10 x 10 meters. Even a very modern high end graphics card would be choking to death on that. Therefore terrain that is far away from the camera isn't *really* there - in the sense that those polygons aren't loaded. What you're looking at once the terrain is far from the camera is essentially a hologram with no physics on it *that objects would just pass right through*, made up of a proprietary mathematical heightmap algorithm SQUAD has for each planet. When you get closer to the ground, KSP takes sample points from that math algorithm and uses then to create the ground polygons based on calculating where the vertexes should be in the heightmap. When you leave the area, those polygons go away again. The ground only really exists within about 7km of the camera. Those mountains off in the distance? They're not really there. They're holograms. So that's a second problem with driving a rover that's 100km away from the camera. Not only is the rover itself not loaded, but even if it was, the ground on which it's sitting isn't loaded. It would fall through the holographic ground and into the planet. - - - Updated - - - tl;dr version - you can do some tricks to increase the loading range a bit - but not enough to be driving a rover that's 100km away from the camera. The terrain alone would make your GPU want to commit suicide.

kOS still can't fix the inherent problem in KSP of unloading the vessel when it gets far away. It *can* drive a rover that isn't the active vessel, but once it gets more than 2.5km away from the active vessel, it will stop moving unless you have modded the unload distance. And then even if you have, if you make the unload distance too long, you hit the space kraken problem that was the whole reason SQUAD had to make an unload distance in the first place.

This is my really long explanation of the angles system. I turned on he microphone and just started talking through stuff. An example of bank angle happens towards the end about 22-23 minutes in, but it wont make much sense if you skip ahead to it without watching the earlier bits.

Hey, one of the two active devs for kOS here. Just in case you don't know kOS's current design (although this is not the original design by Nivekk, who no longer maintains the project), is that kerboscript is merely the default language that is bound to the low level virtual machine's opcodes,. Once it compiles to those opcodes in an almost JIT way (not quite JIT), then the program just executes off those opcodes alone, ignoring the higher level script it came from. The point being that in principle it should be possible to compile more than one language down into those virtual opcodes, even though we haven't had the time to address that and give it a try yet. There is someone trying to make a .NET converter that will take a C# .NET DLL file and convert its opcodes over into kOS opcodes, but it's kind of hard because some of the limitations of kerboscript are also limitations of the underlying virtual machine itself, like not having a means of making local variables for example. If you want to make a new system from scratch, I'd love that and enjoy the "competition", so to speak - as it would force us to keep pushing. But alternatively, if you want to look into the possibility of making a javascript compiler FOR kOS we'd be happy to work with you on that. The reason I mention it is that a heck of a lot of what goes into kOS isn't *really* about the language itself and instead is a bunch of utilities connected to the interface between the language and the stock game. Making the in-game terminal window work, making the new telnet feature work, dealing with the lock steering mechanism and connecting it to KSP's API, etc. If you start a new project from scratch, there's a lot there that you'd have to re-implement. While there might be a lot of headache around trying to work together (especially since we'd probably need to do a lot of stuff at the low level to change the opcodes, but we'll have to do that anyway as I'm in the midst of designing a function call (with local variables finally) system for kerboscript. Another possibility may be to try to split kOS apart into two different mods - one that is the language and one that is the utilities (like the terminal and autopiloting system and so on), so that the utilities part of it can become a shared thing used by more than one mod (sort of like how RasterProp Monitor works). Anyway, I'm just throwing ideas out randomly here. I have no idea just how workable this all really would be. As for if you do want to go do it from scratch, here's a few things to keep in mind that we've run into in kOS that you'll run into as well and want to consider what you'd like your solutions for them to be: 1 - Unity and KSP are not threadsafe, so you must do one of two things: 1.A - Break up your script's running into small chunks that can be run a little bit per Update() or FixedUpdate() callbacks (depending on which you want to use - kOS uses Update() which is wrong and we have to change that some day to FixedUpdate()). The main Unity program runs all in one thread, and makes calls into your mod's update or fixedupdate callback methods. These callbacks MUST NOT take too long to run, and mustn't ever perform any blocking I/O activity like waiting for a keypress, or waiting for network traffic. Thus if your user writes a long-lasting loop in their script, you have to find a way to execute that loop a bit a few chunks at a time and save the state of things between chunks. (For example if you have the C# code "while (true) {}" in one of your callbacks, you actually freeze the entire KSP game because everything your mod is doing is in the same thread as the main game.) kOS achieves this by compiling the kerboscript into lower level opcodes and then lets the virtual machine only run a fixed number of the opcodes per Update() call. 1.B - The other approach would be to run your script in a separate thread that can just run as fast as it feels like, but then to do that you must make sure it never makes any use of any Unity or KSP API calls directly from the script's thread. What you'd probably have to do then is devise some sort of queue or stream of marshalled API call parameter information that is used to pass these requests from your script thread to your main Update() or FixedUpdate() callbacks, which DO run in Unity's main thread, which can answer them, put the answer back out on the stream or queue, and let the script's thread then see them and act on them. While conceptually cleaner maybe, it's a heck of a lot more work because you then have to pass back a LOT of data that way for a bunch of different things. Every time the script tries to read the ship's position, or velocity, or mass, or fuel remaining, or tries to alter the throttle, or set the steering controls, it's going to have to do it through this system, and that means you have to design how all of that is going to get marshalled up and sent from one thread to the other. 2. Unless you pay money to Unity for the professional development suite, you CANNOT add your own fonts to the game for your mod. The free development suite doesn't allow you to because it requires the creation of an asset bundle. It won't let you read a TTF file directly, **EVEN THOUGH the Unity documentation says it works without mentioning the fact that it doesn't in the free version, grumble!**. You just can't. The fact that this is the case is not well documented, and took us a long time to figure out. I don't begrudge Unity for having features that only work in the professional version, but they should freaking TELL YOU in their documentation when their instructions won't work without it. Anyway, the fact that you can't add your own fonts becomes a problem with the terminal window. SQUAD has a few fonts you can use in their own asset bundle that the game ships with, but they never put a monospaced font into their bundle of fonts. If you want a monospaced font to appear anywhere in the game, you end up either having to buy professional (expensive) Unity, or you have to fake it by manually painting rectangular zones from a template bitmap file into coordinates of the window, which is what kOS does. 3. The internal coordinate system of KSP is notoriously messy because it keeps changing depending on circumstance and the XYZ axes don't stay put in the same orientation throughout the life of your campaign savegame. It's fine if only modders have to deal with it, but if you want to expose users who write their own scripts to it, they'll complain that your mod is all broken and messed up when in fact that's what KSP's system *really does* look like. You'll need to deal with finding a way to mask some of the ugliness away. (kOS doesn't fully succeed at this but it helps a little bit by always making it look to the script as if the universe's origin is centered on the CPU's ship whether it is or not). 4. Some parts of the KSP API make the assumption that you are only interested in working with the "active vessel", which is the one the player is in control of. Once you introduce autopilots into the picture, they can be operating on other nearby vessels that aren't the "active" one. We've tried as hard as we can in kOS to make the rule be that everything you affect about the ship is affecting the ship the CPU part is attached to, which might NOT be the one the player is in control of. Well, there's others, but I've let this post get too long. The tl;dr version is this: There's a lot of code inside kOS that isn't dependent on the fact that the language is kerboscript. There may be an opportunity to do some useful sharing of work here. The person to contact is erendrake. He handles most of the high-level archetecture stuff like organizing the code tree, and dealing with the integration of DLLs and so on. I get down into the nitty gritty of things like parsers and opcodes and telnet RFCs, and so on. I'm more of a C++/Java programmer used to UNIX and makefiles and so on. Erendrake is more into how C# does things and I only learned C# specifically FOR doing kOS, so the way that Microsoft designed all that to work feels entirely alien (and a times very wrong) to me. You should *definitely* contact erendrake and discuss possibilities of shared work in some fashion or another. He's usually very much in favor of that sort of thing. One caveat, though, is that kOS is licensed under GPL3, and that legally requires that if its code is ever mixed together with other code into the same codebase, that the other code has to be GPL3 as well. The fact that it uses GPL3 quite *literally* cannot ever be changed by us because it contains code from an original author who fell off the face of the internet a while ago and we have no idea how to contact him. Without permission from him, it would be illegal to change the license under which he chose to release his code.

I personally hate the name of it. It's a naming choice going back all the way to Nivekk. The name implies that: (A) The only reason for getting a list of vessels is for the sake of setting a target (which is false), and ( The only things you can target are vessels (which is false - there's bodies and docking ports). It's just a list of all the vessels in the campaign save. That's all. The name of it is terribly misleading. I don't actually like this rule either and I'm the one that implemented it. I just don't like it when mods make things easier than stock in ways that aren't just fixing stock bugs or stock annoying missing bits (i.e. alarm clock, for example, makes things easier than stock, but by basically fixing a missing feature that stock needs. kerbal engineer makes things easier, but by un-hiding information that stock has no right to be hiding from the player. In-flight waypoints just un-hides information that stock has no right to be hiding from the player, and so on.) But this is different. Allowing a back-door way to enable a feature that stock is *deliberately disabling* is something else entirely, and I don't feel comfortable doing it. Ideally, what I'd like to see is to make the stock game stop using this silly feature. The custom action groups are not in any way related to how nice your VAB is, thematically. They're part of how your flight controls can pilot the ship, not part of how you engineer building it. But nevertheless I'm reluctant to change it unless stock is changed, even though I think the change would make perfect sense, the change should happen in STOCK, not in a mod. - - - Updated - - - Incidentally, the claim that IR allows you to call its action groups without an upgraded VAB isn't *quite* true. It's more accurate to say that IR has two different user interfaces to access the part movement, ONE of which is the action groups and THAT interface is still restricted by VAB level just like in kOS. It's just that IR also provides a second way to move the parts that kOS can't see, using IR's own GUI window that is entirely outside the action group system altogether. I'm waffling on this, however, because really you still *CAN* use the IR action groups from the stock action groups, its just stupid and weird (i.e. turn the brakes on to slide the slider up, and turn the lights on to slide the slider down.) So the dividing line isn't "can you call the action" but rather "can you call it from Ag1, ag2, ag3, etc.") And come to think of it.... I don't think we use the VAB level as a restriction against using AG1, AG2, AG3, etc. We just rely on the fact that you can't BUILD anything into those action groups anyway without the VAB interface allowing it.

The very first thing to look at to see if the culprit is kOS or something else is to look at this little indicator in the corner of the screen: If you see it being pushed to the limits during the part where you want it to roll, and it's still not rolling at all, then kOS is *trying* to roll but some important facet of the ship engineering isn't being enabled (i.e. RCS is off, or torque wheels are starved of power, or thrust vectoring is off, etc.) On the other hand if you see that it's NOT being pushed to the limits, then kOS is piloting it incorrectly and maybe there's a bug report to be made.

Doesn't the size of the rocket scale in a way that isn't linear with the size of the payload? In other words, to put twice as much mass in orbit requires MORE than twice as much of a rocket. It seems that this would make two smaller launches of half the payload each more economical than the one combined launch.

It's a ridiculous bug in KSP's stock code that users have complained about for literally years that SQUAD pigheadedly pretends is "correct" behavior. Correct behavior: When you have radial symmetry enabled and attach something to the side of a rocket so the game clones several copies of it around the rocket, then attach fuel tanks under it, then engines under that, KSP is smart enough to know that each engine is connected to each fuel tank one at a time. Engine 1 sucks fuel ONLY from tank 1, engine 2 sucks fuel ONLY from tank 2, etc. Incorrect behavior: The same is NOT true when you attach air intakes using bi-symmetry in the SPH. Although the liquidfuel gets sucked from the correct (only the ones in the same stack in-line) tanks for each engine, the air resource gets sucked globally from ALL intakes, even the intakes not attached to that engine's stack of stuff. Basically, the bug seems to be that the game is treating the air resource like a global resource that ignores part pathing - similar to how electriccharge works. All the air gets pooled together into one common resource, which then is NOT doled out equally to all engines, but rather all of it is given to engine 1 and then whatever is leftover after that is given to engine 2. The effect is that once you get into thin enough atmosphere that the intakes don't GLOBALLY have enough air intake to satisfy GLOBALLY all the engine's demands for it, the starvation does not happen equally on left and right sides, because engine 1 starts stealing air from engine 2's air intake in a way that should be physically impossible. Thus engine 2 flames out way before engine 1 does, and your plane spins way out of control. Lots of people have defended this ridiculous arrangement by pretending that "well it's okay because flameout isn't uniform anyway and the engines won't all flame out together anyway", which ignores the crux of the problem that engine 1 is consuming air it's not even supposed to be connected to in the first place, which is the cause of engine 2 getting starved of air prematurely. In a case where realistically, you're talking about maybe a difference between one engine operating at 10% power and the other at 0% as they flame out inconsistently, you now have one engine operating at 20% and the other at 0%. It's not JUST that one engine gets starved, but that the other one gets TOO MUCH, creating this large imbalance that spins you out of control rather than both of them getting worse and worse so when one flames out the other isn't very powerful either. Squad refuses to fix this known problem, and there's a workaround where you can attach engines without symmetry turned on and it won't cross feed their air intakes together then, provided you can be exact enough to make them have symmetry by hand, and that's hard. People making spaceplanes are therefore deeply concerned about detecting when flameout is about to occur and they want to kill the throttle JUST BEFORE it starts to happen. Thus the desire to be able to read what the current intake levels are.

I've been toying with the idea of getting into RasterPropMonitor, with the goal of making a kOS computer terminal that appears in IVA view in the cockpit window. But one problem is that I'm not sure it's possible to have RasterPropMonitor "grab focus" and pass keypresses through itself into the current Page plugin. There appears to be API methods for getting button press information about the buttons along the tops and sided of the monitor, but not for getting keyboard input into it. (Thus people couldn't type into the kOS terminal via RPM - only use the buttons along the side). I suppose one possibility might be to have my own RPM page plugin be in charge of grabbing keyboard focus from the game instead of having RPM do it, and it could be told to go into "terminal keyboard mode" by the user pressing one of the RPM buttons along the side of the monitor.

I figured it out and submitted the fix to the development code here: https://github.com/KSP-KOS/KOS/pull/613 , along with another telnet terminal issue with using UP-arrow to get previous commands back when some are long multi-line commands and some are short cmmands. I don't if it will be a while before it's released, or whether it will be deemed worthy of a "quick" patch by erendrake.

I want there to exist one. There have been several people claiming to set one up but then they stop updating with little explanation.

For anyone having trouble with the telnet terminal - remember the control-L key If you are having cases where the telnet terminal doesn't update well, then remember the Control-L keypress as a temp workaround. (It's documented on the docs referred to by he changelog, but admittedly it's buried pretty far down the page.) Pressing Control-L will force the telnet terminal to redraw itself entirely from top to bottom, which might fix some problems with it getting out of sync. Still please do report such problems though, because having to fall back on that shouldn't be necessary, but it might work as a temp workaround until the fix is out. For the specific problem Wercho found I'm not sure if control-L will work with this one. I tested PRINT AT lots of ways and it worked when I did it. I am going to test it tonight but I suspect what's happening here is this: Wercho printed PRINT AT to a new, unpainted area of the screen. I was using PRINT AT to print into an area of the screen that's been painted once already with space characters. I.e. I print this first: clearscreen. print "+------------------------------+". print "| DISPLAY VALUE: |". print "+------------------------------+". And then further down, filling it in with: print value at (18,1). Thus I'm writing atop spaces that are already there. I suspect the bug arises when you write atop areas of the screen that were previously padded with empty null chars. When it should be sending the characters: F i x e d (space) (space) (space) (space) (space) V a r i e s to the telnet session, instead it's probably sending the characters: F i x e d (nullchar) (nullchar) (nullchar) (nullchar) (nullchar) V a r i e s and the telnet terminal is interpreting the nullchars as "do nothing" operations. If this is correct, then I know how to fix it and should have a patch available shortly. kOS doesn't clear the terminal when the program ends. If it's clearing, then the script is doing it.

One thing that I've realized is that we may want to support telnet linemode for the sake of RemoteTech with delay - where echoing back each character at a time live seems wrong because there should be a large network lag simulated. It may be the case some day that you don't have to do it as char-at-a-time mode, but don't hold your breath about how long it might take to implement that. Right now the presumption of interactivity is pretty set in stone.

Beware that the kOS telnet server insists on operating on char-at-a-time mode, so if you are piping your stuff to telnet you'll have to have it running on a pseudo-tty so it behaves right.

We're currently in discussions about what should be in the next update. It's a possibility. - - - Updated - - - Radial attachment *can* be done with existing models by changing he Part.cfg file if we want - it would mean the disc-shaped thing would be glued to the sides of things.

Well now I feel stupid. Apparently I had that little icon clicked that hides some of the paths on the screen. Those RT buttons on the map view could seriously use some mouseover hover tooltips. As it is they're indecipherable glyphs, and I don't know what any of the mean except by random trial and error.

They both have the probodyne octagon-shaped core (the next core up the tech tree higher than the stayputnik). I'll post them when I get a chance to get back to the game later tonight. Or so it says. That's why I'm confused that it's not acting that way. --- edit --- Okay, so here's the screenshots The map view - the two satellites have no line between them and I've verified that they cannot relay any contact to mission control through each other. Switching to map view and returning does not change the situation: This is KerbComOne.A, one of the two satellites. The kOS window is open to show the distance between this vessel and KerbComOne.B is under 2.5Mil meters. This is KerbComOne.B, the other satellite: As far as I can tell, with everything I've done they should be connected. It's entirely possible I missed something in the instructions but if I did I have no idea what it is.

The changelog list is built manually by one of us eyeballing the list of recent closed issues and typing them into the list, so it was just missed that's all. There doesn't seem to be a built-in facility for building a changelog automatically that way, we have to do it by eyeball.

Okay so what am I missing here: I have two satellites, both equipped with lots of communicatron 16s. They are well within 2.5million meters of each other (they are in orbits of less than 700000 each, plus Kerbin's 600,000m radius means each is 1.3million m above the planetary center. They are positioned 90 degrees apart around the circle, so that should be no more than sqrt(1.3^2+1.3^2) ~= 1.838million meters. The planet is not in the way. Both are well powered. Both have their communicatrons activated. The map view still draws no line between them. I don't get why. Is there a rule I'm missing somewhere?

I'm in the middle of adding a bunch of video links to the documentation pages, for a "show and tell" section. If anyone would like to have their videos added, post here and let me know. Also, if you respond, let me know how you want to be credited in the list - with your real-life name or your youtube username.

I just made the edit to my config and I'll be starting a new career with it. I'll let you know how it goes, and if it works, I'll post it over in the remote tech contracts thread. Basically, here's what I did: Instead of EVERY satellite having to have a direct connection to every other one (which is impossible if you use 4 as there will be ones on opposite sides of the planet), I did this: first satellite needs no contact with other satellites. Second needs contact with first. Third needs contact with second. Fourth needs contact with both third and first. Thus you can put them up one at a time, each placed 90 degrees ahead of the previous one. I also slightly increased the money payout because you need to pay for 4 satellites instead of 3.

Ah. Unity's Raycast. That's why. Say no more.

Good point. I forgot to add Kerbin's diameter. I still don't understand why it's claiming line of sight is cut off when clearly it's not. - does remotetech add atmosphere to the radius when checking? That might explain it. - then it would look like it's clear when it's actually passing through the atmosphere, which KSP doesn't draw. I'd do it with 4 except I'm trying to satisfy the contract for it that comes with that other mod (name escapes me now) that adds remotetech contracts to career. It mandates 3 satellites, which is kind of restrictive and fiddly.

Well, you lose the ability to "transmit all" that way, having to go click on each and every science reading thing one at a time to see their report windows. (Making conditional buttons is easy - you just toggle the guiEnabled field of the KSPEvent attribute. What's probably hard is fighting against SQUAD's code that's also trying to control the same button's visibility, such that squad's own code was just disabled entirely and replaced, but losing this useful piece of functionality in the process.) So I have a question about the Communicatron16. The display panel claims it has an omnidirectional range of 2.5Million km. I'm seeing it cut out at shorter distances than that. Is there a mismatch between what its displaying and the number the game is actually using? I have 3 comsats in an orbit of 700,000m each, and it can't cut the chord across between them. The diameter of a 700,000m orbit should be 1,400,000m, so any chord distance has to be less than that, and yet the green line only appears when they're about 110 degrees around the arc from each other. When I try putting them at 120 degrees around the orbit from each other (forming a triangle), the communicatron16s don't quite make the connection. And I'm definitely not trying to pass signal through the planet either. It's clear by eyeballing it that there's plenty of clearance.