Gaalidas

Now you just need to make configs for those ASET wheels and we'll be good to go. Now, lo-fi, I need you to merge some changes in the project file because I just merged github with my new files that will eventually be a better logging utility (maybe?) and, more importantly, the implementation of DustFX into KF. I've also done some updates to the scaletypes and the parts in relation to the scale modules and commented out some modules that I believe are redundant now (such as the old icon fixer modules, which went config-less quite some time ago I think).

How about... unpowered wheels with rockets attached to them? Or better yet... unpowered wheels with tiny rockets attached in such a way that the wheel will be rotated by them! Now that would be Kerbal...

Fuel-powered wheels, eh? I do remember there are some old, and quite dead, mods that implemented fuel usage for rover engines and such, but, as I said, they're quite dead now or in perpetual WIP status with no working releases. The simplest implementation would simply be to swap the electric charge resource in the configuration for the wheels with whatever other resource you want to use. I would also think that combustion-reaction propelled wheels would be a lot more responsive to input, but also a lot less controlled, and have a possible idling speed that could actually add more functional uses for the brakes. Possibly a throttle-based propulsion control? hmm... Interesting idea.

So, upon further investigation into what those Batman style audio texts are has revealed that they are likely, in reality (so to speak...) RPM texts being warped out of proportion and sticking out from the transparent pod internals. It's rather disturbing now, rather than comical.

Excuse me if I don't get my hopes up... but it would sure be about time we at least got some new progress reports. I suffer for the lack of these components.

Mac users should be prepared to become rainbows when doing random things. It comes with the territory.

KSP starts rendering text to represent audio events? yeah, I hear you... that's pretty nasty. But kinda cool too...

Indeed. I would never have made it with the config node crud without him.

Alright, I'm going to add a new file to the source and start trying to make my recent ideas into a reality. Adding the DustFX spinoff into the KF plugin will be as easy as copy and paste really. It's pretty clean over all as far as code cleanliness considering it was mostly coded to fix my badly coded attempts by xEvilReaperx as I begged for help with my broken code. I'm still not sure exactly how he made that happen in the end, but it works.

Only clean plasma sails. Dusty ones will require an add-on that is specifically built to handle the dusty nature of the dusty plasma sails. I would recommend cleaning them before use in any case.

That's the great thing about separate working folders between github and a local directory. Anything you overwrite, I can overwrite better! Err... what I mean is... I'll check out the new stuff and re-merge anything I've done into it. Another thing I started working on was a better way to identify all of your log entries with not only the plugin name, but also the specific class that it's coming from in the form of constant strings that contain a prefix, then using "string.Format" to prefix all of your logs with that prefix. However, I'm considering adding a custom method to your source which will make the process of conversion much easier, basically replacing all calls for the log methods with a custom method which will insert the appropriate prefix into the calls. Either way, work is being done when I have free time (gasp!) to better identify when, where, and what the error or information being logged is referring to. I'm also considering if it might be better to package my DustFX plugin into the KF plugin considering I made it primarily for your parts and pizzaoverhead has been strangely not responding to any of my attempts to let him in on the developments I've made working off of his original code. Besides, the dust that is thrown up from the repulsor colliders is so good that it really should be a stock behavior for this mod. The only thing I want to add it the ability to have the dust be thrown up when the repulsor craft isn't moving, but only when the repulsors are fired up. Hey, if I don't remember to do it soon, remind me some time to post up my latest WIP of the plugin for you to play with. The effect is quite nice.

This is literally the problem with navigating using a solar sail that I was thinking about when considering attempting to make such a craft. Unattended navigation, however, is going to be a must... or at least the ability to track how long it has been since the last time the craft was referenced (either by switching to it or loading its on-rails position) and updating its position based on where it should be. Ideally you would set up a transfer using the sails and then go do something else while the solar winds push your craft to the spot you want. Of course, deploying and retracting the sails should be done in person. Same for ion engine crafts, where the only thing that should be happening unattended is the thrust, but any modification to the thrust level should be done in person. At least, that's my thought process. If that can't be achieved, I'd settle for the craft being able to continue with the maneuver while I am focused on another nearby craft so that I can control a larger formation of vessels all making use of sails for maneuvering colony modules ahead of the crewed mission. Finally, way down the line, this would be an awesome add-on for mechjeb to let its auto-calculation control where and when the sails need to be used to get the craft to a specific location.

That's what you get for not working right from github in the first place. Every time I update things, I first download anything new from github and use winmerge on it to make sure I'm not screwing anything over, then sync it back up. By the way, that MM config update for TweakScale is... well... still in the works. Yes, I know it's about three weeks behind my last estimated arrival time, but then 1.0 was released and everything went to heck. Once heck is over with, I'll get the... uhh... heck... back to it.

Wait... what did I do now? I actually haven't done much of any updates lately, despite my various reports of "impending updates to the code and/or MM configs" that I've been threatening you all with for the last month. School always gets in the way at the wrong time.

Holy epic wide screen...

Considering the hang is on the loading menu, I highly doubt it's isp/thrust related.

I only just noticed, when browsing Kerbal Stuff for recent updates (found a mod that didn't have the correct API extension DLL specified and caused KSP to stop loading... completely... like totally stuck... okay, I'm done now.) that you added the transparent pod disabling in the editors thing I was working on a while back. Awesome stuff. Now I can remove my custom override DLL I made with just those methods in it. EDIT: in reply to the Chinese student's post... your English is actually an improvement over many native English users that post on these boards. I wouldn't worry about little mistakes so much were I in your shoes. Not that I want to trade shoes with you or anything. That would be creepy.

As far as I'm aware, we're looking good without any updates required from even the pre-1.0 editions. As for procedural stuff... we've been through that conversation many times in this soon-to-become mega thread. It's just too brain bending to figure out at this time. Fortunately, with TweakScale support on all the tracks, you can easily set up clusters of tracks where you'd originally want one long one. It won't function exactly as you'd expect a one-piece track to function, but it works in the end. I would think, however, that some sort of procedural track could be produced in this custom-made stroke of genius brought to you by... well... me... So, what you'd do is make a basic procedural part that would act as the visual representation of the track itself. Not the inside wheels or anything, just the outer rubber band. This part would have a track texture and would use something like your texture animator to make it look like the track is moving. The collisions and what not would then be provided by a set of inner wheels which would be made as companion parts to the track. The track itself wouldn't have any collisions that the wheels would be able to interact with, and so the wheel parts (with a larger collision range to accommodate the track thickness) would be able to handle everything. The tricky part will then be making the procedural track attach to one of those inner wheels exclusively, so as to make sure that the orientations remain accurate, and controlling the texture animation on the procedural track to match the speed that the track would need to be moving for the current maneuver (turning, moving forward/backward, etc.) In other words, it'd be re-making that whole thing about the stock wheel bug that lets people make what appears to be hovering rovers (using wheel colliders and flat panels) except you're not using a bug technically, and you're providing a visual to make it look right. But, I have no clue how to implement this... so good luck making it happen. You're gonna need it. Oh, by the way lo-fi, I must have mentioned by DustFX spin-off from CollisionFX right? So, I finally got it working with a complete and extendable configuration file to define dust colors for biomes and planets (and possibly as detailed as specific locations using "landedAt"). Everything can be controlled, including particle strength and speed (which I also made TweakScale exponents to handle) on a per-wheel basis. Well, I added the module to the repulsors, before this KSP 1.0 release screwed up all the mods (temporarily of course), and did a little testing. As it turns out, the collisions that the repulsion field create also trigger the DustFX collision detection and throw up dust on the ground when you're moving over the surface. It looks awesome, and I really wish I had screenshots or something to show.

That mining rig is... well... really whacky. I love it.

Wow, this is an old thread that's found its way back to the surface.

A note: I don't think DDSLoader is necessary anymore. Squad wouldn't make their own content dependent on a mod, so I have a feeling they've integrated DDS loading into the stock loader. The vertical flipping is actually very necessary. When you export DDS files from the asset files, which are loaded before DataFiles, you have a DDS file which is upside down. If you use a generic image viewer (such as IrfanView) to view the DDS and then re-save it as a PNG, you will need to manually flip it vertically for the PNG to be loaded into the game correctly. When converting to DDS, you need to not only change its format, but also flip it again in the vertical axis for KSP to use it correctly. I don't know why it works that way, but it does. The DDS conversion utility that was mentioned does this automatically for you. As for quality, DDS is actually quite accurate if you use the correct DDS format. Some formats will screw up different images in different ways. I don't pretend to know what format is best for each case, but the utility does a lot of that for you and has been very good at it. However, the real culprit is mip-mapping. Unless you generate mip-maps using Gimp (in which case you can specify the filter to use and what not) then the mip-map generator will simply do what it does by default and KSP will then load those mips instead of the full resolution file based on whatever logic it uses to determine what the texture resolution for each instance is supposed to be. Sometimes that first mip-level will be a major reduction in quality. Some tricks I've found while modding games like Skyrim is to manually delete a mip-level from the file (I used utilities specifically made for those mod flatforms, so not much use here at this time) forcing it to re-adjust its mip-levels to compensate for the lowest quality level being a different mip-level than it expected. Other tricks were to simply replace the first mip-level with the full resolution texture. This bloats the DDS file a bit, but tricks KSP into thinking that it's loading a lower resolution version of the texture than it really it. How I do it: I make sure that the texture isn't overly large (I do a lot of resizing before I install due to running KSP on a laptop that wasn't specifically designed for games) and then I launch the utility and I unclick the box that tells it to generate mip-maps. KSP will load the full resolution every time it needs the texture. Even at extreme distances. Yes, this has an impact on performance for large textures, but it also reduces the situation where a very close proximity texture is being loaded under a mip and is appearing lower in quality. I'm really hating that mods are now distributing in DDS format because it makes quickly editing them for performance a bit of a pain. I'm going to need to find a way to add DDS->PNG conversion to my mod unpacker batch files that I use to extract all of the mod archives and process their various files for unwanted readme files and textures in a over-sized format. Addon: By the way, KSP still loads up all the other texture types that it did previously (no idea if they fixed the TGA issues, however). EDIT: So, you liked my comment about the staplers. That was a moment of pure randomness. - - - Updated - - - I want it. Badly.

From where all names with periods come from. The land of periodites, where else?

You're thinking too much like a developer, and not enough as a tester. The Dev says "heck, it worked before, so surely everything is fine." and the tester says "Your baby is ugly and smells funny, go fix it!" and the battle of the lost staplers begins. Many deaths. As for stock wheels, I don't think they even worry about orientation. That's why you can place wheels are strange angles and still have them work the way you expect (within reason). KF wheels are much more finicky about where they are initialized and if you move them, they get cranky. I believe some sort of "reset" would be a good idea for many of the problems we've faced with KF products. Included is the issue with repulsors within physics range only functioning on the last vessel to be launched. If a reset could be activated when such issues arise, you might be able to get around those issues without having to reload the scene. Eventually, with some testing, we might even be able to automate the reset process for certain situations, such as when a vessel change is detected. It seems to me, you could export all the scene-load initializations into a separate function and call it from the scene-load event, but also be able to call it from a GUI item labeled "Reinitialize" which would, when activated on any KF part, redo the initialization process for the current vessel. Sorta like the current actions for applying steering settings, or applying all wheel settings which are available now.

gah! I was just about to get my game stable again and then they release 1.0 and now everything is going haywire again.

That sounds like the most plausible fix. You would likely have to reference the original lift module and include a toggle for the entire function in order to make lift a togglable function. If, however, power drain is supposed to be a part of it then scaling power drain with speed is a good answer. However, to keep the power from draining when moving slowly over the ground, I would set the minimum speed for power drain to start only when a certain speed is attained, whatever that speed is which allows the wings to start generating lift. Otherwise, a plane on the taxiway making it's way from the hangar to the runway will be draining power because it's moving.