English Mobster

Hmm. That's odd. The game only displays that message when everything is done correctly -- if it detects that it's about to freeze for any reason or ANYTHING goes wrong, I abort the warp and display an error message. Displaying the success message is literally one of the very last things that happens. Can you do me a favor and try one more time? If it happens again, find your player.log or output_log.txt file and put it on Pastebin so I can look at it and see what went wrong. Log files can be found here: â—¦ Windows (32-bit): {KSP}\KSP_Data\output_log.txt â—¦ Windows (64-bit): {KSP}\KSP_x64_Data\output_log.txt â—¦ Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log. Aka Files>~/Library/Logs>Unity>Player.log â—¦ Linux: ~/.config/unity3d/Squad/Kerbal Space Program/Player.log

Asteroids and flags should be working as intended, so let me know if you manage to break it so I can put out a hotfix. I did a lot of testing, but asteroids, flags, and debris gave me the hardest of times. They should all be fixed now, but I wanted to get something out there so people weren't left waiting. I'm not so much a coder at Disneyland -- I work as an attractions host, which means I run the rides. I usually work at Star Tours, but I also do a lot of crowd control during parades and fireworks. As far as comparing Disneyland and Walt Disney World -- Disney World is so much bigger. Like crazy big. If you have seen Disney World and you go to Disneyland, it'll be completely different because Disneyland is so small. I mean, we do have some pretty cool rides, but honestly it's nothing like Disney World (except for It's a Small World -- ours is a million times better). That being said, because we're smaller, Cast Members like myself have less restrictions on us (from what I hear) and can more easily make magic happen. But I'm biased.

What do you mean by actually changed? As far as the game is concerned, they do actually change -- I change CelestialBody.bodyName, which changes the name of the planet itself everywhere. There might be some sort of PlanetID somewhere which doesn't get changed, but I'm not sure what playing around with that would do. I haven't done much poking around there in any event. It's going pretty well, I'd suppose, considering I'm announcing the release of version 1.1.0! Changelog: [B]Features[/B] Added craft persistence between solar systems. Updated cost and science requirement for Hyperdrive part. Automatically return to Kerbol when "Return to Space Center" is clicked, leaving your craft in orbit around the other system. [B]Tweaks[/B] Changed some randomization features to use a normal distribution. Improved performance of RNG (thanks, paul23!) There might be a very, very slight performance hit on some systems, as the game has to write more persistence files to disk than usual. However, I most sincerely doubt that anyone would notice it, especially consdering that it only happens at non-critical moments (such as when the game is paused). There's also potential for some new bugs, since I still don't entirely understand how KSP works internally. What I have now seems to work, but there's always the potential that someone finds stuff I don't. There also seems to be more moons than there should be in the latest release, which will likely be addressed in the next patch. As I've mentioned before, I work at Disneyland and we're gearing up for the holidays. This means that there are a lot more guests in the park, which means I have to work a lot more (and I come home a lot more tired). As such, releases may slow down just slightly (you've probably noticed it by how long it took me to get my bug fixes done). They should pick up again when the holidays are over and everyone goes back to school/work. I won't stop development on this by any means, but I wanted to give you guys the heads-up that I won't have quite as much time to myself.

To some extent, that was exactly what happened. SOI changes would work fine sometimes and not-so-fine other times. The map view would show an encounter, but you would never leave the SOI of the larger body. If I hacked myself into orbit, I could get to the Sun's SOI, but not to a planet's SOI. I actually fixed it, and I'm not sure how. I think I fixed it by updating the childBodies of each CelestialBody. I'm edging closer and closer to release, but one more bug just popped up -- a moon was named incorrectly, taking the name of planet "e" when it should've taken the name of planet "c." Everything else was correct, although the orbit looks as if it wouldn't be terribly stable (its orbit crosses paths with the orbit of another moon -- it's a matter of time before the two likely hit one another). I'm going to see what I can do to clean that up. Then it's just making sure that there is no other game-breaking bugs and we'll get it out there. I've made a lot of improvements, I think, and I'd rather have the new version out over the older version. E: Hmm. Is there a way to turn off the auto-destruct for vessels on rails? I safely landed a crew of Kerbals on a planet surface, then warped away and came back. When I returned, my Kerbals/landed ship was gone. When I checked the debug log, I found this message: [LOG 01:09:54.032] Vessel Untitled Space Craft was on-rails at 0.1 atm pressure and was destroyed. [LOG 01:09:54.034] [04:16:34]: Joefred Kerman was killed. [LOG 01:09:54.034] [04:16:34]: Meltrey Kerman was killed. [LOG 01:09:54.034] [04:16:34]: Dosey Kerman was killed. My vessel was landed, not on rails. I'm wondering if there's anything I can do to avoid that happening in the future, as the risk of spontaneous death would likely deter any would-be Kerbal colonists on a faraway planet's surface.

Whew! I have some catching up to do, looks like. Hmm. I'll have to consider it. The idea behind having users type their own seed is to create Minecraft-esque "infinite" systems. Someone can type anything they want into the RNG, and a system will be generated from that seed. When you limit the seeds to A, B, C, A1, A2, etc., you still have people exploring the same systems, even if the number of these systems grows exponentially. It does add some additional exploration to the game, but nowhere near the level that can be achieved if a player can type their own seed. I do have to say that I love the design. I'll try to look for a way to implement something like it at a later date, but I'm somewhat concerned that I won't have the tools available to do so. I would basically have to create my own scene containing a list of all the systems, and I'm not sure how much of that is doable. If I were to have a starmap, I'd like for some sort of hybrid approach to the two systems. I'd generate galactic coordinates from each system's seed. I would need to make sure these coordinates are always unique, but that shouldn't be terribly difficult. I would populate the starmap with a few systems with randomly-generated seeds, but if you wanted to type in your own seed you could travel there and the star would appear on your starmap. Each person would get different randomly-generated seeds, but if they found a seed they really liked they would be able to share it with their friends and everyone would see the same system with the same coordinates. I would need to look into the exact implementation a little bit more before I can make any promises. However, if I were to implement something like a starmap, that's likely how I would do it. Now, as far as progress is concerned: I'm basically done crushing bugs. Adding all this saving and loading made everything an order of magnitude more complex, so it's likely that the next release would have a few more bugs I didn't catch. I think I've gotten most of them, but there's a few I haven't been able to replicate. Right now, however, I'm having issues entering the SOI of a body. It always says I will encounter the body in T+, but I never actually make the encounter. If I try to use Hyperedit to get myself into orbit, it doesn't change my orbit at all. The built-in KSP debugger says it's recalculating my orbit and I'm not sure why. Here's an example of what is spit out when I try to orbit another planet: recalculated orbit for probeStackLarge (Warper): the Nepin rPos: [-781129934.20732, -6521005042.28655, 390824550.506799] rVel: [1415.5297083033, -22.618722349208, -4572.38091210196] |4786.53352302522| I'm honestly not sure what's going on here. This happens even if I don't randomize the SOI of a body. I'm going to keep playing around with it and see what I can come up with, and once I get this bug quashed I should be able to make another release.

Ah, okay. I'm not sure if there's a way I can fix that, but I'll put it on my to-do list and see what happens. As for the persistence thing, I failed to mention that asteroids and stuff will be regenerated as of the next version, not this one.

Huh. That's weird. I don't even touch the RCS tank. I do copy the large ASAS, but I don't actually modify anything. Could it be related to the number of mods you're using? I would imagine that if a lot of memory gets taken up KSP might not load stuff or might "forget" stuff in memory. That's speculation, however. In the future I do plan to expand the planetary creation out, yes. I also plan to try and have binary systems and stars of various masses. However, at the moment that's beyond my current scope. At a future date, perhaps, but as for right now I want to focus mainly on getting persistence files working (which they now do 95% of the time -- working on that last 10%), improving the current randomization code (using normal distributions for some of the orbital properties such as inclination and such), and allowing users to name planets (and hopefully share their names with others!). Once these major milestones are accomplished, I plan to look to things like that. Ideally, I'd like some sort of simulation of an actual system being formed. It would have to be heavily simplified, of course, and it would be a LONG way out. There's the simple stuff, like putting gas giants further out and rocky planets closer in, but eventually I would at least like the option for the whole stellar process to be simulated. A random age for the current system would be determined by the RNG, and the randomizer would simulate stellar development until it reaches that age. It would also simulate the formation of binary systems and the like, although I believe black holes are beyond the reach of KSP. Obviously you'd orbit it fine, but when you crash into it I'm not sure what would happen. Perhaps the Kraken will be purposely summoned? I think this idea would be really cool since it would allow you to explore a star that will soon go supernova or a system which just formed. However, it would be a LOT of work, and even a simplified stellar formation simulator would require quite a bit of processing power. I would likely have to add load times inbetween jumps. At this stage, it's just an idea, but I'm going to see how viable it would be.

Asteroids: Cleared when you warp. New asteroids will be generated around the system you jump to. Jumping back to your original system will restore your original asteroids. Think of them as very heavy space stations, since that's how the game sees them. Kethane/ORS: Have not tested them yet, to be honest. In theory, they should be unaffected by the warp, since as far as Kethane is concerned an alternate Kerbin is still Kerbin. Kethane doesn't care (or at least it shouldn't care) what Kerbin's orbit is, what Kerbin is named, what its atmosphere is like, etc. All it cares about is that Kerbin is identified as Kerbin. This should also apply to ORS. Is Real Solar System compatible with Kethane/ORS? If it is, this mod should be, too.

I have some great news! I've done it! Everything seems to be working A-OK now. Whenever you launch to other star systems, your last system is cached. If the system you are launching to already exists, then the other system's vessels are loaded. This is mostly due to 2 handy GameEvents (thanks, OverloadUT and Joshwoo69!): onGamePause() and onGameSceneLoadRequested(). Whenever you pause the game or switch scenes, I save the current system to disk. This means when we load the next scene we can just reload Kerbol without needing to worry about saving the last system. Since KSP shouldn't require many resources while paused, I figured it couldn't hurt to save the game when we pause. The redundant onGameSceneLoadRequested() is in there just to make sure I cover the event of a rapid unplanned disassembly in-flight, where the player doesn't necessarily need to open the pause menu. I want to make sure that this release is fairly stable before, well, releasing it. I've already found a bug which killed all my orbital velocity and sent me crashing into the sun, and I'd rather not repeat it. I also want to make sure my save recovery system works in the event that the game crashes. There is also a bug right now with how far out moons orbit planets -- I tried calculating them using Hill Spheres, and the result was much too large. I also have an issue with orbital periods -- moons presently make a full rotation around their parent every minute or so. Both of these should be easy fixes. Once I'm happy with the results and kill any remaining bugs, I'll release it to you all. The next version has a lot of improvements, both visible and internal. Keep in mind that the planetary RNG system has changed a bit internally, so if you've grown attached to a seed it's going to be completely different when you load the next version. I'm going to try and minimize this effect happening on every release, but if I tweak any random variable or add in any new random stuff it's going to throw off everything just due to the nature of things.

See, the thing is this is the actual Vessel class (or rather, ProtoVessel) that KSP generates when a persistence file is saved. It's part of the stock game and not a class I've created. I've actually narrowed down what the issue is. I originally saved a "snapshot" of the last-generated world the moment the KSC scene loaded (in the Awake() method, for those of you who know Unity). That appears to be before KSP loads in the vessels -- so I was taking a snapshot of a game with no vessels (hence the empty space where vessels should be). If I move it to Start(), I get the vessels -- but now I'm saving the vessels from Kerbin again. I'm trying to work out when exactly KSP loads the vessels into the KSC scene so I can reliably manipulate it. I'm considering making a class which has a log of every vessel we've ever saved and keeps track of what seed each vessel is in, deleting the vessels that aren't in the right seed. I've also got to seriously clean up my code, as all this experimentation and reverse-engineering has made everything messy. Ideally, I'd like to save a snapshot when the flight scene gets unloaded, as opposed to saving one after KSC is loaded. I'm a bit worried about writing to file as the scene closes, however, since I have no control over what gets deleted when. I could try to save a snapshot when half the scene has already been deleted, for example. I'm going to poke around a bit and see if there's anything I can hook into that's called before OnDestroy(), but I'm not sure there is.

In the currently-released version, things don't persist like that, no. They persist, but they persist across all systems -- they never go away. This was mainly because I wanted to make sure I was protecting people's save data. In the next update, however, they will do exactly what you described. That's what I'm working on at the moment. I hope to have it ready by Monday, but no promises.

Time for some more explaining of what I'm up to. Right now, I'm working on making things revert properly when you return to KSC. Rather than returning to the KSC equivalent in the system you jumped to, as it is currently, you return to the KSC of the Kerbol system. The first step here involved decoupling the Warp logic from the Hyperdrive PartModule itself, which was fairly easy. Reverting to Kerbin was easy as well, as I was able to repurpose a lot of code in the newly-decoupled warp drive. However, for some reason when I went to KSC everything in orbit went screwy. Part of the time I was able to attribute the issue to simply not having an active vessel, but the problems resulting from that have cascaded and resulted in all sorts of fun issues. I usually had one of a few problems: Object that warped away was still saved to Kerbol when I came back to KSC Object that warped away was removed from Kerbol, but didn't get saved to its new system upon returning to KSC All spacecraft in orbit around Kerbol were randomly deleted All spacecraft in orbit around Kerbol got randomly duplicated (in the exact same positions they were, leading to massive explosions) I've been slowly killing these problems, one-by-one, but it seems one of the other problems pops up every time I fix something. I believed I understood how persistence works (and I still think I have the general gist of it). However, I'm getting very inconsistent results with saving and loading, which doesn't make sense to me. The first bug listed was an easy fix -- remove the active vessel from FlightGlobals.Vessels, rebuild the ProtoVessel cache (by creating a new FlightState), save, delete everything in FlightGlobals.Vessels, create another FlightState, add the active vessel back again, and save once more. However, while the first save worked fine (removing our active vessel from Kerbol orbit), the second didn't save any vessel at all. Creating a FlightState seems to populate FlightState.protoVessels with all vessels in FlightGlobals.Vessels -- or so I thought. However, although it creates a perfectly good persistence file, the second save doesn't add any vessels to the flight state and I don't know why. I did fix that issue at one point. However, when I did so I would somehow wipe all of Kerbol's craft every time I jumped for no apparent reason. Finally, I managed to successfully create a "snapshot" of Kerbin every time I jumped, but when I returned all the craft would be duplicated for no reason. I only load the craft once, and they are only listed once in the file I'm loading from. All the print statements I use whenever I create a new craft get printed exactly once. However, every single craft got duplicated for no apparent reason. I fixed that issue by scanning all the vessels in FlightGlobals every time we entered the Tracking Station or flight mode and deleting any vessel which had a duplicate ID. However, doing this caused the same issue I mentioned earlier where crafts that warp away from Kerbol don't get saved to their new system. It's not that I'm deleting them -- right now I am literally saving every single vessel in the system by using Unity's Object.FindObjectsOfType<T> function. However, for some strange reason the active vessel simply isn't being saved to the FlightState, even though the FlightState says it should be saved. Here's what I get in my FlightState: FLIGHTSTATE { version = 0.25.0 UT = 3105575.30545282 activeVessel = 0 mapViewFiltering = -1026 } This should have VESSEL tags on the inside, but for some reason it doesn't and it's driving me nuts. I'm going to keep punching away at it and seeing if I can fix the problem, but I have to reverse-engineer the entire vessel activate/deactivate logic in order to work out what's going on (since I believe we can't decompile the KSP source and look at it under the EULA). This is probably a bit of a confusing post if you don't have any experience with programming or knowledge of how KSP works, and I apologize for that. It's a bit frustrating throwing code at the wall and seeing what sticks, but once I do have something working, I'll see if I can simplify things down a bit and share my knowledge with the community at large to help others playing around with persistence. Hopefully I'll get this resolved in the next couple of days and I can move on to other things. A lot of the randomization has been revamped, and I'd like to randomize the radii of planets to give more obvious SOIs. I'm thinking about adding in some ModuleManager support for Interstellar, but I want to keep ModuleManager optional if I can to reduce dependencies. I'll have to see what happens if I reference ModuleManager without having the mod installed -- if it's possible for me to recover from the error, I'll probably implement something involving ModuleManager and Interstellar. However, if the error is not recoverable (although I don't know why that would be the case), it would have to be Interstellar implementing stuff from this mod.

That last bit is indeed a known bug -- I think it's fixed now, but I'm not entirely sure. In any event, you can always restart KSP itself and everything will be a-okay again. As for your first question -- does the map view keep zooming further and further out until you hit tab to focus a planet? I'm not sure if that's a bug I'm introducing in the next version, or if it's in the stable version. I'm taking a look at procedural planets. It looks like KSP has some sort of noise generator built-in, which I can likely repurpose to generate planet terrain. There's also a PQS class which I think handlles terrain generation and many, many different options for it. I honestly have no clue what it does, but I'll keep looking at other mods that modify terrain to see how they do it and imitate what they have done. In any event, it will probably be a lot of work. Doable, but a lot of work. I do actually have a solution to this. I have finally gotten persistence to work properly! I've reverse-engineered the Autosave/Quicksave functionality, and I think I have a general idea of what it does. What little documentation is out there was very helpful, but I still had to do a lot of experimentation before I figured out basically how it works. But now I have successfully generated persistence files local to each system! A sattelite in orbit around Duna will no longer be in that orbit once you warp to another system, but when you warp back to Kerbol it will still be there! Here's basically a breakdown of how it works: 1. Take the active vessel and remove it from the list of vessels. This makes sure that we don't get cached before warping, thus preventing duplicate ships. 2. Create a new "blank" FlightState. This will automatically populate the ProtoVessels used in the persisitence file using our list of vessels. Since we just removed our active vessel from that list, this will effectively be a list of inactive vessels -- vessels which will be remaining behind when we warp. 3. Save the game, using GamePersistence.SaveGame(). I specify the filename to be <lastseed>_persistent.sfs. This is going to be the last "snapshot" of the system we are leaving. 4. Get a list of all vessels except our active vessel and destroy each one. You need to call Game.DestroyVessel() on each one in addition to Vessel.DestroyVesselComponents (). Note that this will not kill crew, and even if it did we've already saved our game. 5. Travel to the new system! 6. If we do not have a persistence file already for the new system, simply give ourselves another new FlightState. Honestly, I'm not sure if this part is necessary, strictly speaking, but I'm too afraid of breaking things again to play around with it. 7. If we do have a persistence file already for this system, DO NOT USE THE REGULAR "LOAD" FUNCTIONS. I tried for ages getting them to work, and the only thing I managed to accomplish was deleting all my crafts and turning my active vessel into an asteroid somehow. Instead, we want to selectively load just the crafts from the persistence file. 8. To do this, we get the full directory to the persistence file we want to load. Rather than using GamePersistence.Load(), create a new ConfigNode and pass it the full path to the persistence file. It will read all the lines in the persistence file for you and automatically generate a tree of nodes. 9. Now, we need the root node. If you look in any persistence file, you'll see things in ALL CAPS. These are the names of a new node. To get to our FlightState, we have to navigate first to the GAME node and then to the FLIGHTSTATE node. 10. Create a new instance of the FlightState class and pass in the FlightState node and a reference to the current game. This will generate the ProtoVessels for you, but it won't actually load them into the game itself (that part drove me crazy because I thought it simply wasn't reading my persistence file correctly). 11. Iterate over all the ProtoVessels in the FlightState you just created and load them manually with ProtoVessel.Load(). 12. Update the game's FlightState with your most recent FlightState. 13. Now that all the vessels are loaded in, you can add your active vessel back to the vessel list. 14. I make sure at this point that the camera is still focused on the active vessel -- I'm pretty sure that's redundant at this point, but better safe than sorry. 15. Save the game over the old persistent.sfs file. Now the persistence file is completely localized to your present system! At the moment I don't revert back to Kerbol when you go to KSC. That will probably come next. The big problem with that is managing the tracking station -- when I tried to bring the tracking station into all of this I managed to break everything. I do plan to have some way of managing it, but at the moment I have no clue what form that would take. I don't think I can add pretty new buttons to the tracking station, so it would have to be an ugly GUI window somewhere. Any ideas as to how the tracking station should be handled?

That is correct! At the moment, I'm not generating any new planets. If I ever do generate any planets, I will maintain a "lite" version which doesn't have the planet generation, specifically for that purpose. Furthermore, all calculations are only done when you jump. I do write to the hard drive in the next update, which might slow down some absolutely ANCIENT computers, but the size of the files are so small 99.99% of people won't even notice. Even if copying over the persistence files did tax your computer, it would only happen when you jump -- between jumps, KSP will act as normal. One more thing: Should I put in time dilation effects, or should I leave travel to and from instantaneous? It would have to be somewhat toned down from "reality" (so no 100-year absences from Kerbin), but if time dilation is included it would mean more time would pass in other solar systems while you travel there than the time it takes you to get there. If it were included, it would likely be on the scale of months to years. I'm a bit hesitant about it, since I know it'll probably screw with times set up with Kerbal Alarm Clock and stuff, but it would depend on how "realistic" you guys want this to be.

Ah, I see. Yes, oxygen atmospheres will be a bit more rare -- there's currently a 2.5% chance of having a planet with a breathable atmosphere (I believe), but I might reduce it a bit more. Right now, for gas giants I've just been using Jool. I'm not sure how much of Kopernicus I'm going to need to do that -- I'd prefer not to have too many dependencies (more stuff to break). However, it is something I'm going to look at. I do have something of a breakthrough in that I managed to find a way to stop crashes to desktop! Turns out I had a malformed regular expression that was corrupting save data. I've since fixed it and the problem appears to have gone away. At the moment, I'm able to generate fresh persistence files whenever I want. It's not much, but it's a step in the right direction. There are still bugs in the system (I just accidentally deleted my own save -- whoops!), but I'm working on ironing them out.