Gaalidas

And I thought I had a high opinion of myself. You're going to need some struts on that head if you intend on going to space today. - - - Updated - - - Just had a look at that thread and I'm looking forward to playing with those. Just need to get back to my PC. I'm on a phone now.

Bah. Pizza whateverhisnameis came up with the concept, and the original code, but I made it fabulous. Anyway, I'm still investigating TS. I'll get it sorted eventually. The ERS wheels could be due to some screwup in my MM config. Still worth a look. - - - Updated - - - So, what is electronicfox about to release, lo-fi?

I believe if you bury a TWEAKSCALEEXPONENTS node in the module definition, or at the very least bury one inside a SCALETYPE node, which modifies the same thing as the default exponents, it will override the default with no issues. I use that in some of my scaletypes. I recently remade all my scaletypes and extracted all my exponents into root exponent nodes, which reduces the redundancy in the scaletype configs. However, for one of my scaletypes, I need a specific value to be defined differently and so overrode that within the scaletype by sticking the same named exponent node inside that scaletype. So, to simplify things, you can stick a TWEAKSCALEEXPONENTS node either as a root node, or embedded inside a SCALETYPE or embedded inside of the TweakScale MODULE node in the part config. I think the part config overrides the scaletype, and the scaletype overrides the root node definition. Anyone want to correct me anywhere?

This has got to be the most awesome thing I've seen here since Kerbal Foundries. Almost as awesome as when I discovered you could turn a live Kerbal into Kethane by going to the suicide booth.

Yup, I even loaded up the game (it didn't crash this time, woohoo!) and the sliders exist. However, I tried to use the KF ERS wheels as a testbed, and discovered that problem where they animate, but don't actually become usable properly. Also, the treads are still all screwy. I discovered an even bigger problem though, and one I thought I'd fixed. The only KF parts that can be scaled at this time are the repulsors. All the wheels/tracks/whatever are showing an empty line in the context menu where the TS slider should be, and my log is getting spammed with: "ItemPrefab for control type 'UI_ChooseOption' not found." The control type in question is in KSPAPIExtensions.dll, and I already checked the referenced version in TS against the version of the extension DLL I have in there, and it all fits, plus the extension DLL does have that control type in it. So, I've already posted to the TS thread hoping to shed some light on this obvious screw up that I cannot seem to make sense of. So... I didn't get a chance to actually see if my sliders work or test anything out. In the end, trying to relaunch the flight scene with a different craft ended in a complete crash which I had to reboot my whole computer to recover from. Dang TweakScale.

I wonder if anyone else is experiencing this... I've got a set of wheels (the KF wheels, in which I implemented the original TweakScale options for, which worked fine with the same scale type setup a while back) and at least from the launch of 1.0.2 of kSP and onward I am getting not only no option to scale them, but the place where the scale would be is replaced by a blank entry. What I mean is the context menu has a blank spot in it where I believe it is trying to render the scale slider and failing. In addition to this, the log is spammed with: "ItemPrefab for control type 'UI_ChooseOption' not found." Now I did some digging of my own and 'UI_ChooseOption' is a KSPAPIExtensions thing which, when browsing that DLL, in the version specified by the references for TweakScale's DLL, the item does in fact exist. What's even more irritating is that the same scale type options for another part type (the KF repulsors) works perfectly fine. I'm about ready to pull my hair out trying to fix this. Has some form of game-changing modification been done to how the scale type has to be defined in order for this mod to continue working as it has in the past?

I'll take that as a compliment. I agree too, lights are a good idea. i especially appreciate cockpit-lighting for night driving, especially in a dim red hue (to better fit with the eye's natural night-sight which does not get ruined by red light.) setting up MFDs shouldn't be that messed up. You just need to place the props in the right spots and make sure they're doing everything they should be doing. You could probably take a stock cockpit patch as a template and just modify the locations to fit the spots in the rollcage. Page setup is only necessary if you want your own custom information displayed (which might be cool... a single page to display the current status of the suspension on the wheels/tracks on the craft, or show the height and power drain of the repulsors... but that can wait for a later update.) I wouldn't try to do anything like what you get in... say... RetroFuture (wide screen maps with overlayed square screens side by side that can show info while allowing a scansat map to run in the background, complete with controls for all three screens arranged on the outside, and controls dedicated to camera movement next to that, along with complete action group toggles and switches for jsut about everything you can possibly do with a ship.) and I would never recomment trying to do what Alexustas has done (custom readouts for fuel/power levels and drain rates, transparent HUD displays for rover orientation, speed, direction of movement, controls for every action group, plus controls for everything you might ever think to do in stock or any combo of about 50 different mods, plus stopwatch-like devices, time keepers, lights, bells, whistles, you name it.) That stuff can lead you to go completely nuts. What was I talking about again? oh right... the rollcage. Yeah, I'd say either set up a single monitor (or several small monitors with just a few functional buttons each) or just give it the basic IVA controls. I'd also export a version of the part which can just have a control seat attached inside of it, without any form of IVA of it's own, for the non-JSI users out there who might still want that part. I wouldn't exactly change the geometry of the part like the others are suggesting. For that, I would make separate and completely new pods. This thing looks fine on it's own. As for the crazy angles, yeah those are annoying, but you sacrifice a lot of style to get things fitting together perfectly. You just have to decide what's more important in this case. There are already a good number of mods uot there with flat, boxy surfaces for your perfect attachments. I guess my point is this: put some stuff in there to at least help us navigate, then worry about making it really awesome later after we've had a chance to mess with it ourselves. No one says it has to be fully functional in its first release. - - - Updated - - - Okay, so I admit I have little understanding about what each of those parameters actually does. I wonder how hard it would be to set up a GUI slider (context menu), available in flight, where I could tweak some of those values in real time to get a sense for what does what? That would sure help me figure out how to better control the effect than simply relying on alpha transparency of the color. This would sure be great, because I kinda like the effect better when it's almost completely transparent so it appears more like dust than bits of ground being ripped up. I could then control the density separately. Might be a good time to resurrect the test module and do some code copying from some of your other modules with in-flight modifiable parameters. EDIT (final edition, I hope): To answer a long standing question, YES my posts are getting longer. In the next few months I'm going to have to start adding a table of contents and insert page numbers into my posts. You think I'm kidding? Just look at the progression during all 280+ pages of this thread. Be afraid.

Well, there is of course adding all that instrumentation using the complex JSI prop packs and such so we can basically control the universe from the seat of our mini-rover. But I'm sure we could scale that list of features down. I'd settle for at least a monitor with it's accompanying buttons on the inside surface in front of the kerbal for some basic information. Other than that, it's not really meant to be a complete pod solution for off-road kerbal transit devices, is it? So, it's pretty feature complete. In the future, maybe some different color options using a texture switcher would be great. Maybe one with really dark bars to contrast with the brighter surfaces. I like the idea of sampling like that. I still want some control over the density of the particles however, and currently I don't see anything to handle that. we have control over the strength and size of the effect, but it's still just an effect which limits us as far as density of the effect. Using an alpha channel to make it appear less dense by making it semi-transparent is my way of combating that problem, and I've been setting that based on what I think the surface would produce when scraping it with something. So, at the very least, we would likely need a list of biomes with their corresponding alpha values. However, sampling the color of the surface being collided with would fix another problem I had, where there's a small patch somewhere between the KSC and the distant hills which is incorrectly flagged as part of either a tundra or pole region. This resulted in snowy-colored dust from green grass. I found it only once, but it's rather annoying and I really have no way of fixing it unless I can get color values from the field. I know TextureReplacer merged in some of that reflection stuff, which I'll do some digging into later. I've already looked at that stuff anyway because there's a problem with how it handles the reflectivity of the region you want to reflect. Unless you specify a specific object in the part, it simply makes the whole part reflective and the higher the alpha channel, the less reflective it is. It uses the main diffuse of the part to do this, which makes texture replacement a real pain because you have to take into account the bleed-in from the model's default untextured color, which is a pure white. I wanted to see if there was a way to get it to reference a different texture, or alternatively treat the inverse of the current alpha handling instead. This would be a lot easier to deal with, since the reflective parts wouldn't need much done to them for texture since they're being overlayed with a reflection modified by a custom color shade (if specified). I didn't find any easy way to invert things or redirect them without having to recompile the shader. I don't speak shader-talk anyway. EDIT: Something else to think about with the color sampling. The pro of doing this would be that making water spray when repulsing over water would be a lot easier, but the con is that the sampled color would be the color of the water when, in reality, water spray looks more like snow-dust than the blue that you would get from the sample.

That looks like a very bad idea... -hits the launch button and walks away-

I want it. I can think of all sorts of fun I could have adapting that.

pizzaoverlord has never even responded to any of my messages or posts in his CollisionFX thread (which is buried under a boatload of threads by now). I seem to remember you telling me his license allowed for, at the very least, my DustFX plugin. The thing is, at this point there is not a lot left of his original code. Yes, it looks freakishly similar, but I've had to re-write a lot of it in the various iterations since the original. Unfortunately, the only way I found to make it work turned out to be more or less identical to the original. I suppose there's only one way to really get the right effect sometimes. So, the grounded hit thing was what I was just looking at 10 minutes ago. I started to try and grab this information for use in my test module, but started feeling that headache coming on and decided to take a break. I look forward to seeing how you did it though. As long as you don't break the color definitions and such, I'm happy. Speaking of which, most of the non-Kerbin definitions in the DustColorDefinitions config are based on the average color of the planet's appearance from orbit, grabbed from various sources including screenshots from the tracking center. If you end up taking any of your creations to other worlds, I'd welcome any adjustments to those color definitions in the config. The config, which originated from the first time xEvilReaperx helped with the project, (I think he generated it from the game's internal information, I'm not sure how really) contains all the planetary names and biomes in it already with these placeholders. The alpha channel for those colors is what I'm using to affect how thick the dust particles appear. I'm basing that on what the material appears to be (as in how tough it would likely be. The harder the surface, the more transparent the particle color, thus the lower alpha value.) Otherwise it's just an RGBA color. EDIT: Took a look at what you did and I'm impressed. Didn't take you long, and seems incredibly simple. I re-enabled the OnCollisionEnter section though, as it is used to enable a wheel-impact audio effect that the original mod had which I liked, but never really tested the implementation here. It needs to be enabled, have the user's volume jacked up, and get some wheels rammed into something. Because it is untested, I don't have a default sound effect even defined in the code, but if you look at the MM patch, I do define one (which I added to our sound folder, though I might have referenced the path wrong in the patch, I'll check after I get done writing this) for everything except the repulsors (and the patch which implements the dust on non-KF wheels too, since that also works... actually, I may have removed that now that KF specific values are being called for. I may add that as an extra park of the mod later.) I guess I can cancel my test module now then, since you've managed it in record time. Did you get a chance to test the result in-game?

Wait a sec... so those wheels have a retracted state? I thought they simply appeared retracted until you launched with them... Maybe I should actually launch the game and see what's been going on with the parts instead of simply updating the files and diving through code and ending up confused. So, I did actually take a look at what you have available in that module, and it's a bit overwhelming actually because I still really don't understand how the original scraping and particle spawning code actually works in the original CollisionFX mod. Because of that, I really don't know how I would use any of that information. The furthest I've come to actually using anything is simply by expanding the equations used already with more multipliers and whatnot. I'm still digging between my various headaches (this stuff really screws my brain up) so who knows what I'll come up with. That's why I really wanted to integrate this with your mod. The more heads working on this stuff, the better. I'm good enough to be dangerous., and by that i mean I could easily break everything at any moment, but I'm still not experienced enough to call myself a programmer. All that and I should be working on my ASP.NET final project instead of KSP mods.

Wow, that thread title is... like... the most vague question I've read in a long time. Awesome.

I thought you'd already made your own LookAt. Or were you just expanding on the stock LookAt? Oh, well. Vector maths are as familiar to me as deep-sea diving is to a desert-dwelling lizard. I know the name, but that's about it. Okay, so the analogy doesn't work too well, considering a desert-dwelling lizard doesn't know what deep-sea diving is... but you get the idea. I've actually had a moment of inspiration... or rather, I've started doing what you told me to do earlier when I was looking to grab the tweakScaleCorrector value from the other modules. I figure if you can search the parts for colliders and such, I can probably do that too. So, I began mucking about with some copies of your code in a TestDustFX module to see what I could do. I still don't know how I'm going to make DustFX use a list of colliders instead of just a single one as it's built to handle now, nor if/how I'll be able to average the effect between the multiple colliders if the part has more than the single one, assuming I can get it to differentiate between the colliders that are simply a part of the whole "part" and which of those are actively scraping the ground. At this time I think it's just emitting the particles at the wheel's collider when the part, as a whole, is scraping the surface. I can't claim to understand all of it's inner workings though. Good stuff on the model nodes and such. I just hope your parts won't require any wonky scaling done once made into MODEL nodes. I had a nasty experience when optimizing my local install of the Endurance mod, where all the parts in the Ranger craft ended up too small, but the attach nodes were all in the positions they would be in as if the part was full size. That really sucked. - - - Updated - - - By the way, what the heck is that "BV" track you mentioned? I'm not familiar with it, or at least not that reference.

Well, on the bright side, stock aerodynamics update was going to send everything to hell (or heaven, if you're a realist... in which case KSP is not the best fit for you) and it's turned out alright. Doesn't make me feel any better about it, but I don't have much of a clue what it means from the programmer perspective, so I'm keeping an open mind. Those ideas sound great. I have absolutely no clue how to do that though. Keep in mind, everything I've overhauled is still, at its core, straight from CollisionFX. Whenever I break something completely, that old mod is still my go-to to figure out what I've done and get it working again. The whole collider detection stuff is some of the most confusing parts of the whole thing too, so I'd welcome your own mucking about with the code. My baby is really just the addition of an external config file to define colors/biomes/planets and all that. Previously it was hard-coded, which is simply not acceptable, and even then the code is really from xEvilreaperx. All I did was pester him for help and combine it with the original PQS detection stuff. My only worry with emitting from multiple colliders in a sing part is that, when using many different wheel-type parts, you'll overload your performance with all the dust you'll be emitting. I would actually love it if you could somehow detect the collision that is furthest towards the rear of the part (pretty much dead center for a wheel, but would be pretty far back for a track) and emit from there. However, since tracks can throw up dust when turning in place, the effect would lose its cool factor in that instance. I'm actually not sure even the current system would detect movement during in-place turning with a track. So, it's all quite the work in progress. I'd also like to see the particle stream itself done differently so that, upon changing biomes or surfaces that produce different colored particles, we don't get the entire particle effect changing all at once but only the new particles being produced by the collision. This would probably mean we'd need to start using a real particle emitter, instead of a simple smoke effect. I'm unsure if we could get the same results from a particle system though.

Yet another masterpiece by the master of pieces himself. Yeah, that was bad. I'm up way past my usual bed time.

Those crazy relatives are always kicking buckets at the wrong times. It's all about communication... or the lack of it. if you intend to go to the farm, do us all a favor and present a timetable so we can plan accordingly. Eesh! Anyway, as lo-fi has said, loose ends need to be tied up. I have a feeling my recent additions aren't helping with that either, but those will be tied up soon too. It's gonna be awesome though. UPDATE: Alright, I did a merge to github. The bad news is that, in order to be sure that DustFX (more accurately called KFDustFX and KFRepulsorDustFX) and the old CollisionFX modules don't conflict, I had to implement the module using Module Manager. Considering nearly everyone who uses mods at all will already have it, I don't even consider this "bad news" necessarily. Eventually I would like to find a way to detect the presence of CollisionFX on the parts, those of which have the KFDustFX module as well, and disable the offending module when the part is initialized. This would eliminate the dependency on MM. Ideally, in the far future, being able to break free from the extra module and turn DustFX into a called method from the standard KF modules, which would allow me to eliminate the current collision detection techniques and simply re-use what the KF modules use themselves (water-spray when repulsing over the water, that would be awesome)... well, a guy can dream. So, in conclusion, everything should would as it is (totally untested, but it's not really any major change from the original DustFX implementation, so everything should work like before) but I'm nowhere near being done tweaking it. In other news, I've updated a number of mistyped module names in the wheel configs, and removed some previously-commented redundant/unnecessary modules. Also cleaned up the moved source files and restored the files in the DustFX sub-directory.

Hey, that's what I'm here for... amongst other things. I'll try to upload my latest changes soon. On the plus side, the only change I've made to any of the files is adding a part info override, which can be overridden in the config file if necessary, and that's pretty much it. Anyway, yeah... the DustFX stuff got moved from their own directory to the main directory. In the next upload I make some of the files have a name change applied too, so that should sort everything out. I'm just waiting for a chance to do a little testing before I commit the whole thing. I still want to make some additions to the whole system, and there are likely some tweaks and optimizations I can make to the whole thing now that I'm tying them directly to the KF wheels. Also, in the far future, I would like to see if there are other effect types that could replace what the dust is currently emitted from which might provide a more natural effect. We'll just have to see how that goes, and if any of this still works when the next major KSP update comes about. I still think there's got to be a way to trick KSP into thinking that the tracks are, when placed in a "packed" state, that they are, themselves, a super-heat-resistant part that completely overrides anything that KSP wants to do to it. Sorta like the physics-less parts in the old days. It's not an ideal fix, but it would do the trick. I'll have to do some digging in the heat-system modules using ILSpy one of these days, see if there are any override parameters that have gone undocumented.

Really? A veteran you say? I didn't think they still made those... Last one I found was locked away in a cabinet at the back of an antique store. You know the ones, which those signs that say "Completely Not-Stolen Legitimately Illegitimate Antiques, made just for you on a daily basis!" Awesome stuff with the ERS wheel though. I'll see if any updates need to be done to the MM patch version of it. Great news on the DustFX scene too. I have successfully split the module into two versions: Wheel/Track and Repulsor. The repulsors don't seem to make any use of tweakScaleCorrector, so I stripped out most of what I was doing with that and replaced it with a modification based on the ride height of the part. The one thing that worries me about that, however, is that I'm only grabbing the value when the part is initialized... but I've got a few ideas on how to update that. I may need to move the setter for that variable into the method that defines the dust color, which is updated quite often and should be active enough to catch changes in Ride height during the flight. Of course, all of this lacks any proper testing due to my OCD when it comes to building rovers. if I'm not completely happy with it, it doesn't get launched. The only other thing I would like to implement that was part of CollisionFX is something specific to the screw and skids. Those parts, when moving over especially-hard materials, have the potential to throw up sparks due to the fact that they're not exactly rolling over the terrain, but rather scraping along. I'm gonna have to do some digging to see if pizza-whatever-his-name-is ever got the sparks to only fire off when colliding with non-planetary-collider surfaces. I've also been experimenting (well, I experimented with the config, haven't actually tried it yet) of adding the FSbuoyancy module to the screw so that they actually float in addition to your propeller module. I hate to do anything that would add a dependency to that part though. EDIT: Oh, hey, a thought about the overheating problem. As a short term fix/hack you could simply double the maximum heat tolerance of the parts. In a more long term fix/hack... I wonder if an animation state could be added to the rest of the parts, taking the ERS wheels as an example, which would put the part in a "packed state" where the suspension would be put in a fully-contracted position and, as a nice side-effect, the part would then spoof the game into thinking they are fully shielded (something we'll have to do some coding work to achieve) as if they were under a fairing. This goes along with my long-standing idea that the repulsors (specifically the non-surface ones) need to have a fully-retracted state that causes the repulsion-pod (I'm making this up as I go along) pull up and rotate to face outwards to show that it is "turned off" which would also make it take up less horizontal space. I wish I could create an image of what I'm seeing in my head right now. It would sure make things easier. - - - Updated - - - This is a problem we are looking into, as shown by my above posting. The issue isn't related to other mods, but rather with the mesh and the way it is handled in KSP, which is kinda weird, which causes the part to not get shielded properly because it thinks the part is sticking outside of the fairing. EDIT2: So, lo-fi, moving my DustFX source files into the main source directory is going to conflict with my local copy, which I've put into a sub-directory to keep things organized. It really doesn't affect the compilation process or over complicate anything in the coding process, so I'd like to leave it separated like that if possible, at least until I finish tweaking and integrating it.

Don't take me too seriously. I was in a mood. All may not be lost... though I shudder to think what will happen to my performance on this laptop I use to run KSP when this changeover happens.

How did I not notice that before? I'm such a noob sometimes.

The auto-brakes would be similar to how the mechjeb rover controller will brake the vessel when the electric charge is low/empty (which would make the wheels stop working anyway).

Okay, little update on my weird problems. Apparently they've fixed themselves. I have no idea what happened either way.

Technically, it's this movie that answers what would happen if Kerbals ran out of rockets:

I really wish there was more information to give you, but my experience was that all three parts were not even flat like that. They were shaped more like a fuel tank, all the same size and shape, with the larger one using nodes that were inset slightly. I can't explain it. This just gets weirder by the moment.