Gaalidas

I think we've made a breakthrough! My mind is so blown right now...

Unlikely. No word here or on Github from the author, and no one seems to be able to figure out what needs to be fixed or how to go about it.

I've been a long-time user of LLL (a year at least before I even made my first forum post) and I've received that error about modelx.mu for as long as I can remember. I also know I've been able to fix it by simply removing a file somewhere. I'm about to reinstall this stuff again, so I'll probabably have to recall the workaround in a few minutes.

Actually, lo-fi has already reinvented the wheel. I know, it blew my mind as well, and I was there for the entire process too. All other wheels using the old module are, unfortunately, made completely inferior now.

He's a modder in high demand these days. If you don't get a message in quick, it'll fill up again before you can blink.

That's... really sad. I've always wanted to try building a rover that's just down right insane in its size and scope. We're talking about something like a large structure on several spider-leg style stilts stretching out to the sides each with their own array of tracks and/or wheels. Time to see just how many of these things can be working together on a single craft before lo-fi's code goes berserk.

I forget easily that we're not all in on the deal. Someone has to be the odd-ball out though, and I appreciate you for being that poor unfortunate soul. It makes room for me to be on the inside. If that doesn't make you feel any better about it, do not fret. I wasn't actually intending to make it easier for you. I'm just talking to hear my head rattle.

I do love that one about the anchors. No one said anything about them not ripping the craft apart. All they were required to do was stop the craft. Success!

Considering I don't reference from a local copy, but rather from the KSP directory itself, it should be all updating properly no matter what. It's a confusing thing, but since it seems to be a local issue I'll fiddle around in my off time. With the success of your compile, at least we know I can make little adjustments here and there without negative impact. For instance last night, while trying to figure out my problem, I discovered an odd case in one of the files (I forget which one presently) where you had two functions with events/actions defined above them. What's nuts about it is that the field labeled "Gear" and attached to the default Gears group was also attached to the function for "brakes" and the other event/action (whichever it was) labelled "brakes" was attached to the function called "Gears." I looked at the content of the functions and those seemed to be in the right place, so I just swapped the function names so it all fit properly. As far as what happens in each instance, considering the functions don't actually get called by name anywhere else in the code, it probably has no impact at all on what actually happens in game. As far as reading code, it's definitely an improvement. I'm going to try and commit that one in a little bit here. EDIT: Off topic, I've been to a few sessions of my C# class now and it looks like the class won't even cover anything more complicated than single-file, single-function console programs. So, since I started messing around with KSP and your source, I'm already way ahead of most of the class as far as experience with the language. "See Mom? I told you computer games would benefit me someday!"

I was just coming back to report absolutely no issue with your compile. Rather irritating, though. Seems like I can no longer compile your code locally. Good thing I've pretty much finished with all the things I wanted to add to it.

Strange, cause I just tried again and I'm getting this on load: [ERR 09:26:41.564] AssemblyLoader: Exception loading 'KerbalFoundries': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'KerbalFoundries.Extensions' from assembly 'KerbalFoundries, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Only thing I can think of is that there's something whacky about the references I'm compiling against. I even tried reverting some of my changes last night and tried to load up the game again this morning with the same results. Well, good to know it's not my changes then. Those are completely uneducated changes, just suggestions by the software.

I was thinking of Better Buoyancy. I just didn't know it at the time. So, lo-fi, I don't know if this is due to some unforeseen issue woth .90 or if I'm just an unlucky guy today, but I just spent some time fiullding with KSP and, when I went to set up my action groups, I found that the only actions attached to your wheels and tracks were related to cross-feeding (which is probably from some other mod I have, but should definitely not screw up the standard actions available. I don't think my tidy had anything to do with it since I didn't even touch action groups, other than re-adding one action that you reverted over the holidays, which I have now re-checked for errors and found none. So, I dunno what's going on. It's getting a bit too late here for me to be launching KSP again for another check, so you might give it a quick try yourself if you have the time. I'd like to think it's all on my end, which I can deal with in my own time. Otherwise, we're going to have to revert my last few commits. EDIT: It's worse than I thought. Checking my log, there was an exception that caused the entire DLL to not be loaded. I sure hope I didn't do that... oops... EDIT2: I really should have just gone to bed, but this thing was bugging me. I may have narrowed it down, but I'm not going to go into detail right now. I'll check back here for any updates tomorrow morning, and if none are present I'll compile again and see if I fixed it.

In relation to the texture animator thingie, I was getting similar errors back in .25, but totally forgot to say anything. I need to be smacked for that. on the note of the buoyancy thing, I have yet to try it but I would think it might work better using the buoyancy plugin that was released a while back (buried by the forums by now) which had the goal of rewriting the water interaction in KSP, thus eliminating the insta-death, and improving the way parts interact with it. Doubtful that it would affect any of our water repulsion stuff, but it might improve the water-interaction of some of the parts that have the propeller module and these rovers that float....sorta... If I can get past my real dislike of the new controls in the SPH, I'll give it a go later. I just noticed that as you rotate the camera over the top of your craft, it acts like it's hitting a wall above you and shifts your camera in a weird way that is totally unintuitive. As well, the default placement for a brand new part on a brand new craft is at a different elvel than the default camera position, requiring one to shift their camera vertically to even see the first part. Very annoying.

The sky is blue because we brainwashed you to think it's blue. Blue does not exist, it is only an illusion of the mind. "We" are not there yet, but "you" might be. For what is "there" but another form of "here" that we are not "at" yet? Thus, everywhere that is "here" is "there" also. And all that is "there" can also be "here" given the right circumstances. From this point of view, you are "there" but from your point of view, "there" is "here" and the rest of us are "there," and "here" is where we are. It does seem to be those that are in the Development version. I think we're getting close to a release though, so no need to loose your sanity over it. By the way, lo-fi... I've re-done some optimizations to the code, but for the most part that does not make any changes to functionality in any way. In its current state, the project compiles with absolutely no warnings or errors. Very impressive. I'm holding off updating Github with any new optimizations or additions until I know you won't revert them when you update.

That's seriously close to that video shared a while back (some quad-zillion posts ago, roughly) about a guy who made a track-powered sled. Just replace the back surface track with a few of those skids and it'd be really freakishly close. Looks awesome though. You can really achieve that wheelie thing with these wheels/tracks what with their high starting torque and their suspension. That reminds me, I need to get back in and do some more testing with the torque values. I was messing around in .25 with the curves and had tweaked my configs with about an average of 6 extra definitions in those keys for various levels in order to try and smooth out that sudden acceleration that was causing my large-wheeled rovers to flip upside down with just a tap of the accelerator. I wonder how difficult it would be to write a wheel-tweakables-style set of tweakables for the wheels and tracks to do things like torque modification, perhaps with a few presets and whatnot (assuming we don't already have that and I'm not being stupid right now). I'm gonna have to do some fiddling around I guess. The trouble with tweakables is that I hate having to re-tweak for every wheel in the editor. Ugh, my brain is getting cluttered now. Must... stop... thinking.... gah! Oh, hey, while you're at it with the surface track, how about a surface wheel too? just the same model, except a wheel where the track is. Heck, you could probably use the track, but just give it only one "wheel" inside of it. Either way, that might be the one thing that could make that motorcycle thing even better.

I haven't tested yet, but the excited remarks so far have me convinced. You've succeeded where I failed at fixing the plugin. Of course, I failed because I didn't actually fix anything... maybe i should actually try to fix it next time.

I wonder if some sort of scale-fix could be implemented. When trying to implement TweakScale into the KerbalFoundries wheels, lo-fi had to implement a "tweakScaleCorrector" variable that could be set from the TweakScale exponential variable scaling system. In this way, both the visual appearance of the wheel and the settings in the plugin for the raycast collider height could be set dynamically in the editor. If the nodes are being modifies by the scale change in the game, then you'd think there'd be a way to detect this change and apply a fix when writing the config. For the time being, if it's really the scale change that's affecting it, then we should be able to reverse the scale multiplier on the modified node locations to get the proper position to be applied in the config. Anyway, I don't have the coding experience to even try to make this happen... yet...

When I saw the sketches for conveyor systems I was thinking we could possibly use the rock spawner from the bulldozer to create real rolling and tumbling rocks to those conveyors for the duration that it would take for something to travel along the path, then despawn it at the end point. It'd be like an animation, but with that little bit of randomness that comes with physics interaction. As long as it cleans itself up on a regular basis, and limits the number of rocks spawned in a particular area, then slowdowns should be avoidable. In theory, anyway.

Sounds awesome to me. What's better than recolored parts? Why, recolored parts that glow!

And there's the fact that kerbals do not limit themselves to traditional building material. We've seen wooden rockets before, so why not brick ones?

Actually, the name of the file itself is not a factor. What is a factor is the data inside it. As long as the file contains a node structured like this: (Sample) CelestialBodyColor { name = Sun color = 255,225,180 intensity = 6 atmosphereAmbient = 0 groundAmbientOverride = 1 }...then all should go as planned. UPDATE: As it turns out, this is not accurate. My latest post below is the correct format.

I attempted to do just that when .90 was still steaming from the press. There seems to be a specific function it makes use of that has been changed in the reference dll which requires more input than it did previously. This input is described, but my limited experience with C# has me scratching my head and getting nowhere. It's really annoying since there are a few part packs out there that seem to revolve around this mod quite heavily.

Wow... cool stuff. I have no clue... and I mean absolutely no freaking clue what you're all talking about, but it looks awesome.

I'm too much of a perfectionist to destroy the building. I'd rather find a way to obliterate it completely than destroy it, but then I'd find a use for it and want it back. As for controls, I've been using Editor Extensions for a long (freakishly long) time and therefore had no clue there were different controls between them, other than the orientation issue that was annoying and of course the symmetry limit. Editor Extensions has been updated for .90, though I'm unsure if everything is updated to function the same. I'm still wrestling with errors from mods that have yet to be updated fully. I've actually been battling that whole "burnt out" feeling with KSP lately. Been doing a lot of comparatively mindless gaming while starting a new quarter in college. Trying to get back my old interest in this stuff though. I'm getting close, too. I just noticed in my previous post that the "this way up" items almost perfectly align vertically, text-scale and screen resolution dependent of course. 1366x768, standard Firefox text scale. I'm so easily amused sometimes.

Who'd have thought a circular frictional propulsion device would need a "this way up" indicator. What is this world coming to? That said... I've done the same thing many times. Maybe we do need a "this way up" indicator.