Kielm

This is usually caused by either using an unsupported unarchiving program (i.e. trying to unzip it with the wrong program) or the file download was interrupted and is incomplete.

Thanks for this refreshingly detailed reply! I'll help you out. I checked the .craft file: The rover body had been tweakscaled to a very small size. Could this have been rounded to zero somewhere along the way? Craft file zipped up here (SPH) What I'm less sure about is the unknown part names. The .craft file shows 32 instances of "partname = " but 29 instances of "part = " - the uncounted parts are stored 1.11 EVA experiment kits, repair kits etc, which might account for the unknown parts. Could that be it? EDIT: Even more confused about the missing mass for science.module and scienceBox - these parts have tweakscale modifications assigned but clearly have mass in their configurations. The only way I can see their mass being reduced to zero is if the rounding is being done to ... one decimal place, which doesn't seem likely. The only other module I see that might possibly affect it is ModuleCargoPart from KIFA (Kerbal Inventory For All) which allows parts to be stored in cargo. DOUBLE EDIT: Here's the (only) roverbody.v2 in the save file:

Well no, all I can say is "they don't do it when I don't have all these new mods" - this is a new issue in this career save. Previous game did not have parallax, kopernicus (GU) or tweakscale. Other new mods are things like commnet constellation, Chatterer, scatterer, KSPIE - mostly QoL with the exception of KSPIE, that I don't suspect are interfering, but who knows. I'm working through the delta between this career and the last one, and the only new thing specifically on rovers is tweakscaled parts. But then again... parallax, kopernicus, and god knows what else could be squirrelling away in the background, with parallax throwing an awful lot of highly suspect wheel-based physics exceptions. However, I did spot this in the log, so I will post the full log below. Logfile:

@Gameslinx Still having the issue with rovers and I noticed an awful lot of nullref spam related to rover wheels in the ksp log (it's 40Mb unzipped). There are quite a few parallax related errors in there, thought you might want to have a look. Appreciate it's early days for parallax collisions so this is to be expected! Currently chasing up tweakscale and parallax as a possible cause. Parallax is throwing a metric ton of rover wheel errors but it also occurs without parallax (just less quickly), so I'm not sure what to do with that.

Hey, I'm having some... unusual issues with rovers, and having done the rounds on parallax, bon voyage and other threads I've started to think perhaps tweakscale could be a factor. https://imgur.com/a/jkSsH7D Not pointing the finger at this mod - it's more than likely a conflict between parallax, bon voyage, kopernicus etc, but asking the question; Ever seen anything like this? Issue occurs on loading a craft. It gets a bit... warped and kraken attacks follow. Currently using KSP 1.11 and Tweakscale 2.4.4.3 but I will update as I see there's a newer one available. Removing parallax didn't fix it, sadly, and I'm confident that the rovers used are kraken-free minus the tweakscale parts (I've used them tons of times in other career games). In terms of 'mods that could affect physics', I don't have much else - KSPIE, USI suite and a bunch of QoL mods. Thoughts? P.S: I'd post my logfile but that's 40Mb due to Parallax nullref spam - that's another story.

This. I wasn't sure whether it was BV or parallax (which seems to make it worse) but it's not just you. I have the same problem. Attachment nodes become twisted and/or rotated, or offset/misaligned. It's intermittent too, yet to pin down a precise cause. EDIT: See below

Hey @Gameslinx Mod's still awesome! I'm unfortunately having some physics-related issues when using the parallax colliders, specifically affecting rovers. It took a bit of pinning down because the issue doesn't manifest until a save is loaded, so I can only assume it affects the way craft are saved when on a surface with parallax colliders. I pulled all sorts of mods out of my gamedata to try to pin it down but parallax was the one causing it. Pictures are worth a thousand words so here you go: The theme here is twisted / bent attachment nodes or messed up collisions between parts, or both. It's almost like the craft is mid-destruction when saved and when it loads it just... finishes that destruction. It's entirely possible that this is specific to USI rover wheels and removing parallax just removed the conflict, but looking at the Akita rover wheels (that's the first two screenshots) I don't see any unusual modules in the configs: Reproducing it isn't 100% reliable, but landing a rover on the Mun and then using Bon Voyage to travel it around a little seems to do the trick. Sometimes just quicksaving and then quickloading (no interference from bon voyage) will cause the effects. I will state that I've used these rovers extensively in previous career games (100+ hours) without this issue occurring, but I do vaguely remember this being an issue in stock game a couple of years back. It's almost like the saving feature is using the terrain collisions to affect all the parts and then saving it, instead of just saving it as it is. Odd! EDIT: Actually it could be a conflict with the way bon voyage resettles craft as well. Didn't think of that til just now. Double EDIT: It does look more likely that it's bon voyage itself causing this problem.

For anyone else having this issue, it appears to be related to parallax collisions introducing some physics jankiness - nothing to do with USI's awesome rovers. EDIT: Actually, could be bon voyage itself causing the problem.

That's a negative. Nothing really unusual. I'll try out another rover just to be sure - the Malemute usually works pretty well.

Wait what? I'm currently playing with just KSC as the ground station as it feels a bit cheaty to have them all, I didn't know that choosing specific groundstations was an option?

@RoverDude I'm afraid there are some bees in the Akita rover. Backstory: I landed a tidy little Akita on the Mun for some science rover goodness. Problem: 90% of the time when I switch back to the rover, it has been attacked by a swarm of Mun-bees and looks... well, to use the technical term, janky. Note the general screwiness, and separation/misalignment/twisting of attachment nodes (you might have to zoom in). Ignore the 100% intentional orientation in the final screenshot (not related) but notice how the parts are misaligned and twisted? Rover looks fine before switching away. Side effects of this are mini-kraken attacks - colliders go a bit nuts and the rover spins wildly, or bounces once on loading and then spins to destruction. I know it's not a consistent problem as the rover I built in my last game was simpler but had no issues.

Ah. That explains why the USI Akita wheels didn't work. Thanks. This is a fantastic mod @Gameslinx

I'd check your settings to ensure they're actually still bound - at least one other person has reported key bindings not sticking recently. As far as IVA goes - if a craft doesn't have IVAs or the Internals folder is missing for that part then the IVAs won't be available. Lastly, there could be another mod stealing the key bindings for C/V. I'd start with the utility/helper mods (part mods or "expansions" like Mk3 Stockalike probably won't touch them) and go from there.

You can find the answer on the wiki under logistics https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Logistics)

This mod is well placed for expansion into a slightly more realistic model of communications networks, which might be well-suited to RemoteTech as well. e.g: Increased antenna diversity to encompass a range of frequencies better suited to represent career progression i.e. (Relatively) low frequency (VHF, UHF), low-bandwidth starting antenna Mid-range, L-S band antenna (around about the Mun/Minmus landing stage) C-X band antennas for the interplanetary exploration stages Ku/Ka (and potentially above) for transmissions across the solar system & beyond Yes - I'm aware that increased frequency doesn't imply increased range but given the implied increase in load/connections this will soon make sense. However, lower frequencies have the issue of having a lower throughput of information (generally speaking). Adding more devices while still using a time-division approach to communications (each device transmits at a certain time) severely limits the number of devices that can connect. Thus: Bandwidth limitations on lower frequencies, limiting the number of direct connections in a low frequency constellation - which would be able to sustain less devices than a higher frequency one, and/or suffer limitations on data transmission rates. A limitation that could be alleviated through research? Thinking of relays as simple 'repeaters' as a simple approach Treating relays as connections in their own right (but taking up a fraction of the bandwidth of a direct connection) would be arguably more realistic Range limited by power & efficiency Frequency has little impact on range of a transmission in a vacuum* - power and the type of antenna (e.g. parabolic, slot, phased array) are more important. Higher power requirements for longer ranges, less so for more efficient / directional antennas Edge cases for certain frequencies - e.g. ~20Ghz, 60Ghz are quickly attenuated in atmospheres, HF/lower VHF skywave communications (although, might be tricky to implement that) CommNet Constellations provides an excellent framework for taking a deeper dive into the communications aspect of KSP, which doesn't generally get much love. Overcoming more realistic limitations could be a fun challenge! *There are caveats to that statement that are probably beyond the scope of this comment.

You can have more than one antenna on a vessel. Ground stations can have multiple frequencies. So for ships within Kerbin's SOI for example, you might just have one frequency & antenna. For comms outside the SOI you could have one relay sat on a different frequency, linked to the ground station, and relaying only on that frequency to other satellites around other planets. What I'm not clear on; if I assign a geostationary relay satellite around kerbin to frequency say, 50, and relay that to Duna's SOI and then switch to a local frequency (say, 17) using a relay with two antenna, if frequency 17 is only for ships in Duna's SOI, will craft on frequency 17 still have comms to kerbin (via 50) if the relay sats have a connection, but there's strictly no Freq 17 at Kerbin's ground station? Or would I be reliant on local control in Duna SOI on 17? If signals can be combined and split by relays then it'd be useful to have a diplexer or band-pass filter to make such a feature explicit. If they can't then that would be a useful feature @TaxiService

Well, you can either look in the tech tree or check the CTT.cfg (the community tech tree patch) that comes with FTT. Either way I think we've established that you have the parts (Orca) so there doesn't seem to be an issue here. CTT is big, but it's not so big that you can't look through it

The Honeybadger command pod is under heavierRocketry, some of the ducted fans are under fieldScience, and some of the structural pieces are under veryHeavyRocketry along with the Orca command pod. That's on the normal (non-CTT) tech tree. If you're using another tech tree then it could be elsewhere. You can check the .cfg files for parts to find the tech that unlocks them, but this could be changed by any patches to the tech tree: TechRequired = veryHeavyRocketry entryCost = 7600 cost = 3800 category = Pods subcategory = 0 title = 'Orca' Command Module

To use the new Konstruction features which are still in pre-release (i.e. not finished) you'll need the USI Constellation pre-release here. It includes the full USI suite so you might have to remove the stuff you don't want. I replaced the Firespitter with just the plugin/dll as I didn't want those parts. Big question... MKS has a long production chain for building Material Kits and Specialised Parts that are used by GC. You could read a guide here or refer to the wiki here. If you're talking just about the Konstruction changes then it works similarly to OSE Workshop - try looking here for a better idea of how it works. It sounds like you're pretty invested in your current game. I wouldn't wait for the new mechanics if I were you - it could be a while, it could be today. There may be bugs. It may still use GC. It may not. It's unlikely you'll be able to build complete craft from scratch using just Konstruction, it will probably be GC / whatever RoverDude has in the works for MKS. If I were you, I'd stick with your current system for now but be prepared to change it.

Looks like a botched install - it's missing a lot of textures. Suggest you remove both mods and install them again - make sure you follow the instructions carefully and install any dependencies.

Hmm. It could be Sigma Kopernicus Scatterer GPO I see here that there are problems with flickering in some versions of GPO, so that's probably where the problem is, sorry.

You could also try disabling "Celestial bodies cast self-shadows" in the options menu.

Ooof, I'm an idiot. I was about to post a logfile about CommNet not working before realising I'd accidentally downloaded the latest CommNetConstellation-1.5.7-cnm-144-commnet-manager-port-2 which requires CommNet Manager (which I hadn't installed). As my penance I will now install both and report any bugs EDIT: Works a treat on 1.11 so far

Oooh, I was contemplating what mods to add into a new career game (something broke unity in my last one so I'm starting over fresh) but it looks like Nertea is updating a bunch of mods, maybe I'll hang fire for a bit

They don't have storage for credits atm, add the storage from one of the logistics modules' cfg files as a temporary fix