kellven

Unfortunately, the PartModule system isn\'t used by the stock parts. There are some PartModule classes in the stock code base, but I believe they are just the examples from Mu\'s thread. If you want a single part to handle multiple functions, you need to code in those handler functions yourself into a Part/PartModule subclass. Ideally, after the PartModule system moves beyond it\'s initial demonstration phase, you\'ll be able to include functionality by just adding blocks to the part cfg file, or even just drag and drop in the VAB, but it\'s just not there yet. Right now, you either have to code a set of PartModules to handle the mechanics you\'re wanting to implement, and then add them to your cfg; or make a normal Part subclass that handles all of the mechanics, perhaps a set of functions/subroutines/methods that get called in sequence inside the (Fixed)Update block. Happy moddings.

I just wanted to add that while it does get tricky, as <someone> ...cough.N3X15.cough... has a mischievous habit of breaking stuff like dependencies, r4m0n\'s code classes can be derived from, so stuff like rotor rotation can be piled on top of another part class like meat sauce on spaghetti. Also, the throttle setting/thrust vector used by a given engine can be controlled by code, but you have to override the FixedUpdate block, which entails rewriting the gimbal code. Not that hard in itself, until you get to part rotation, and arbitrary axis alignment, then it\'s just a crapshoot. If you want a simple non-gimbaling tail rotor, you don\'t need to re-add the gimbal code, you just need to manage the throttle separately with some control algorithm, and correctly hook the thrust vector to the rotor part axis and offset.

Coming soon to an orbit near you: Jeb got hungry. Not without my slushee. Interplanetary Module of Pancakes https://dl.dropbox.com/u/74137297/KISIMOP.zip KerbalMart https://dl.dropbox.com/u/74137297/KISKerbalMart.zip

I also had to recompile against MechJeb last night. Fortunately, I\'ve made the plugin I\'m working on now, to only interact with MuMechLib indirectly, so there\'s no reference. Getting at class members is still going to be difficult, but Mu told me a while ago he might be adding a static field/prop/something with an Assembly, or Assembly[] or somesuch containing the plugins that loaded correctly. Just hope he didn\'t forget. About the library linking thing, I was also getting errors every time I called string.isnullorwhitespace(). I finally found this the linky there seems to indicate the code in Unity derived blocks only supports .net 2.0, which is somewhat frightening. Fortunately, things in classes not derived from Unity stuff seem to get much better latitude.

That is a very interesting choppa, those winglets rotate for airbrakes? Also, really don\'t understand why people keep asking for the Skylon, but the engines are already done over here: http://kerbalspaceprogram.com/forum/index.php?topic=10065.0 Should still work, if I don\'t have to recompile against MechJeb again. Better check that now. I believe I also figured out why the MuMech engines aren\'t pulling fuel properly anymore. I think calling RequestFuel on the stock FuelTanks tries to drain through the stack now, instead of draining from that tank directly. It\'s also giving me fits trying to get my custom fuel boxes to show when I modify them indirectly, and I had actual MuMech tanks that were working correctly earlier.

Fun with Gimbals: For some reason, I have both .mu files, and .dae stuff in my LiquidEngine2 Part folder, not sure if I put them there, or Squad did. In any event, trying to grab hold of the gimbal transform, this is what I encountered: -Using the model.mu files: The following all fail, except the very last one, part.FindModelTransform('solid_rocket'); GimbalTransform = part.transform.FindChild('model').FindChild('obj_gimbal'); if (GimbalTransform == null) { Debug.Log('KIS fail0'); GimbalTransform = part.transform.Find('model/obj_gimbal'); if (GimbalTransform == null) { Debug.Log('KIS fail1'); GimbalTransform = part.FindModelTransform('obj_gimbal'); if (GimbalTransform == null) { Debug.Log('KIS fail2'); GimbalTransform = part.transform.Find('solid_rocket'); if (GimbalTransform == null) { Debug.Log('KIS fail3'); GimbalTransform = part.transform.FindChild('solid_rocket'); if (GimbalTransform == null) { Debug.Log('KIS fail4'); GimbalTransform = part.FindModelTransform('solid_rocket'); } } } } } How did I get 'solid_rocket'? I derived from LiquidEngine, and asked it nicely to tell me what 'fallbackGimbalName' in LiquidEngine was. -Now using the mystery liquidEngine2.DAE files I had: The first three attempts all succeed in acquiring the gimbal transform. The last three all fail. Conclusion: 'obj_gimbal' has been replaced with 'solid_rocket' in the LiquidEngine2 at least. The .name of the Transform assigned to the gimbal object also reports as 'solid_rocket', so I assume that\'s a fairly safe bet. Also, FindModelTransform called on a Part instance seems to be the preferred method of obtaining this thing, as it was the only function which successfully acquired the gimbal transform from the model.mu files, and also retrieved 'obj_gimbal' from the liquidEngine2.DAE without bothering with 'model'. As always, expect someone to come correct me shortly.

Actually, you CAN convert a class to a string, that\'s why I mentioned .tostring(). If you\'re using VS, just type override then space, and select object.tostring(). Or write the override yourself. Useful if you want a data-container object to be 'string-able' for debug printing/etc.

I thought about doing something like the X-33 once, the biggest problems were the limitations of the one part-one function system we had, the general floppy rocket principle KSP uses, and the impossibility of making a functional lifting body before plugins. I would like to see someone try this now that we have code-your-own-adventure capability. Using PartModules, you could actually make the thing just one single huge part now.

Not sure what exactly engines we\'re talking about, but one of the 0.15 ones at least has a no-deathray option. By deriving a new engine class from it, adding a gui button to reverse thrust, and overriding the FixedUpdate block with a check for that button, and flipping the thrust vector 180 before passing it on to the base, you could get around the 0 thrust minimum 'feature'.

Added link to more functional version. Really needs cleaning up, but lots of low level stuff is working now. It also pulls fuel properly, and evenly, though I couldn\'t get the actual KSP resource request system to work right, and made my own.

Haven\'t tried Romfarer\'s namespace trick, but I discovered the plugin loader broke inter-plugin references the last time it got updated. It\'s supposed to be being fixed, but the workaround I had was to append \'Z\' characters to the plugin file name, as they apparently load in alpha order.

I agree with Romfarer, only 2 things to add: 1. If musiclib[curSongPos] does resolve to an int, and you want to display it, might want to try removing the (string) cast, and making it musiclib[curSongPos].tostring() 2. If you\'re still getting problems, try adding a few Debug.Log('Made it this far: 0'); lines inside whatever block is causing the problems, that\'s helped me figure out exactly where the problem occurs many times debugging my own code. The last log to show up before you hit the exception in the place to start looking.

Completely recoded the fuel matrix four times, moved the } in the tank code that was causing the fuel box bug, recoded the persistent storage locker again, and rebalanced the engine specs again so they\'re actually matched to the LV-T30 for real this time. Also moved most non-plugin specific stuff into extension methods. This is actually in a flyable state now, tested a quick orbital launch with identical results to stock equipment: Did I mention that is completely custom coding for everything? I finally settled on using: public Dictionary<Guid, Dictionary<int, Dictionary<int, List<PartResource>>>> KMasterResMx { get; private set; } To store the valid resource tanks. I will need to change that yet again when I move on to stage 2 of my sinister plan, but I want to get this working again, and it will shortly be possible to burn through fuel in stock tanks, and resource 'tanks' automagically, without any extra hoops to jump through.

It\'s actually not the tiltrotor, prefim. It\'s the connections between the parts attached TO the tiltrotor. r4m0n fixed the connection inside the tiltrotor a while ago, it\'s actually the single most solid connection on a rocket atm. I had a fix for the rest of the part to part connections, but it just doesn\'t work anymore in 0.15x. HarvesteR said he was going to be changing things around under the hood in 0.16, which I believe will make my joint fixer usable again, but for now, we\'re stuck with floppy rockets. On that note, I think I posted this in my joint fixer thread, but never sent this here where it rightly belongs:

Fun with Part Stage values: After testing, came to some conclusions about part stage values: For <Part>: stages are 0 based ascending, comand pod starts in stage 0. inverseStage = the stage the part appears in the actual stage GUI(ie, final stage after all adjustments). inStageIndex = the index value of a part within a stage. Zero based.(ie if part is the third part in the fifth stage: inverseStage = 4 & inStageIndex = 2) originalStage = which stage the part was added to originally by the game. Zero based. defaultInverseStage = appears the same as above, unclear difference. manualStageOffset = what it says on the tin.

I believe you can set the start angle of the joints in the cfg, or if you just want the robojoint rotated, can use the <> buttons in VAB.

Getting very close to something fully functional now. Still have to figure out why the resource system is only reporting half the fuel it\'s actually burning, and messing up my thrust ratio. Recalculated engine parameters by volume, not mass flow, and it\'s almost perfectly inline with calculated and observed stock rocket/tank fuel burn now. Not setup yet to handle air ram/LOX switching. Going to need single fuel LH2 tanks for atmospheric mode as well. The module tank and engine can actually handle an arbitrary number of resources, it\'s just setup as dual chamber at the moment. If you look closely at the GUI\'s, there are no actual FuelTanks or Engines on this bird. The stack icons are a lie:

Mu say: 'So you can\'t use constructors on classes derived from MonoBehaviour (Part, PartModule, etc). To do your constructor stuff in a PartModule you need to the override OnAwake method.' Which explains quite a lot of the bugs I\'ve been having. I think I have the C# thing mostly nailed down, but learning Unity is still troublesome. Not going to update my code here right now, as I\'m almost done with a larger system this is a prototype for, but in short: Do Not -use class constructors for Unity stuff Do -use OnAwake to do constructor stuff Also Do from Mu public string classdata = ''; As in provide default values for stuff that defaults to null, but don\'t do it in a constructor. Also, check for null in OnAwake, before just assigning new: if(DumDumList == null) { DumDumList = new List<DumDums>(); } //instead of DumDumList = new List<DumDums>(); EDIT: Also, if you open a part.cfg that uses ConfigNode stuff in NotePad++, and set the Language to Batch, it handles the structure very well.

Work continues quietly. Can you smell what The Count is cooking? EDIT: Better explanatory picture:

That was interesting, it seems the [KSPField] persistence might still be having problems, but a separate static class with a static ConfigNode field will persist (Just doesn\'t get cleaned up I guess). If that will work with a List<ConfigNode> also, can just call a static member inside OnLoad to check if the part is already in the list, and if not, add a new ConfigNode('PartName here') to the list. Then in OnStart call another member to return a node by 'PartName here', and send it to whatever Load(ConfigNode) members need it to re-initialize the part data. Eliminates the need to read/write from disk.

Alchemist, I assume you\'re using the part.RequestResource thing. Have you tried modifying part.Resources[0].amount directly? I\'m curious as to whether or not that also modifies the return value of part.GetResourceMass. The part.mass remains constant (as in the old drymass value), and I\'m not entirely sure whether or not the mass from resources is thrown into the gravity, CoM, and applyforce calculations, or is just ignored. I was going to add micro-resource tanks to my part-engines for air, oxidizer, and fuel, so they would work as a complete-engine-in-a-part instead of the multiple-parts-per-engine we seem to be having now. Probably not a big thing, but would be nice is the wetmass of the engine was used when applying the force, instead of the drymass, empty/full fuel tanks are something else entirely. If there\'s an additional 'RequestMode' param added to the part.RequestResource, I\'d like to see an option to lock it to a specific part, so it would assume there\'s no crossfeed paths connected, and just pull from itself. To pull from a tank, you\'d have to call the method on a ref to the specific tank you wanted to draw from.

I haven\'t looked at Kreuzung\'s code in a while, but it\'s a known problem with r4m0n\'s MuMech tanks, and the vanilla ones as well. They\'re designed to work like rocket fuel tanks (kill on empty), not refillable storage containers (batteries). Not really sure where MechJeb is going with regard to the new resource system. Now that I finally got my Connect plugin kicked out, and have a semi-functional workaround for class type field persistence, I can get back to tinkering with the resource/engine system. Hopefully, I\'ll have some findings to share soon, so that will probably help this out, assuming Kreuzung, and everyone else isn\'t already 10 steps ahead of me.

Ok, it works reasonably well. Smithers, release the hounds.

It looks now like the root problem is the terrain collision. I got the new plugin to behave like the old plugin, so it\'s at least where the last version was. By 'loosening the bolt' (projection settings function exactly like a bolt) 0.025 KerbalDimensionUnits, the ballet on the launchpad turns into a jitter and wobble in whatever parts are in contact with the ground. The behavior also occurs when landed off the pad, so it\'s the terrain collision itself, not the pad surface. The behavior does not manifest in small mass objects, only heavy ones. Once in the air, the problem resolves either way. I believe the turn to north is just the result of an unstable initial launch trajectory, or it may be something else entirely, there\'s so many bugs in the game now it\'s impossible to pick one out individually. The good news is that by making that 0.025 KDU adjustment, the rocket engines in contact with the pad wobble and slide, but the rocket remains upright, and given time to sort itself out, comes to rest. That exact measurement was the minimum to achieve dynamic stability, and probably varies by total load force on the contact points. The bad news is that the Unfathomable Mu the Magnificent confirmed my suspicions about object types not persisting, and is working on a bugfix. There\'s actually a ton of data needed to setup a joint right, too much to store it individually, so the cfg settings for softjointlimit data are highly buggy. Once that is fixed, tweaking spring and dampening forces might help make the problem unnoticeable. The good and bad news is that this is almost ready to be released again in working condition, the remaining problem is that struts seem to instantly snap when replacing the other joints. Once I figure out how to stop that, it should be usable, if still buggy.

Yay, hoo-ray, it\'s finally done. The thing you\'ve all been waiting for is finally here. What does it do? It makes every single part on your ship explode simultaneously! Seriously though, I finally got this mountain of code 'working', as in fully functional, actually replacing the joints, and making the parts explode. Here\'s some demonstration screenshots: This transcript was recovered from the black box: Jeb: What happen ? Bob: Somebody set up us the bomb. Bill: We get signal. Jeb: What ! Bill: Main screen turn on. Jeb: It’s you !! Kellven: How are you gentlemen !! Kellven: All your joints are belong to us. Kellven: You are on the way to destruction. Jeb: What you say !! Kellven: You have no chance to survive make your time. Kellven: Ha ha ha ha … Bill: Jeb !! Jeb: Take off every ‘ZIG’!! Jeb: You know what you doing. Jeb: Move ‘ZIG’. Jeb: For great justice. [00:00:00]: Structural failure on linkage between ZIG and FL-T500 Fuel Tank. ZIG collided with fuelTank - relative velocity: (2.1, -1.8, 5.7) fuelTank Exploded!! - blast awesomeness: 0.9 Once I figure out how to replace the joints without making the ship explode in 0.15, this should be good to go.