Gaalidas

I tried it with both the small wheels and the medium wheels, but I also noticed a while back that the medium track wasn't responding to height changes either. I didn't test all the parts for the rotation thing. It's very subtle, and it took me a few various tests to even notice it. I even tried to take into consideration if I was on an incline or not, but it doesn't seem to matter.

So, I've something to report. I tried this with two different sets of wheels and in two different locations around Kerbin and it's not looking great. First off, it looks like neither context menu nor action group control of the suspension height (aka ride height) is working. The wheels sit at the same height no matter what I do. Secondly, while under power (so, while the W key is held down, not when just cruising) I'm getting a strange rotation of the vehicle. It's not always the same direction either, but both powered forward and backward movement seems to not go quite straight even when on a flat surface. So, I'm unsure if this is a problem with the code, the model, or something else entirely.

Unity markup, HTML markup, basically the same thing in this case. Except that HTML markup wouldn't be considered valid according to the recognized validator services. For proper HTML, CSS is required. To figure out exactly how they did that one, you could probably dig into the DLL files with something like ILSpy and see if they have those defined somewhere in there. Most likely, however, is that they have their own stuff in a resource of some sort, possibly a string database... or whatever they're called. It's been a while since I've messed with resource files.

It may be something to do with gravity, not just force. I'll need to go back a few years, but I remember Scott Manley doing an experiment with the interior of a circular, hollow, space station where he created artificial gravity by spinning the station and was able to drive a rover under that gravity. Now, granted, gravity is simply force directed in a specific direction relative to the body in question, but I have a feeling it needs to be force that can be measured by one of those gravity measuring devices. So, if the force is being applied to the kerbal, but is not measurable by one of those gravioli thingies, then the kerbal is just being pressed up against something. If, however, the gravioli detects a gravitational pull then the kerbal might try to stand on the surface that is "below" them. EDIT: or just read lo-fi's post. I spent too long thinking about what I wanted to say.

Getting an odd error when toggling the landing legs that have the auto-balancing applied to them in the editor: NullReferenceException: Object reference not set to an instance of an object KerboKatz.ModuleAutoBalancingLandingLeg.lowerLeg () KerboKatz.ModuleAutoBalancingLandingLeg.toggleLeg () KerboKatz.ModuleAutoBalancingLandingLeg.toggleLegEditor () BaseEvent.Invoke () UIPartActionButton.OnClick () Specifically, I'm only getting this error when the module is applied to the LT-1 landing legs, the rest seem immune to it.

I've been around since before the toolbar mod even existed. From what I can tell, and I went through the same thing developing the kerbal Foundries GUI (very annoying), is that the code, within the QuickScroll source files, specifically calls for the GUI to pup up when the event associated with the onHover state of the button is reached. So, it's actually not anything whacky about KSP or Unity here, it's deliberate and rather annoying. So, I attempted to recompile from the source. However, upon launching KSP with my personal recompile, all worked well except the scrolling part. Whenever my mouse was hovering over the part list and moving (what direction didn't matter) it would automatically scroll every scrollable element in the entire part list area as long as the mouse kept moving, no matter what button was pressed. So, for the time being I've gone GUI-less, but I'd rather have the settings available. Not a huge issue, just something for the future.

Like I said, already did that a long time ago.

Which means, I would guess, that pretty much anything that can be used as a part can, potentially, be used as a static as long as you don't intend to launch anything from it. Even then, you could probably just put a dummy launch pad static on your own non-launchable static and make it work alright. - - - Updated - - - I wish to point out that launching from the Mun has absolutely no issues from what I've experienced, so we can probably assume Minmus would be okay. The real issues come from trying to launch from a different planetary SOI outside of the Kerbin's. Even then, EPL managed to make it possible to do this so it's probably not so much the launching from that location, or moving the ship spawner to that spot temporarily, but likely a limitation of how KK actually moves your craft and camera into the correct position, while dealing with the transitions between SOIs.

Hey, something I was thinking about the other day and forgot to post about... Something that would be nice for the suit/head GUI would be a label for the currently selected head (by file name) and for the current suit (by directory name) for those cases where two suits looks very much alike and the small preview screens make it difficult to see properly.

No need to vote, guys. The linked config that started this discussion is is the MM patch that I've been updating in the wheel config repository. The MM patch has been a thing for a long time, just not officially released. I even recently updated it to include the DustFX module, which will be functional once we release 1.9 of KF. Unfortunately, we never actually implemented a damage and repair system into the KF modules so, for the time being, this effectively makes the wheels indestructible (as far as the functionality that is, not the whole part). You can still break the entire part in the usual way, but the wheel won't require any repair work while on the field. The rest is a brainstorm session: The only way we could make using KF with the stock wheels any easier is if we found some way to hot-swap the control modules being used for the wheels. There's another mod being developed out there, though I forget the name of it, which is attempting to create a system for being able to swap out the modules that are active on a part in conjunction with a texture/mesh/fuel-capacity swap that we've already seen done in several ways. I'm waiting for that development to make a working appearance before I start to brainstorm ways to use it for our purposes. In theory, we could then keep the stock modules on the part and simply add our modules at the end of the config, then set up a module that would reference the different modules much the same way that the mirror modules in KF can reference the mesh objects by name, and then swap them. Alternatively, if this development never sees daylight, we might be able to mimic stock wheel functionality and put a swapper module to swap out the config variables between KF behavior and pseudo-stock behavior. Or, maybe simply set up another switch in the settings GUI that would simply, upon being created in the editor/flight, just remove all the KF modules from the part and leave the stock ones alone. In this same way we could have it simply remove offending modules from the stock wheels during the running of the game much like we can add DustFX to a part if the wheel collides with something and doesn't find the DustFX module present. Lots of different ways to handle stock wheels. For the time being, an MM patch is the easiest way to make it happen.

Oh yes, it's getting better and better. I've even been able to actually run KSP recently... though that is probably more to do with eliminating huge part mods that I really don't ever use but so with I could have. Every little big helps. Of course, I sacrifice a lot of detail and whatnot and also convert everything to DDS that I can, so I'm not going to notice much of the performance upgrades in relation to texture sharing from this mod alone. I think the end users will appreciate it though... or at least, they won't complain about it. - - - Updated - - - That could be entertaining sometimes. - - - Updated - - - Not only do we need to update those configs, but I'll then have to update the MM patch. See, lo-fi? I told you... (a long time ago)... people would want to replace the originals with your module. It's simply not enough to copy the originals, cause then everyone would have to swap out their wheels on their rovers.

Finally, Navball support without the need for a MMU vessel.

Technically I really have no clue about modelling. I'm barely able to keep up with texture formats and their respective performance hits. I'd have trouble making a simply cube, even with a "click here to make cube" button. So, lo-fi... I noticed during my playti.... err, important mod-related testing... (yeah, that's what it was) that the surface track's diffuse texture seems to be missing.

That video had me holding my breath.

Wait... when did making fuel tanks become simple? I'm so out of touch these days.

Wouldn't want an arctic biome spawning on the equator would you? So, if I may return to a line in the first post and answer it... "simple" may not be a very accurate way to describe this idea and/or mod.

That sucks. Then again, live broadcasts can get tedious at times. Better to be able to skip the awkward stuff.

A little request for when you have the time... In QuickScroll, could we have the GUI not pop up on mouse hover? It's getting really annoying having to move my mouse out of the window area to expedite it disappearing whenever I accidentally hover over it while editing my various vessels. I would think that activation of the button would be enough.

Idea coming to the surface... hit the deck if you want to live.... Okay, so taking screenshots of the entire screen is possibly a performance killer if you're on a non-gaming system or if you're running a lot of mods and your RAM is already nearing maximum... so how about this (no idea if it's even feasible, just bear with me for a few moments): Have a GUI window that represents a "frame" of some sort in which the user could resize and position to fit where the screenshots are to be taken, and then have the shots only save what is at the GUI's screen coords + the height and width of the frame. Just something to mull over. Only other idea would be to allow this to interface with other screenshot automation mods so that captioned screenshots could be taken automatically as well (along with the usual caption automation variables as well, if they exist.) I don't sue any of those mods, so I can't be certain what is possible, but it's something to think about.

I never intended to add new ones. I had enough trouble trying to position elements in a GUI for our settings menu, much less trying to position nodes in a tech tree layout. My position on the whole thing is that just about anything we create can be reasonably placed in a stock tech node, so why create a huge tech tree full of nodes that most users won't ever need? But, as I am not a career user, I pretty much loose all rights to voice such opinions other than what I just did. I've put a few of our parts into some advanced nodes, considering the advanced code behind them and the whole "defying the laws of gravity and physics to a certain extent" but I'm not going to go through the trouble of installing CTT, starting a career, struggling through career to experience the tech levels of each node, and balance our parts against it when i really have no interest in even running a career game with the heavily modded game I'm running right now. My main draw towards KSP is the sandbox experience and the extensive modding capability, frustrating as it is sometimes. You just don't see this level of freedom in other mod-friendly platforms... ever. However, like most other mod developers, and I believe I speak for the main author lo-fi as well, we're open to suggestions on where to place stuff. I would suggest waiting for the impending update before making your decisions though. From what I can tell, everything from stock exists in CTT, and it also looks like it's easy enough for mod makers to create alternate paths for the tech advancement without messing with the nodes themselves or the technologies within them, so in all it's pretty easy to work with. The CTT mod itself is simply a bunch of new tech node definitions and a bunch of MM patches to put everything together. As long as you don't modify what they've done, or run your patch after the CTT patches, you're going to be fully compatible. I would think that adding new nodes is only a problem when CTT is updated with more nodes that have been added through official channels (so to speak) or when a user starts to clean out old mods that they've already unlocked nodes from. For the most part, the wheels and such shouldn't need adjustment from their stock positions, and if there is a need for it the CTT has pre-noded (lets see what Aqua's translator does to that word) a number of tech levels, some of which are unused and hidden by default. If you need to use those, you simply need to make sure the prerequisites are not hidden still, or make sure you're not putting anything higher up than what is currently visible.

Playing at all has become a thing of the past since taking up modding more me. I intend to fix that as soon as we get this thing released and can relax a bit. I nabbed a copy of the CTT mod is preparation for writing a config for it, so all I need is some direction on where to put them. I would have figured the CTT mod would still have nodes that correspond to the stock tech tree, making CTT integration a less urgent matter. EDIT: in a moment of inspiration, I set up a preliminary config which really only modifies the repulsors and the APU. I figure other parts can simply unlock with whatever they unlock with now since, as far as I can see, CTT doesn't remove any nodes. It simply moves them around and spawns new ones. There's not even a plugin included.

I always delete the CTT configs, honestly. I play sandbox usually, so there's not much point in keeping them. If anyone has suggestions for tech nodes to use, I'll certainly look into it though.

Fixed your little booboo lo-fi. "axRPM" just ain't gonna cut it. Just stick around Aqua. I'm still just a dabbler in these things, and lo-fi can't do everything himself.

I look forward to hearing about your various plans for the future, but lets get this baby shipped. I'm looking forward to seeing dust clouds in future videos and such. It's been a long road getting that stuff where it is now.

I appreciate the attention to memory footprint. A ramp for rover access would be great, if it's not already available. Or the above mentioned false landscape to provide a smooth access to the facilities. Multiple launchpads would be awesome too. Finally I might have a good site for launching multiple rockets in formation using BurnTogether mod or something.