Xiong

I've played heavily with RT2 now for a couple months and through two careers; I've spent way too much time thinking about it -- what it is, what it's meant to simulate, what can be simulated well, and so forth. Now my experience with suggestions is that people would rather stay wrong than change -- which means being better but having to have been wrong in the past. Don't ask me to argue, please. This mod needs a major overhaul. The basic concept is sound: An uncrewed, robot craft must communicate with Mission Control; and the only practical method is by radio -- possibly laser, which is the same in effect. Two restrictions are guaranteed by physics: Communication links must be straight lines (geodesics for the wonks); that is, a clear line-of-sight (LOS) must exist between endpoints [Yes you can bounce signals off the ionosphere, if you have an ionosphere, and with enough gear, off a moon. Not practical to simulate.] No signal can propagate faster than light ©. [No you cannot avoid Officer Einstein.] Other restrictions are a bit more flexible: Robots are stupid; the smartest robot ever built in reality is no smarter than a housefly. They cannot adapt well to novel situations. [This may change in your lifetime, not in mine.] Robots are buggy and cannot be expected to follow a stored program for very long before making a mistake. The more complex the program, the sooner the bug surfaces. Radio systems generally get bigger, more massive, more expensive to build, more costly to run; the higher the bandwidth provided. Transmission demands more than reception. Bandwidth: video > still photos > programs > commands > status Therefore, reasonably, a robot craft must communicate at intervals with MC; and the more complex its programming, also the more variable the robot's environment; the more frequent the communication. And, obviously, every command must be sent in advance of execution; every report from the robot will be received after an equal delay. The delay between distant points in a system the size of Kerbin's is significant, on the order of minutes. However: RT2 is even more restrictive than this; and that's just asking for trouble. Losing control of a robot is a serious issue; it usually means that you lose the robot altogether -- gone, Jack, not coming back. So engineers work hard to avoid this disaster, even if MC does an oops. Robots designed to operate under harsh conditions out of reach of a helpful hand to push the big red button are kept up at all times with some subsystem that reboots the computer whenever it crashes, freezes, or otherwise fails. The first thing after a reboot and self-test... reacquire signal from Control. You engrave into the most durable possible storage all of the info needed to restore power to antennas, aim them at known stations, and lock on. This routine has the highest possible priority after safety routines needed to preserve the robot from immediate destruction. But that's not all! it's never enough to build a high-bandwidth channel; you cannot guarantee it will always be up. It may just use too much power to run continuously. So you always include a low-bandwidth channel, an entire, distinct subsystem. This may not even have ability to report, although it should report status, at least. What it certainly can do is hear MC, even under very difficult conditions. It may only be able to hear the commands: Wake Up! and Turn On Your Big Ears! But the probe will not be dead. So you simply do not spend $10 million to put up a probe and as soon as it goes around the Moon, you lose it. People down at JPL do make mistakes but if the dish didn't deploy, it likely still can pick up a command to deploy. Meanwhile the entire Flight Computer thing is broken. Suggest you trash it altogether. We already have a flight computer; it's called MechJeb; and it's in constant use by many players. You need to get in there anyway because MJ, now, simply ignores signal delay. Write a MJ submodule, get that working properly. As for the endless juggling of RT2 antennas, comsats, and stations... no, just no. I absolutely endorse the demand that one launch sufficient comsats to maintain control: If you want to talk to, or hear, your robot probe then a path from MC to the probe must exist and each link in the path must be a straight line not passing through any celestial body. Absolutely. But let the computers embedded in the network decide how to route the signals. Do not ask me to dedicate any more dishes! I understand that the game engine really isn't sophisticated enough to aim, physically, a dish directly at another dish a billion meters away. I fear an attempt was made to substitute, for this realistic requirement, the funky requirement to dedicate a dish to a single target. Bad idea. It's an oddity of the core KSP game that not more than one craft is "active" at any time; and then there's a gray area defined by physics range: Within a radius of a bit more than 2 km, other craft are pseudo-active. If this were not the case then there would be a clear motivation for multiple antennas on comsats, with multiple probes all transmitting reports, receiving new programs, or sending HD video of that leaky pipe aft. As it is, and as RT2 is now, I find it very hard to justify a comsat containing 24 huge dishes. But it's either that or spend all day re-dedicating the dishes I do have, instead of building and launching rockets. This stinks. This stinks all the more because a single omnidirectional antenna seems to be able to handle infinite bandwidth -- one omni can control a thousand probes within its range. A reasonable compromise might well be to take note of how many active links terminate at a given comsat or relay ship; and call this the vessel's load. If the total bandwidth provided for a given range falls below load, then comms at that range degrade. Then this can be fixed by adding more dishes or omni antennas. Then the distinction between dishes and omnis becomes a little less distinct, as in real life, where the chief difference is capacity, not dedication. In sum: RT2 does not look sexy, provides player with no new capabilities, extends nothing, makes nothing easier, gives nothing, yields no science. It demands more of player, takes away things, consumes. This is good but a hard sell. The only basis on which to advance RT2 is realism. So let's try to be a bit more realistic, eh?

The above issue with biome maps failing to load is corrected by first cd to the dir enclosing the game executable. (Thanks, taniwha.) Suggest checking your pathfinding code.

Well that was quick. With nothing at all installed in GameData except CustomBiomes, Squad, and 000_Toolbar; same as before. I sent a command pod to the pad, opened the Toolbar and added the CB button; clicked the button, checked that 'Basic' was set for the new Sandbox, and clicked to Moho. "There is no biome map for Moho." -- or for anything except the three stock bodies. As before: [LOG 04:34:19.528] AddonLoader: Instantiating addon 'CustomBiomes' from assembly 'CustomBiomes' [LOG 04:34:19.535] Starting Custom Biomes v1.5 [LOG 04:34:19.573] Parsing rect [LOG 04:34:19.573] Parsing bool [LOG 04:34:19.573] Parsing rect [LOG 04:34:19.573] Parsing bool [LOG 04:34:19.573] Parsing int [LOG 04:34:19.573] Parsing string [LOG 04:34:19.610] Biome replacement complete. As before, KSP.x86_64 (patched as usual), CB 1.5. The biome files are there but they do not load.

Running KSP 0.23.0 (64-bit version for Linux) with CB 1.5; a career with 'Basic' map set does not load any of the custom biome maps at all; they are visible neither with ScanSat nor directly through the CB toolbar-button window (which itself works fine). The 'Basic' set clearly is set; the three stock bodies' maps display in living color. All other bodies display a little tab with the text, No map for X. Here's a few lines from KSP.log: [LOG 00:07:50.285] AddonLoader: Instantiating addon 'CustomBiomes' from assembly 'CustomBiomes' [LOG 00:07:50.287] Starting Custom Biomes v1.5 [LOG 00:07:50.304] Parsing rect [LOG 00:07:50.304] Parsing bool [LOG 00:07:50.304] Parsing rect [LOG 00:07:50.304] Parsing bool [LOG 00:07:50.305] Parsing int [LOG 00:07:50.305] Parsing string [LOG 00:07:50.325] Biome replacement complete. I have a lot of mods installed but none I think *should* conflict. If I can put together a few hours, I'll see if I can eliminate possible causes.

I desperately do not want compatibility broken with 0.23. Let's get this working before moving forward.

I prefer wiki to forum so look for me there, thanks.