Gaalidas

Caustic and toxic? Sounds like Bill's morning power-drink. It's all brown and if you don't drink it right away the glass will melt. I don't know how he can stomach the stuff, but I tried using it as a basic propellant yesterday and I got a whole 20 feet off the ground on just a cup-full of it. Then it melted the tank and proceeded to fizzle on the pavement and release noxious gasses that may have contributed to the death of a few interns, though no concrete evidence can be brought up... conveniently. But hey, if it works, lets put a bunch in a booster and see what happens!

Only a few posts up he already answered your questions. Just ignore the warning for now.

That beast is sweet. I'm surprised it floats so nicely like that. As for the runway, you might have to start it out supported by some launch clamps to keep it from bouncing on launch. To further reduce that, start your repulsors out with zero percent height using the tweakable in the editor and providing other means of support. I remember my early tests with these things resulted in some crazy maneuvers to try not to roll over and go -smoosh- before I even got it launched. EDIT: stupid me, didn't read the rest of the posts. Oh well, at least now it's been double-suggested to use clamps.

That's odd... I haven't touched the file names, but even if I had it would not have told me there was an problem with the model, it would have told me that the model didn't exist. Still, I gotta check on that. EDIT: No, sure enough the model file name is intact, it's just the log that's spaced a little strange. The config has the right model name as well. I don't know what it could be. I'll try re-downloading the model. EDIT2: I did find something strange in the config file however, though I doubt it would cause any issues with this. Still, worth fixing. This was in the part.cfg of the alpha repulsors (non-surface mounted) crashTolerance 1200 Which I assume should be: crashTolerance = 1200 eh? And that was in the github version, not my local file. I fixed my local file a few minutes ago before I checked if that mistake was in the github.

Noticed today that the alpha repulsors were missing. did a little research and found this: [LOG 15:09:27.305] Load(Model): KerbalFoundries/AlphaRepulsor/AlphaRepulsor [WRN 15:09:27.320] File 'C:\Program Files (x86)\Steam\SteamApps\common\Kerbal Space Program\GameData\KerbalFoundries\AlphaRepulsor\AlphaRepulsor.mu' is an incorrect type. [WRN 15:09:27.322] Model load error in 'C:\Program Files (x86)\Steam\SteamApps\common\Kerbal Space Program\GameData\KerbalFoundries\AlphaRepulsor\AlphaRepulsor.mu'

I always maintained that using turbojets for that first atmospheric ascent stage could be a very viable way to launch efficiently. Now we just need the parts for 'em.

Funky... how does it balance on that? Or is that due to the reaction wheels going nutty trying to keep it upright?

That thing is nuts. And I mean that in the best way possible.

That little kerbal reaction segment was awesome.

Yeah, now we just need some wheels that actually do that. Or Skids... or Landing Legs... or whatever. Awesome... cause I was thinking that would be amazing for creating sci-fi styled engines with lights running down the edges and stuff.. to name but one application.

Wow, this thread really took off all of the sudden. I didn't get to see the texture animation mishap, but I can sure see some awesome uses for such a plugin if the controls are pretty flexible. I look forward to seeing the next iteration of the track. As for the wheel replacement, I see no problem as long as it functions in the same awesome way. In fact, I can see a use for those even without the repulsor side added to them. If they could sit on the ends on the wheels when turned for repulsor mode, you'd basically have a wheel that transforms into a landing leg. If we end up with the ability to completely disable the repulsors, then this functionality can continue to work even after the repulsor is added. Just need to make sure the wheels quit responding to input once they are changed.

Wow, you're good. I'm finishing an update as I type. Well, not literally as I type because I sorta need my keyboard to do it... but in a moment I will.

Hey sweet, thanks. I was just doing some code diving (and trying to wrap my brain around something that it's not ready to tackle) and was just about to bring your attention to something I saw in there, but I'm glad you've found it yourself so I don't make myself look foolish. I honestly wouldn't know up from down in all that code. I've only had one successful compile, and all I did was swap some things around in lo-fi's repulsor module. I also must apologize. I got a little heated in the head there. I guess it was bad timing for this error to show up, that's all.

EDIT: I had previously written all sorts of comments regarding the last reply to my issues. I have sicne decided it's not worth arguing a point that doesn't really matter overall. Just know that my complaint was not about whether FAR is a good mod or not. I have a lot of respect for the attempts to bring realism to an obviously unreal world. I just have issues with it personally. My problem is with the latest release of this mod. That's all. EDIT: I just read that you're willing to try and replicate. However, I have a feeling you won't get very far with that. I'm sure that mod releases are well tested considering the long-time success of the mods in question. I'm still combing through my various plugins and configs to see if there is anything that could possibly be causing Module Manager to think that I have FAR and do the adjustments. Even if that were the case, however, I've had FAR parts loaded into the game before and all that happens is that the log contains something along the lines of "could not find module of that name" and continues as if nothing was wrong. This is different.

FAR should not be a requirement to run this mod. I've been running it forever without FAR with no issues. I choose not to use FAR because it makes building and launching rockets a real pain, and mechjeb support is still not quite what it needs to be for us non-spaceflight gurus to actually launch anything. From what I gathered from this update, Procedural Wings now fully "supports" FAR, there was no mention of it now "requiring" FAR. If it now required FAR, then how am I supposed to fly all the crafts that are made with Procedural Wings which fly perfectly fine for me without FAR? The correct question should have been "do you use FAR?" instead of "have you updated all your mods?" Also, I did not actually see anyone else saying this version worked. The postings since the release have been all of about 1 or 2 other than mine. If there'd been 10 or more posts of people saying that version 0.9.1 worked perfectly with AND without FAR, then I would assume there's something on my end. As it is, all evidence points to this mod. My errors only started after installing this mod. So please, at least have the decency to not assume that I am an idiot when you are trying to diagnose a problem I am having.

Woah there, I think I saw something about a raycast and some gibberish about physics and other good suggestions when moving things, and that's where my ability to understand things fudged up. Nice to know you understand it though. Oh well. Still, might be a great idea to revisit the range for the tweakable. The mole tracks responded all the way to 0%, but the rest of the wheels/tracks seem to respond only down to 50%.

Yeah, it is a stupid idea. No, I'm kidding. Yes, I make sure to update things properly whenever possible. The first thing I did was reinstall it freshly when it started spitting out errors. Sure enough, this version straight out of the box is buggy.

So, this mod no longer functions after updating to 0.9.1. The relevant parts on my log are pasted below: [LOG 14:20:27.453] Proceduralwing2: Calc Aero values [LOG 14:20:27.455] Gather Children [LOG 14:20:27.457] FAR [LOG 14:20:27.458] FAR Done [LOG 14:20:27.474] PartLoader: Compiling Part 'ProceduralDynamics/Parts/DYJproceduralwing2endcap/part/Proceduralwing2EndPiece' [LOG 14:20:27.500] Proceduralwing2EndPiece: Calc Aero values [LOG 14:20:27.501] Gather Children [LOG 14:20:27.503] FAR [LOG 14:20:27.504] FAR Done [LOG 14:20:27.523] PartLoader: Compiling Part 'ProceduralDynamics/Parts/DYJproceduralwing3/part/Proceduralwing4' [LOG 14:20:27.551] Proceduralwing4: Calc Aero values [LOG 14:20:27.553] Gather Children [LOG 14:20:27.554] FAR [LOG 14:20:27.555] FAR Done [LOG 14:20:27.576] PartLoader: Compiling Part 'ProceduralDynamics/Parts/DYJproceduralwingAllMovingSurface/part/ProceduralAllMovingWing' [LOG 14:20:27.605] ProceduralAllMovingWing: Calc Aero values [LOG 14:20:27.607] Gather Children [LOG 14:20:27.608] FAR [LOG 14:20:27.610] FAR Done [LOG 14:20:27.632] PartLoader: Compiling Part 'ProceduralDynamics/Parts/DYJproceduralwingB9/part/ProceduralwingBac9' [LOG 14:20:27.658] ProceduralwingBac9: Calc Aero values [LOG 14:20:27.660] Gather Children [LOG 14:20:27.661] FAR [LOG 14:20:27.662] FAR Done [LOG 14:20:27.682] PartLoader: Compiling Part 'ProceduralDynamics/Parts/DYJproceduralwingSPP/part/ProceduralwingSPP' [LOG 14:20:27.708] ProceduralwingSPP: Calc Aero values [LOG 14:20:27.710] Gather Children [LOG 14:20:27.711] FAR [LOG 14:20:27.712] FAR Done [LOG 14:20:27.734] PartLoader: Compiling Part 'ProceduralDynamics/Parts/procedural_ControlSurface_1/part/pCtrlSrf1' [LOG 14:20:27.764] pCtrlSrf1: Calc Aero values [LOG 14:20:27.765] Gather Children [LOG 14:20:27.766] FAR [LOG 14:20:27.768] FAR Done [LOG 14:20:27.790] PartLoader: Compiling Part 'ProceduralDynamics/Parts/procedural_ControlSurface_SH_4m/part/B9_Aero_Wing_ControlSurface_SH_4mProcedural' [LOG 14:20:27.817] B9.Aero.Wing.ControlSurface.SH.4mProcedural: Calc Aero values [LOG 14:20:27.819] Gather Children [LOG 14:20:27.820] FAR [EXC 14:20:27.822] NullReferenceException: Object reference not set to an instance of an object WingManipulator.CalculateAerodynamicValues (Boolean doInteraction) WingManipulator.Setup (Boolean doInteraction) WingManipulator.OnLoad (.ConfigNode node) PartModule.Load (.ConfigNode node) Part.AddModule (.ConfigNode node) PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) PartLoader+.MoveNext () [ERR 14:20:27.877] createHull: convex hull computation failed! [LOG 14:20:27.878] B9.Aero.Wing.ControlSurface.SH.4mProcedural: Calc Aero values [LOG 14:20:27.880] Gather Children [LOG 14:20:27.881] FAR [EXC 14:20:27.883] NullReferenceException: Object reference not set to an instance of an object WingManipulator.CalculateAerodynamicValues (Boolean doInteraction) WingManipulator.Setup (Boolean doInteraction) WingManipulator.OnStart (StartState state) Part.ModulesOnStart () Part+ .MoveNext () The loader stops functioning and that point and I have to forcefully shut the process down.

So, today I started messing around with the medium tracks (yours, not the RBI stuff) and I noticed something a little odd. I don't have the capability to put up an image at this moment, but here's my best description. The wheel-thingers are alright, the bottom half of the treads works okay, but the top half is clipped downwards so that it clips with the bottom half of the treads and/or the rest of the track body. Otherwise it functions just fine. EDIT: I just tried out the RBI invertible tracks and they're all whacko as well. Instead of the top portion clipping into the bottom portion, the upper row of wheels and the track rubber-banding over them are super high compared to the rest of the tread. It's all connected as far as I can tell, but man is it really funky looking. You sure did a crazy one on these babies in your last code updates. Something else I've noticed about all the wheels is that anything below 50% ride height is pretty much ineffective. As it appears, 50% is the lowest that any of them can achieve. I wonder if 50% could be reset to read 0% and give the wheels another 50% ride height above the default height? This would provide more flexibility and give the under-50% range something to do. The one exception seems to be in the mole tracks. While subtle, the lower-than-50% does have a noticeable effect. Last observation for the moment. The action groups to change torque (specifically the tracks, haven't tried the wheels yet) work pretty well except that, like the repulsor ride-height stuff before we fixed it, you have to right click and tell it to apply the setting to all (even when the action group is activating a track that is symmetrically attached, which should make that group affect all symmetrical parts.) I haven't been code diving is a while, so I can't direct you at the exact bit of code. Maybe later if I feel industrious.

The hovercraft maneuvering system sounds a lot like the Firespitter swamp-boat fan. Okay, so it's an extremely low-tech example, but it's the best image my brain could conjure.

That's just the problem. There are no steps other than: 1) install mod. 2) run game. 3) notice the launch selector images sitting too far to the right and being cut off. It should be noted that this was not always the case with this mod. This issue has popped up in the last few versions of this mod. The images and launch locations are both stock-KK and Kerbin Side. No alteration has been made to any of the images or configurations.

Six cameras? Sounds a bit like overkill to me. I like it though.

Hey lo-fi, have you seen this thread on the possible implementation of multi-threading for KSP mods? I don't know how useful it would be, but considering there's a lot of stuff happening that gets more complicated with the more wheels you have on a craft... well, it might be something to at least look at. While not ready to be used widely yet, it'd be something to consider for the future. Thread Here.

Well crud. Sorry you're having difficulty. I'm afraid my troubleshooting skills end at this point. Someone else will have to take a stab at it from here. Any takers? I've had this happen as well with some modded pods. I've only had it happen when somehow the alpha layer was being removed from the texture for the window, if the mod in question uses the alpha layer to do that sort of thing. Some modded pods do the transparent windows from the model layer, instead of relying on the texture. I must admit I have no clue how they do any of it, I just know that i have accidentally edited out an alpha layer from a texture and not discovered my mistake until a week had passed and I finally got the pod into the air. In the end, I am unsure what the culprit could be. I don't actually use ALCOR myself. It's rather ram-heavy. This is often either a sign that the full-size textures that LOD is loading are still overloading your memory limits, or that LOD is being forced to load and unload full-res textures at too fast of a rate and the air-passages got clogged (so to speak) in the chaos. I've had this happen when flipping pages in the VAB too quickly for LOD to keep up, and too slowly for LOD to not notice. There's this magical sweet spot where things just go wrong. Interesting little thing here, I remember when .25 was released and we were asking for an update here on the forums. However, not a lot happened until someone went to his github and opened an issue. If you're having trouble stirring up that author here, might want to go poke him where it hurts (so to speak.) I'm just a guy with no off-switch to make him shut up. EDIT: Holy crud! Now I'm getting the exact same error. I haven't even changed anything! What the heck is going on here? EDIT 2: Whew, false alarm.

You are misinformed. Yes, the extension is referenced in the model, but KSP ignores that extension and loads the texture anyway without issue. I would not advise something that was not tested and used thoroughly. I have been doing this sort of thing for over a year now with no issue. Rest assured that I have looked into whether or not it will work and it does work.