Gaalidas

By "right" I take it you mean "install it and you can sue it right off the bat without any confusion whatsoever about the broken state of some parts of the mod which cannot be reproduced effectively on all systems" I'd say... not really. "Right" just isn't the... uhh... right word for the job.

Obviously he's quite mad. I believe the scribblings to be a form of writing that, unfortunately, has absolutely no patterns in it whatsoever. It is extremely difficult to decipher, however I believe it is related to his culture's myth about the beginning of the world and how the great wheel deity created the world in his own literal image and then had a great cosmic seizure and out came our planet. How this represents the topic we are discussing here, I have no clue. The downside of madness, I suppose.

I completely understand that you don't like mod-specific overrides, but that is the only way I can see to allow for the end user to ensure compatibility with their other texture-based mods without forcing them to wait for each update of your mod to address the issue. Endgame plan is, of course, to make it work with the other mods, but unless you plan to update this mod every time a new innovation in modding is performed, or updated, or broken by KSP updates, for the rest of eternity... well, you get the picture. Providing an option to override the default activity of the mod for that "just in case" situation is a good way to ensure that your mod will continue to work even if you meet an untimely end on your way to the bathroom tomorrow morning when an alien invasion causes a satellite to de-orbit and pulverize you to death with a space-toilet. Too much? yeah, maybe... my brain is weird that way. EDIT: What happened? We were getting along so well and now it's dead silent in here...

that's nothing, I have over 2300 of them, and it takes about... hmm... I never actually timed it but it doesn't take all that long really.

Wouldn't want a purple, obviously dead and slightly odorous specimen of bio-matter contaminating the place after all. Just breathe, it's better that way. Trust me.

Alright, theory was completely and utterly false. I had the plugin installed incorrectly. Got that sorted out once I saw the error that said something along the lines of "could not locate dll-name.dlz in the expected path." Long story short... well actually short story made shorter, I moved it and it's working. New problem, and a possible solution. So, as it begins to build its cache, it reaches that EVE texture that I have called "duna1" and then stalls. I actually get absolutely no errors to speak of, even in the logs (either of them) nor in the debug console, which I kept open during the entire cache generation process. so, I got to thinking about how Texture Replacer does its thing, and how in configs for that mod you can specify which pathways should be ignored when unloading the textures from ram. Could a similar override list be created for this mod as well, which would simply tell the mod to completely ignore certain textures either by name, or by a folder-path? That way no entry into the cache would be entered and no modification to the texture loading process would be attempted for the specified textures. This might allow for Texture Replacer to function as well as EVE, though there could be some extra complications when Texture Replacer users make use of the gamedata override feature, but honestly I find that just clutters things up anyway, so you could just warn users of this mod to not use that specific feature, much like the warning for users of that load-on-demand mod. I will say this though, upon reloading my game the partially built cache already shaved off a bit of time from my loading process. Granted, it's only managing ~500 textures out of over ~3000 of them total, but it's a success either way. If I could just get it to move past these certain textures that it has issues with then we'd be in business.

I think I know what's happening here. Texture Replacer has a feature that unloads textures from RAM (or something like that, it all makes really no sense to me) and things like this which render menus and such are affected by this feature. As a result, custom menus will sometimes collapse into non-existence. However, I am unsure if this is the culprit considering the window is showing up, it's just so freakishly tiny that nothing is appearing inside it. It's literally just a tiny little box, about as large as the screen-space needed to render a capital letter such as "H" in it. I plan to dive into my ksp.log to see if anything helpful shows up (or anything I don't already understand.) I'll keep you updated.

Okay, that picture of the wheel-derp is down right hilarious. That may have just made my day.

Interesting mod here... however I have run into some confusion. I installed the mod, ran the program, and faced my usual super-long loading time, which I expected on the first run with this mod. However, I am finding no way to set anything up, or rebuild a cache. I can find no GUI, or an extra button in the toolbars, or anything that would give me any kind of hint. I admit that it is easy for me to miss something obvious in a readme file, which I tend to habitually ignore (the down-side of becoming a true geek) so... anyway... confused!

Hilarious. Yes, I am oversensitive to my buttons. I get rather annoyed when I watch a video where someone is building a rocket with a badly-positioned toolbar on the screen with the obvious "it's time to update your plugin" icon in it. It annoys me to no end and I get stressed over it every time it happens. Also, a 10000x8000 monitor? That is a screen-resolution format, and would actually make things worse. You could, technically, force a monitor the size of your frontal lobe (I'm talking about your brain here, and no I am not making a joke about your brain size... I'm sure it's very proportional) to display at that resolution, which would force everything to appear so tiny that the individual pixels would not be able to keep up. Basically, each pixel on the screen would be attempting to show a view-space that you could normally stick your entire rocket into. That would be.... really annoying to say the least. Anyway... all I'm saying is that the button annoys me and although no one in this thread has the power to change that right now, it's still annoying and I decided to voice that annoyance out of a sheer need to voice something. No brain required for that one.

Only one annoyance I have with all this: that horridly over-sized button in the VAB/SPH for choosing a launch site. I'd be nice if we could banish that to a toolbar position instead.

argh!! Stop it...

for the love of the first kerbal, don't do that! I was just starting to get excited.

I noticed nothing in the way of performance cost.

In the end we'd surely like to see everything we can possibly imagine. For now, lets just try to focus on getting these parts out and functioning as intended. I envision these parts eventually being broken up further than they are now to allow for a epic level of freedom in construction without compromising structural stability, which would possibly allow for the things you (neko77025) are envisioning. I myself am seeing eventually a replacement for the less-than-amazing colonization set already available (HOME I think is the one). History shows, however, that we will unlikely still be working on projects like these when the technology catches up with our visions.

I gotta say, that curved model is really pretty and I'm rather excited to see this in action. I've always wanted to build a craft using trusses as the main structural element, but I always ran into issues with lengths and such that simply refused to match up right.

So, I must say those wheels are really "purdy" and I really want them. The hover "wheels" are interesting. I worry about keeping the craft oriented properly for long-distance, but I sorta have an idea of what you did there. I looks like something similar to the omni-wheel, but without the visual element and with your new suspensions. Even as it is now, you've definitely filled the bill for something I've been trying to do for quite some times using other hover-related mods... and failed miserably.

Sounds a bit like the toolbar addon which works almost perfectly as it is. An integrated toolbar would, perhaps, not be as susceptible to slow responses during re-positioning and setup perhaps. Still, it seems to me that if we have something that works already, why must we now re-do all the current toolbar-using mods to support a completely different system? Just seems a bit annoying.

As much as I want this system now I would also rather have it more or less complete so that I don't have to rebuild the entire colony when it gets updated. Besides, you're making some amazing progress here and I doubt we'll have long to wait overall.

I think something that needs to be considered here is that KSP is a work in progress as it is, and modifications which use plugins, or push the limits with texture resolution and model complexity, will tend to have issues on the users' systems in quite a random way. Everyone has a differently configured system which makes hunting these bugs down a real pain in the -colorful-metaphor-referencing-a-mule- With this in mind, many of these mods may not actually function well together or separate on a standard KSP install. It may be that the 64-bit "hack" isn't causing any of these problems itself, but with the extra complexities that come with large addresses in RAM we will see existing problems increasing exponentially. For instance, with EVE (or whatever it was called before it became EVE) I could have issues where it would load, but show only white semi-transparent (if I was lucky, sometimes it was opaque) layers where the clouds would normally be. Sometimes I would even get a lack of any errors accompanied with a complete lack of cloud layers and nothing displayed in the debug editor. And that's all without 64-bit access.

Seeing that last video, I'm not sure the ramp even needs to be textured any further.

I'm unsure if I could call it a "wonder of Kerbal engineering" given that Kerbal engineering can be a bit wonky at times. This is more the work of a Kerbal prodigy of some sort... you know, the kind that usually get shot out into space in something really far fetched and die a horrible and spectacular death before leaving the launchpad. If this were truly Kerbal it would have to (as stated in the rule sheet which I conveniently dropped in the rocket testing bucket, and has by now certainly been incinerated along with other incriminating evidence that, as I assure you all, does not exist) have some sort of explosive device used to push the ramp out from its storage space in the main module. This explosion would have at least a 48.67% chance of destroying the main housing unit of the ramp itself and a 22.3% chance of killing everyone on board. Very good odds, I assure you. However, this is one instance that I am glad the rules (which do not exist... at least not after Jeb excitedly pushed the ignition switch of our last batch of test rockets before we had a chance to lock down the testing arena) are being ignored. It's looking fantastic.

well, unfortunately my ability beyond the simple (that is, extremely complex) concept is pretty much null. I wonder if something similar to that mod that allows on-demand texture loading could help in this case?

seems the drop-box doesn't know where you dropped your box, so to speak. link doesn't work quite right.

They just didn't seem to fit exactly on the dot with those sizes. The surface was just a tad smaller on the large ring-station. The smaller dome thing, I didn't really look at that one to be honest.