vossiewulf

Thanks Harry, much appreciated, that gives me a lead to follow. What I did was take the whole gamedata folder and copied to google drive and then to the new machine, it looks like one of those steps failed. At least I have a trail to follow now

Attached is the log, if someone can look at it - I have and there are numerous errors but as I've learned looking into them several times, that's not unusual with many mods and they don't necessarily indicate a serious problem. So I can't really tell looking at this what I need to worry about, there are some things that seem pretty problematic but just not sure. KSP.log

Thanks for the responses It's installed on the normal Steam path in program files (x86). Why would that be a problem? Also, I think I can just copy and paste the whole installation, it doesn't do any registry changes that cause it to break if you move it, right? At least I hear people saying they spun up this install and that one and the other one and I'd be surprised if that meant running installers over and over. LGG you obviously have to live with this problem more than anyone else for testing all those mods, how do you move saves from one install to another?

Yes, I was aware of the scaling and have used scaled wheels for some things. However that doesn't work in this case, to get the load I want I'd have to scale to 200% and they're too big at that size. Only question I had was whether the maxLoad of 4 for those wheels was what you intended, I had a question about that since as mentioned on the face of it they seem bigger and sturdier than the truck wheels. You're saying yep, that's as you think it should be so question answered. Otherwise, as already mentioned, I changed my version of that wheel to maxLoad of 8 and I'm going to leave it that way since it allows me to make a style of rover I like a lot - part of this is just aesthetics, I really like the look of those wheels and the wide stance they give any rover. Even though I know I could scale up the truck wheels or other wheels, they just don't look right for what I'm trying to do. And also this isn't a multiplayer game or even a game that people where people get competitive scores, so no harm in people modding things to do whatever they like. But I also think I have a reasonable argument on those wheels, it's not like I'm taking Packrat wheels and giving them a maxLoad of 1000 so four of them can support a battleship rolling around the Mun. Your approach to rationalizing the settings sounds like a good one though, if you have the time to do that it's probably a worthwhile exercise.

Got new laptop, went to copy my current career game across. Installed 1.30 on new machine via Steam, and copied across the full Gamedata folder plus the entire career folder from the /saves directory. I didn't see any reason that wouldn't work, just dropping them in is how I installed all of them the first time , most have no alterable configs and those that do I'd want them to carry those configs across anyway. It didn't work. I'm not sure of the number but many, many mods aren't loading and every single vehicle I have in orbit or landed fails to load because it says parts are missing. I nuked the module manager's cache files to force it to do full patching... and I'm pretty sure, since it said only 1309 patches applied, that it's not seeing most of the mods either. Which is very odd I've never seen KSP ignore a folder in Gamedata but that is how it's behaving. If this was a server I'd be checking read/write privs on the directories and files. I have all the mods still in zips and I could reinstall them again one by one by hand but I really don't see how that's different, you're just copying in a new set of static files that are absolutely identical with the ones it's already ignoring. This is what I saw on first launch after copying everything across: And this is the mod folder, obviously there are quite a few but none are graphics improvements, they're all parts/science/contracts/UI tweaks/tools. Mostly parts. I have way too many parts and I need more. NO I DON'T SHUT UP YOU. TOO many parts! Lastly remember the oddest part (to me) is it's not ALL mods. Some of them you can see from the UI are loading fine, but a majority of the parts mods and some core ones like KER and MJ are missing. Thanks in advance to anyone who can point out what I'm missing.

I've seen the drilling problem repeatedly, it's become habit whenever I check on them to stop and start them again to make sure they're running when I leave. If you look over in the Buffalo thread, along with that problem I have an ISRU that looks like it's working in every way except no fuel gets delivered anywhere. Ore gets consumed, it says it's at operating temp, it says it has a processing load, and nada. After three days of trying to get it to work I shut it down and converted the drills to mining metal and feeding the smelter instead.

The thing that made me uprate them to the same load-carrying values of the truck wheels is that the default versions were breaking when my big rover was just sitting still drilling. It was kind of odd too, it would drill for hours but then within one minute the front one would break, transferring the load to the next, and they'd all break one after another. The idea of building it on the Mun and getting it half full of metal and then all the wheels break wasn't super appealing Besides as noted they're bigger than the truck wheels and the structure if made of similar materials is much heavier on the rover wheel, but you could also say hey that's a superlight not very strong polymer because it will operate in low G. And as @TiktaalikDreaming pointed out, the rover wheel design puts the wheels farther out, putting more stress on the attachment point. So I guess you could make an argument either way. If you want suggestions, it would be to make two versions of this rover wheel - one 50%-75% of this one that is the real medium rover wheel, that will still make them bigger than say the Grizzlies that are standard for the Buffalo rover, and I don't think anyone would think of the Buffalo as a small rover. Set that version to have the maxLoad 4 values that the current wheel has. Then the existing version, the one I used on my big rover, becomes the Large Rover Wheel, maxLoad of 8-10, other values in agreement with the truck wheel, and now you have a wheel that: Looks really cool Has a really nice big footprint for stability Has excellent ground clearance for seriously rough terrain Good load-bearing capability, enabling a whole new class of large rovers like the one I made Looks really cool Thanks for this mod, fills a big gap really well with good options. And I love my giant rover, I've been having a hard time behaving myself and putting him to work, he's just so much fun to drive at 30m/s all over the Mun doing giant drifting S turns and jumping off of craters and the like, and I can see a number of really cool similar large rovers built starting the way I did with structural trusses to create a big and strong but light frame.

That's a relevant point You know way better than I do the number of things broken that are worse than this, I'm certainly not bothering to report on or discuss those items even though it boggles the mind that some of them are still there that I remember from five years ago when I briefly noodled around with KSP right after it came out. So no, I try not to make a general habit of jousting at windmills. But this one got me because, it got me, and I lost about 6 hours of designing and testing. Although in the end I have to agree with you that it's not MAX, I still say this is 1) BAD and 2) it appears on the surface to be easily fixable in a way that will in fact make the game a bit better for everyone. And that's the end of the tilting yard, no more jousting on this one. Yes, exactly what I'm saying. Not an edge case but a fairly common one, and they can prevent serious bad feelings about their game fairly easily, although that comes with a big asterisk still because I really don't know the architecture. But if it's not really bizarre for some reason, it seems like something where most if not all of the variables they'd need already exist, and it can be driven by user-controlled settings so they just need to make a reasonable guess at default values and implement.

Thanks for the quick response. Yeah I'm aware of the ISRU conversion rate, to me it seems like it should be cranked down a notch or the drills up a bit, because you can run four drills on 11% ore concentration and still come nowhere close to loading the ISRU. But that's a designer's choice and I assume it's intended to be that way for reasons I may not be aware of. Yes, I nearly melted the first Buffalo before I got control of the heating. I didn't mention that this is one of TWO Buffalos at this base. The first one is busy converting into LF/O and Mono and everything is working fine and has continued to work fine. Only this second one was having a problem, and the problem looks buggy - everything is reported as normal, it's intaking ore and saying it's working, but the resulting fuels never get delivered anywhere- just disappears into the Mun sand as far as I can tell. I tried turning it off and on, drilling while standalone and while KAS-attached to the base, resetting all the drills, basically if there was a relevant button I pushed it at least once. Pic of current base status, we have a Packrat, a V2,0... um not the Honey Badger, the Puma? Then two Buffalos and also my battlecruiser-class new mining rover that is a monster in every sense of the word. Plus I built those giant LH2 storage/light towers on that teeny little EL launchpad and had to move them into place, yeah that wasn't easy I love everything about the S.A.F.E.R. reactors except typing their names. The base has one, it also has gobs of solar and battery. I am not yet running BARIS, but my intention was that when my new very fast laptop arrives tomorrow that I'm going to start a career with the 2 billlion years before Kerbin mod and BARIS and one or more of the graphics improvement mods, but those have me pretty confused; there seem to be a couple dozen, half of which include half of the rest.

Is there a problem with this question? Do you need more info? BTW, I could not get it to work and gave up, switched the drills to metal ore mining and they're now feeding the Hacienda Iron Works, and I have an inactive ISRU.

See my response to Mr. Walrus, that exact argument can be made against every single safeguard in the game, up to and including the autosave feature that if they were to disable it, would result in a disaster with thousands of complaining customers. And you'd say, hey, not our problem, if you can't remember to save your own game, you deserve to lose all the progress, and an autosave feature doesn't make the game any better, so you unhappy folks don't even bother requesting one. And then you'd be out of business not long after that. And I'll hope you're not in the design loop on any product/software I have to use. For reference, the ONLY reasons that are valid to not include a safeguard that prevents your users from accidentally losing hours of work progress are 1) it happens so rarely it's clearly an edge case and 2) the cost of adding that safeguard is clearly much more than would be gained by implementing it. If there's any doubt at all, you build in the safeguard. And with this situation, this is NOT an edge case. And I don't think the cost of fixing is out of scale with the protection against liquided-off users that is gained, but I can't say that for sure. It seems to me what I suggested above wouldn't be difficult to implement based on what I know, but what I know is very limited and there could be factors that make a solution much more complex and costly.

Close, but not quite I think. The issue is the file structure, that is a tree. It has no conception of two trees in the same file. In the VAB they can keep a detached tree no problem because it's already instanced in memory, but when you go to save, the save file (as designed) must be a single tree with each object attached to N children but only one parent. There are several options. First, it should be extremely easy for them to be aware. I know how many objects (trees) I have rendered in the VAB, and I know which one is attached to the master pod and any that aren't. So when the user goes to save, I would know what needs to be saved in the file but also know how many detached trees there are and how many objects are in each. With a minor addition, I could also pretty easily track the number of elements (parts) that were present the last time this file was changed. So the easy part is knowing that with this save the user is attempting, he/she will be deleting X number of elements in Y trees. That's an alerting threshold problem, use judgment to set a value past which, if it wasn't intended, the user will be very upset about losing those parts. What to do with detached trees is the tricky part. If the user says "NOOOO I DIDNMEANIT!", you can't just randomly attach those detached trees to the existing model and then save that, that would create as many problems as it would solve. The correct solution is to save any detached tree of > x number of parts as a separate file, using the main model's file name as the root. E.G., Atlas IIIA _detached_parts_1. There may be other correct (as in fulfills requirement in a way the users are happy with) solutions but I think most people would be happy with that one. Then in the game general settings, there would be two new flags for the user, defaulted to on, and two fields to set the threshold: (*) Save detached parts in VAB Threshold: 10 (*) Save detached parts in SPH Threshold: 10 If you want a really good implementation you add a couple more fields to specify root name(s) to be used and also to set the path if you want to saved detached parts to something besides ThisCareer/Ships/VAB/.

No, it isn't. It's extraordinarily bad UI design. As mentioned if MAX or Maya or whatever started deleting elements just because they weren't attached to the main model, the entire Autodesk company would have to rapidly go underground to avoid the roving gangs of modelers who had lost work to such an insanely bad idea as that. Further... Why does it auto-assign crew? If you get all the way to Duna and only then realize you've been flying on the OKTO, and you can't even remember to assign crew to your vessel, that's on you. Autosave? If you can't remember to save, that's on you. Engineering report? Who the hell needs that? If you can't remember to check that your decouplers are oriented the right way and you've stayed under part limits, that's on you. And again when you get all the way to Duna to just then notice the only hatch is blocked and the crew can't get out? Well, that's on you too.

Thanks for the explanation. It's still sitting there, I'm afraid to go look lest the entire thing disappear with a sucking sound into a mini-singularity or something. And I understand, but c'mon, that's got to be a dirt-easy change to go from isGeneratingPower boolean to hasEC boolean, at least I'd assume those exist so you don't have to constantly check numbers for yes/no boolean cases

Wasn't trying to do that. I had stuff to add to the launch vehicle and the aero shell gets in the way visually so I detach it and everything below so I can see what I'm doing. Theoretically I re-attach it before saving. Yeah I know, that's the point, it sets a trap for the user to all too easily fall into, in the process losing god knows how much work. Seriously, if any real modeling program did something like this, police protection of the offices would be called for in days - the one thing a UI flow CAN'T do is set traps that cause people to lose work. Squad you know it wouldn't be rocket programming to put a check in at the point the user saves/leaves the VAB for situations in which a significan't number of parts (5? 10?) are about to be deleted permanently with no recourse, and maybe mention that to the user and give them a chance to confirm.

For one the visible structure of the "weak" wheels is considerably beefier than the suspension of the truck. I'm not going to argue it though, if it's intentional that's the way the modmaker wants it, end of discussion. However my version makes this rover possible, so I'm sticking with my settings for those wheels. And here I'm "testing" its toughness, skip ahead to 1:20 for the first jump, we lose the front two wheels but she's still kicking enough to climb the steep crater wall at 20+m/s and jump out the other side at 4:30. It's even more awesome on Kerbin where you can't flip it no matter how fast you're going.

Is this intended? I "corrected" mine, making the big "medium" wheels have the same load-bearing capability as those little spindly truck wheels BTW just looked in on SSTU, that looks extremely spiffy. I will be looking forward to that release.

Too bad the Heinsenberg name was already taken, as it's way more appropriate here- it's a brilliant rover-driving wave until you look at it, whereupon the driver wave function collapses into a stupid unmoving hunk of metal and plastic.

Can someone explain why if I stick two parts together in one stage and then try to leave the VAB or load a different file, it prompts me to save, but if I detach the entire 15 stage launcher, forget that I've done that because I can't see it, hit save and leave it will happily delete hundreds of parts and days of work without any warning whatsoever? You can't check on save and notice that the save will be deleting hundreds of parts across a dozen stages and at least ask if that's the intention? You know, if (partsDeleted > 5) { ASKFIRST()}? I've been using MAX since it was 3DSr4 for DOS and every piece of graphics software and most of the coding tools out there for 25 years and I never lose anything, and I just lost many hours of work to that "feature". Of course with all of those, the only way something gets deleted from a scene is by explicit delete actions of the user, not just by the user detaching objects in the same way they do hundreds of times in each VAB building session, but forgetting to reattach before they save.

Sigh. Ok, thanks again Maybe I can manage to see it working now.

Unfortunately switching away doesn't seem to be working either. I just went through the process until it said BV control lock active and then switched away either to the base right by him or nearby vehicles, he's still sitting there immobile. However it's night now, so maybe this rule is stopping him? He has 40k+ batteries and can drive easily all night, does it really require active production and not just sufficient EC? To start moving your power production must be at least 35% of wheels max consumption You can see the things I'm switching to are certainly within physics range.

Nope, sequence was Mitdin Kerman stuffs (or tries to) a 2.5m decoupler into the recycler, boom, rover jumps and.... just keeps going, at .2m/sec with a very slow roll. As you see everything seemed to work, but nothing affected the new and scientifically unique trajectory it was on. If you watch to the end of the video I have it saved with it floating off, if anyone at Squad is interested in looking at it please let me know. Thanks Goal was to make something that drove very well, had tons of space, and was basically impossible to flip over. Or put a better way, why settle for half or even full measures when massive overkill is perfectly legal. It's basically an Octo-Girder Modular Truss for the front "fuselage" with the top of the T being a Spinal Modular Truss. Provides massive amounts of room, is light and strong, and sets the rear wheels so far outside the CG that you can't even make the wheels lift in a turn - on Kerbin you can do a quite tight max turn at 30m/s and I noodled around with the front wheel geometry until it turns equally well at 1m/s. Procedural wings for panels, full science suite for road trips, MJ and BV modules. It'd work just as well with Drill-O-Matics and an ISRU for fuel. Oh, but I had to hack the KF wheels. This did not make sense to me, that a wheel half the size of these with much lighter structure was twice as strong: And my wheels kept breaking, so I changed the "Medium" wheels to have the same load-bearing capability as the single truck wheels. And then I decided to try some serious jumps to see just how much it could take. Skip ahead to 1:20 or so if you're not interested in a how effectively a high-speed hovercraft moves over the Mun's surface. And then to 4:30 or so to see the jump out of the crater.

Thanks! Much appreciated.

I have a BV unit on a rover, it's activated, I used the control panel to set a target, I hit the Poehali button, and in big letters it says Bon Voyage control lock active but.... nothing happens. Rover does not move. I've let it sit there for several minutes, nothing. What stupid thing am I doing/forgetting? If you think it's a bug, I 'll pull the logs but first guess is user error. Thanks in advance. If it helps, this is what I see:

I just delivered this mega-rover via EL to my Mun base, among many things it has a K&K recycler on the back, attached to a K&K smelter. So I was driving it around, finally able to clean up the base from all the debris of a bunch of deliveries, when I stuffed in a 2.5m stack decoupler. As is often the case with something that big, it decided to explode instead of being scrapped, and my 30 ton rover jumped, seen that on explosions before, no biggy. But then I noticed the rover didn't seem to be coming down. Valentina the pilot is missing, and although the cockpit RCS thrusters and the SAS wheel seem to be trying, it doesn't respond at all, just keeps drifting on a very-slowly tumbling trajectory. Oddly I could retract the ladders and extend the solar panels though. The video below starts a bit post facto, but it took me a few seconds to notice something was amiss. I reloaded a save so no big deal, Just wondering if this one has been seen before.