Gaalidas

Oi, a freak out after less than 24 hours. Haven't witnessed that before. Looks interesting, either way.

When your level of insanity reaches that critical point where you feel you are not suffering enough and need about 50 billion more people asking you to change your mod to fit their vision of it. Honestly, I don't know.

So, I have yet to test this new update, but it looks like you've basically reproduced, in a much more efficient and customizable way, both the effect of a texture switcher and the painting system that was previously filled by KerbPaint. What I think needs to be done now is to take just those parts of this mod and apply them to regular parts as well. the one thing we could never get with Procedural Wings and KerbPaint together was the ability to change the texture on the wing and produce the correct paint-regions when paining it. This seems to be the answer.

The down side is that some mods are not being installed correctly and it is limiting what the mod developer can and cannot do because of that issue. For the user who wishes to simply click a button and forget about it, I'm sure it's a wonderful little utility. If, however, you want to make sure everything is installed correctly, without worrying about what a utility is doing that might screw it up, then you would want to steer clear of it. I agree, however, that standardizing many of the ways that mods are packaged and distributed would be a plus, I am just not convinced that CKAN is the answer to it. I used a mod manager 6 months ago for all of my KSP mod installations until it started uninstalling mods that share the same root folder because it thought that root folder was a conflict between the two mods. It really screwed me over with that one. Then, I had trouble with it trying to automatically install all the textures all over again just because I was using a different texture format for memory optimization. This also caused its auto-version-check to flag the mod as out-of-date because there were differences between the install and the package cache that it had created. In the end, it became a lot simpler to do most of it by hand, with a little help from some very useful batch files that I wrote to handle repetitive tasks. It's still a pain in my rear to track down all the updates and such, but at least I know all my mods are being installed correctly, and updated correctly (using WinMerge to be sure). if I'm stupid for wanting things to be done right from the start, without having to second guess what a utility is doing, then so be it.

Or you could probably add a dummy transform conveniently named "thrustTransform" for that. Hmm, this could be the ticket to adding a sort of "glow" emission like the ion engines have (or like the Near Future electric engines) and then a sort of "overload" effect to the repulsor, perhaps to be displayed when the repulsor is at maximum output. Hey, I just had a thought. How about a red "overheating" style glow for the repulsor plate when running at maximum and still having issues, reduced by adding more repulsors to the craft to support the weight? They could have an actual heat production like you'd get on engines, and could tie into the system other mods use for bleeding off excess heat. That could make the repulsor system a little less "cheaty" for the hardcore player. Something to think about for the next beta after we release this one. I would strongly suggest, sebi.zrr, that you wait a bit before doing any more serious work on that effect. We're getting ready to unload a massive update to this stuff. On the up-side, the repulsors haven't changed all that much so maybe you've got little to worry about. Just backup your work, cause there have been some name changes.

Bah, you people are betting everything on CKAN. Eventually something bad will happen and you'll wish you held on to the skills required to successfully mod by hand. Mark my words! Then again, I've been horribly wrong before.... Moving on... I thought to myself today "Hey, wait a minute... that custom fixed value thing could be used to make the TAC self destruct system even more awesome! Not only will the parts explode according to their individual explosiveness, augmented by their fuel explosiveness with BAM, but the self destruct device itself could be given an augmentation! So yeah, just did that. Now you just wait... it'll be another year or so before I remember to actually test that out. I'm so pathetic sometimes.

It's crazy how my mind works sometimes. If only I could summon that kind of essay-writing power for those times when an essay is required.

Normally, yes. However, the space around Kerbol is a chaotic place, full of collisions and explosions and the dust of countless kerbal lives and their nearly disintegrated spacecrafts. This has resulted in a very fine nebula-like formation to cover the entire system. Under certain light spectrum, such as the one so precisely turned in to by the creators of the light fixture in question, this dust can be seen by by the naked eye and create the phenomenon known as the "light cone." Otherwise, this cloud is virtually undetectable and does little to interfere with further operations in Kerbol space. To the distant viewer, however, Kerbol would be a massive shimmering, glowing, and irregularly shaped cloud of tiny particles thick enough to block out any other visual representation the Kerbol system would normally give off. At least, that's one theory.

Isn't electric charge technically a resource as far as KSP is concerned? I've run a few craft with EC as the only resource being used, but it tends to eat up a TON of EC no matter how you configure it. I only tried to take one of those engines (made to simulate a Star Trek style impulse engine running off a warp-core reactor as the only fuel source) and make it use only half of the EC and the result was an engine that provided miniscule thrust and required, literally, an infinite amount of EC to function. Since infinity does not actually exist, I had to scrap the idea. However, if you instead consumed EC into a generator that generated a miniscule amount of another resource with an extreme efficiency rating at the same rate the engine wanted to use it, you could simulate an engine using EC as its only resource without requiring the supposed infinite EC to run. As for the repulsors being used as engines, i don't think that would work because they are actually reacting to the surface under them, along with all that gravity mumbo-jumbo (There is no gravity, according to one theory. The earth just sucks.) To repulse horizontally, you would need a wall behind you to push against. However, if one were to attach repulsors as an angle behind the craft, and pulsed the repulsion field between high and low settings rapidly, you might produce a sort of "wave" effect that could move a craft forward. If you also made inverse-repulsors that could pull you back towards the ground just enough to keep the craft at its current height but low enough to not counteract the repulsors from levitating the craft, then you could permanently set the angled repulsors to a higher setting and the constant fighting to repulse the craft to a higher level than the rest of the repulsors are set to would cause the craft to continually move horizontally to relieve the pressure. This could, theoretically, be used to keep a craft from sliding sideways while moving, and possibly even be used to slow/stop a craft. This could also have the effect of creating the ability to steer a repulsor-supported craft without slippage. The theory behind this is actually possibly today with normal wheels and hydraulics, as far as the propulsion is concerned. If you have a vehicle which is restricted from moving vertically, and has an angled set of wheels in the back that are made to push downward, the vehicle will attempt to roll one way or the other to relieve the pressure (yes, I know it's more complicated than that, but this is very basic). If that restriction in vertical movement is at the back of the vehicle, and there is less restriction near the front, then the craft will attempt to roll that direction. Not very useful out in the world, but if we had repulsors in the real world, one could possibly generate a form of thrust simply by repulsing at an angle on the back, and pushing downward just behind the center of that repulsion reaction, thus creating something similar to when you squish the sides of a straw with water in it. The liquid moves to escape the collapsing space in the directly with the least resistance. So, as far as I can make out, if the repulsor was not set up to only lift the craft vertically, but instead attempted to push the craft in the opposite direction of the repulsor plate (pointed down, craft moves up) then you might be able to create all of this without making individual parts for each purpose. I figure with regular wheels and a small engine on the back pointed upwards, you could get the same effect by raising the back suspension and throttling up. Of course, that would be very inefficient for a friction-based system like the wheel, and with repulsors you might be better off with some small engines on the back and some RCS stabilization systems pointing every other direction. Even if you didn't use repulsors for propulsion, it would be awesome to be able to use them for stability by angling them outward from the center of the craft, similar to how a roman archway supported the center stone the craft would settle into this "pocket" between the inward-pushing repulsors. You'd simply have to input more energy into the repulsors to maintain the same height as you would with vertically aligned repulsors. Either way, inverted repulsors is something I've been toying with the idea of for a while now... ever since I discovered the squid-system mod a long time ago, before I even heard of this mod (in fact, before it existed.) EDIT: Squid was/is an Impossible Innovations mod (I think) which provided alternate versions of stock wheels which, when the squid was activated, would attach to the surface it was on and keep all wheels firmly attached while driving. I hated the visual effect associated with the activated squid system, but it certainly worked. It was built with landing on low/no gravity bodies and staying landed. This was before we had claws or even asteroids, but I believe the system would have worked on them too. END EDIT EDIT: Huh. I think you hit a nerve or something. I wrote all that in about 60 seconds of frantic typing. Only took me 2 minutes to fix the glaring typos. I'm sure I missed a bunch of them.

Original planet textures are in the asset files. You'll need a unity asset extractor/editor program. There are a few you could probably find with a generic internet search (google or similar). Some more user friendly than others. - - - Updated - - - Maybe not, but instead of the old environment map reflections that I used to get, now I get this really fuzzy image of a white square. So, if they're not intended to be "real" reflections on the main menu, then perhaps the main menu scene needs the settings to be overridden to use the old reflection method if any form of reflection is enabled in the configurations for the mod. It definitely didn't revert back to the stock appearance of the helms, in which there would be no reflection at all.

I was just looking at those! Heck, the first example album makes use of the adapted RBI invertible tracks.

As far as I am aware, nothing is broken at the moment. Just be sure the release includes the scaletype definition file from the main directory and it'll all work fine from that end. Oh, hey, one little thought... whatever happened to that new APU model you told us about a while back? The current one still has untextured parts and such. Also, I may have spoken too soon about CollisionFX. I checked earlier today and it looks like it may have been updated a few days ago.

Indeed, I even tried to help the developer of CollisionFX to properly handle KF modules when patching parts for use with his mod. Unfortunately, I tried to update it for the recent updates to the module names and was certain we were within a week of releasing an update. Warp ahead a month to today and we still have not released that update. oh well. Either way, he still didn't quite get the module name search quite right. I've since updated my local version to handle all the updated module names, but haven't seen any updates from that developer lately. Still, the mod itself might be a good example of how to handle this sort of thing. Heck, if you change the circumstances in which the effects spawn and remove the need for a hard collision (just the basic collision caused by rolling over a surface) then you might have the answer.

I was just thinking the other day that I wanted to find this thread again and see how it was coming along.

15 seconds saved from simply turning off Vsync during load? That's just nuts. Wonder what you could save if you totally replaced the loading screen with a dos-style window and turned off all other special effects entirely. Not that we're going to do that, just speculation. Reminds me of the predictions people used to have when talking about solid state drives. "It'll be like... click the button on the box and before the click is done, you're booted up!" Then we found out we were being stupid and nothing loads that fast.

Bah, paid version my a... err... donkey! Just means you'd have to do some crazy workarounds. But still, would be rather more difficult than it's worth. No, we need something simpler than that. Detecting the body on which the craft is landed and shifting the color scheme of the dust effect, or switching to a really light color scheme when over water, would probably not be too difficult. Not that I know anything about the difficulty level of any of this. I just know what's been done before, and if other plugins can detect when the craft is landed, and what SOI that landed craft is within, and your plugin can detect when the craft is over water in order to use the water repulsor stuff, and other mods yet can automatically switch modes for engines or wheels or whatever depending on these situations, then surely altering a texture color scheme or changing the texture entirely to fit a situation is totally plausible. That was such a long sentence, I am not even sure it made any sense. Point is, if all that stuff can be done separately by other mod developers, then combining those abilities to make something like environment-sensitive dust emission should be doable, eventually. Lighting effects would be cool too... I guess...

You know, you could save the MM system from having to add the module to the part by just entering the module into the part configuration file itself. MM can either add a module to a config based on certain criteria, or it can remove a module from a part if the mod it needs does not exist, from the "part.cfg" itself. Observe: PART { name = whateveryourpartname blah blah blah... and all that important data for the part... MODULE[B]:NEEDS[modularFuelTanks][/B] { name = ModuleFuelTank volume = 2160 type = default } } The part in bold will cause MM to check if the plugin exists and, if not found, delete it from the part. So, while it's really the same amount of processing power being used to add or remove the module, there are a few steps that can be skipped by the loader. First, it can skip having to load the MM config file that the patch would be inside. Second, it can skip having to process the MM patch to figure out what it needs to find. Third, it can skip having to scan all the other loaded data for the part name. Finally, because it is going to look through all the loaded configuration files either way, it can simply detect whether or not the plugin exists when it reaches that check, which I printed in bold above, and then simply remove it if it doesn't like what it sees. Granted, it won't speed anything up much in the long run, if everyone embedded their modules directly in the configs and used these "needs" checks right there, instead of using separate MM patch nodes, the length of the KSP loading process would be significantly improved for people who can report over 10,000 patches per launch. Just a little tidbit of info I thought I'd share. Might reduce the amount of work for the modder to just do it that way as well.

Unfortunately even the most amazing things we can do here have their limits. Sure, it might be possible, even down-right easy, sometime in the future, but for now it's just not feasible. Looking at that picture, however, reminds me of those wheels from the ASET ERS package that we were talking about trying to make compatible a while back, but never came back to it. Maybe we should look at those again. Also, I'd like to add to that next-next version to-do list in the area of the dust emitters. The wheel dust is a great idea, but what would be a better priority for the dust emitter is attaching it to the repulsors. One thing that might be a challenge, however, is how to display the dust so that it fits in with the environment. For instance, the "dust" would have to be turned into small liquid particles when over water/liquid and you'd either have to make the effect extremely subtle (95% transparent, more like an air-refraction than actual dust) so that it could look right on planets like Duna and Kerbin without a texture swap, or implement a planetary detection module that could apply a color modifier to the particles. Another thing to put on the extended list would be more appropriate sounds for the tracks (something that resembles track-segments rattling around on the ground as well as the internal engine rumbling along) and the repulsors (I have a few sound clips of hovering thrusters that might work) and a more appropriate electric wheel sound for the really tiny unmanned-rover wheels to match with the generic electric/fueled sounds for the larger wheels that we have right now. So, yeah... the secondary beta addition will be filled with some really sweet stuff... EDIT: Yeah, that's what I'd like to see implemented for the majority of the parts we've got here, within reason (not gonna be folding those massive things inside anything anytime soon.) but I'm not sure the spinning-upside-down is as great of an idea as it looks. I'd think a simple rotation inward would work. The tricky part is whether or not we want to provide the compartment they retract into ourselves, or simply provide the animation and let the user figure out where they will retract into themselves (inverted cargo bays and whatnot.) Repulsor retractions would also be awesome. For the surface ones, you could simply make them recede into the surface of whatever they are attached to and have an iris-like door close in over it. For the side-attached ones, even just an animation where the arms fold up and back, and the repulsor sits in a sideways position closer to the side of the craft would be great, but a more complicated one where the arms are segmented and retract upon themselves, bringing the repulsor disk straight inward toward the connection plate and closing an iris-like covering over the repulsor field plate would be sweet stuff. More to add to the next-next-next beta release to-do list. Are we insane or what? EDIT2: Also, a note on the "small repulsor wheels." Those are sorta unnecessary until we get our vintage car-part package, if anyone ever completes one. I know there's at least one guy making a muscle-car package, which is pretty close. Dang, I just realized I'm talking about "vintage cars" when, in fact, I wasn't even born yet when the first of the modern sports cars were born into the world. I'm old, but not that old. EDIT3: I sure edit my posts a lot, don't I?

I was noticing today that, with real reflections turned on and sitting at the main menu scene, the reflection that is produced on the floating/mun-landed kerbals is that of a white box. I wonder if perhaps there needs to be a scene-specific setting for turning off those real reflections in that specific scene?

We do definitely need some vintage stylish car parts for our kerbals to ride around in. Even better if those little wheels can turn on their sides and become miniature repulsors. It'd be like that flying car in that TV show "Agents of Shield" that we only really see doing anything in one or two episodes.

Didn't those really huge wheels have the retract action available to them? I remember I could reduce the suspension to zero and then retract them and basically have an immobile rover. That was a long time ago, though.

I can't! It's a sickness. It's all your fault... you started it! You just had to go and reinvent the wheel didn't you? And they just had to be superior to every other wheel out there, didn't they? Gah! By the way, already added TS support to those new tracks and the dev part MainGear with its own scaletype, even though I have no clue what it even looks like. EDIT: Oh, just had another one... what about a track-like structure comprised of wheels all attached to each other... sort of like a prefab four-wheel rack, complete with steering optimization built in. It'd be basically a track, without the track, and rubber on the wheel bits, along with a combo of track-steering and multi-wheel steering. When stationary, it'd use track-style steering. When moving, it'd use the other form of steering. GAH, there I go again! See what you've done? I'm ruined!

Yeah, I figured that method could be eventually made into a toggle so that you could use the same part for a single-function or a multifunction mode. Honestly, I'd like to see an option for the medium wheel to remain animate-able (the turning over on it's side) like the repulsor wheel does, but without the repulsor, so that they can be made into a landing leg of some sort. Another idea would be to have a second object, like the repulsor object but without the repulsor surface, that would instead resemble a platform that a craft could sit on when not wanting to be mobile. Even better would be if the object the repulsor was attached to could be switched between repulsor and landing leg mode in-flight (switch it to the other mode and the little circular panel just flips over) and you'd have the ultimate one-part solution... until we think of something else to make it more ultimate. Anyway, all this stuff will not be eneded for this release, like you said. This is not the time to be coming out with insane new ideas for features we want to see. Lets get this stuff out to the public and let them do the hard work of testing them first.

Texture sharing should be rather easy once any remaining texture names with spaces are eliminated. KSP really doesn't handle spaces very well when referencing models and textures using "MODEL{}" nodes. The actual texture names don't necessarily have to be different though, just the content. The way I generally set it up, when modifying other people's work to same my ram, is to move all the textures that share the same content into a new folder that I commonly call "CommonTex" within the root directory on the mod (or in the mod's "parts" folder if it uses one). I then go into all the parts which are going to have the shared textures and replace those shared-content textures with a 2x2 blank texture. Why not 1x1? Good question, but considering all the fuss with "divisible-by-2" rules, it seems a good precaution. Then I just have to set up the "MODEL{}" node to reference the model from the root "GameData" folder and do the same for the textures which need to be replaced. Interesting thing to note here is that textures which are still going to be loaded from the same folder as the model itself do not need to be defined in the node, only the ones that are going to be replaced. Also, the texture to be replaced can have a different name than the one you are replacing it with. I'm prepared to do some work on the configurations once you've got all the files named and assembled. Alternatively, you can rename all of your "part.cfg" files into files named for the part they are configuring. You then eliminate all the folders and just throw everything into a single folder. this works best if your textures not only share content, but also the same file names. You still use "MODEL{}" nodes to be sure that everything is referenced properly, but the textures can remain un-replaced in the configs because the models are all referencing the same files as local files. You also eliminate the need for dummy textures in the individual part folders. This would have been a good idea to set up from the start, but the way you have it set up now suggests that this method would be more trouble than it is worth. For a good example of this particular setup is the KSO mod. Everything is piled into a single folder for the parts. Another really good example is how USI sets up many of their assets in separate folders where all the textures and models are, and the configs in another directory entirely. Another texture I'm wondering about is the one on the medium wheel which looks like a repulsor texture. I know that the model originally came from the repulsor wheel, and I see that the model references this texture, but I also know the wheel doesn't actually use it. Well... that post was longer than I intended.

Dang... Yeah, there was always a file missing that it complained about in the beginning when loading the project for the first time. I thought I'd taken care of that. oh, well. I'll look through it again. As for the braces, they really aren't all that necessary... except for the fact that, to make it work without braces, you need everything to be aligned just right so that the compiler knows what the heck you want. It also requires that the result is only a single line of code, otherwise hold on to those braces. Anyway, I was just trying out suggestions made by the software. I'm sure not all of them are supported fully by other software packages. One feature it keeps trying to get me to do is changing things like "if (var1 != 0)" into a check against something it calls "epsilon" which, when compiling, complains that it has no freakin clue what epsilon is and fails the build. Really annoying that it keeps asking me to do that when it doesn't work. Still, I would have thought that if the line which pulls from assemblyinfo.cs wasn't functioning that it would have thrown an error. Besides, I've been recompiling your code with my own little additions for quite some time now and this is a brand new issue. EDIT: Oh yeah, new tracks. awesome stuff... just needs a frame and such. I look forward to struggling... err... okay that's actually the right term... struggling with the stack node placement and tweakscale integration. EDIT2: Yeah, found 5 references to that version printing thingie. I'll give it a try later when i have more time to test it. You must have added that pretty recently then, I suppose. Oddly enough, I don't even remember seeing that line when I was browsing the code. EDIT3: Okay, I noticed something that needs to be addressed in the way of textures for two of the parts. As it stands, there are three texture files that are being distributed which are not referenced by the part configuration or the model. In "TrackRBIInverting" the file named "model003_NRM" is not used. In "TrackRBITiny" the files named "model001" and "model003_NRM" are not used. These offending textures should probably be removed before the package is put together for a release.