kellven

Recompiled against MechJeb 1.8.3, going to leave up old versions at least until the 0.15 mess stabilizes, don\'t want to force anyone to update things unnecessarily.

Recompiled again for MechJeb update, going to have to make sure the fuel handling is done correctly when I get time to sort through the mess that is 0.15. Made a very easy to fly spaceplane, so I stuck that up also, I know some people want to fly, but have difficulty with aeronautic design.

The logic tree got too big, and I had to separate it out into another two functions. It did seem to process the joints correctly though. It might not actually fix anything until the first stage gets activated, seems to be another feature of .15. As I was updating the main post, I realized MechJeb is now at 1.8.3, so I\'m going to have to check that out too now, and hope I don\'t have to recompile it again. The plugin loader changed, and it\'s rather buggy atm, so no guarantees.

I was unable to reproduce it, but I will try actually launch/takeoff. I also found out the latest DA 'wormplane' hinge thingies aren\'t being properly excluded from the joint replacement, so I will have to fix that too. Actually, I left all of my .14 stuff up. With .15 still so buggy after two weeks of testing, it really makes me wonder exactly what the testers were doing, and what the initial version looked like. Edit: I looked through the code again, and noticed something that may possibly not be set quite right in light of the rotatable parts. The plugin loader algorithm in KSP changed in .15, and there\'s at least one bug in it related to references, this was referencing the .14 mechjeb plugin, so I relinked that to 1.8.2 version also. I still couldn\'t get anything like you were describing, but I\'ll try the new batch and see if that fixes my problems with the tiltrotors. Assuming the problem was actually in MechJeb (which is extremely buggy atm), relinking may fix your problem as well. If you could hit F1 when your ship turns, and post a screenshot, it would be extremely helpful. I would think that if this was causing a problem, it would be rotating the parts individually, nothing should be affecting the ship itself, unless the dynamics of having wobbly joints somehow made the thing more stable when the abrupt gravity turn starts at 10km. MechJeb is know to cause spiral mode troubles when it\'s jerking the controls about during that phase.

I tried, but just couldn\'t come up with a workable 'wormplane' like you had in the video. Have to add a new exclusion check for that hinge to my jointfixer. Have you figured out yet whether it\'s MuMech screwing the liquidSeekAnywhere, or if it\'s the tanks themselves redirecting everything on their own regardless of which gets designated? I had the same problem with porting my engine to .15, and trying to compare it to a stock rocket engine makes me think it\'s just the buggy fuel code from the stock game. At this point, I\'ve given up trying to balance the fuel consumption until it gets fixed, but the CoM shift would be nice to remove.

Looks like the beginnings of a barge, more than a traditional boat, but still very good. I had big problems with the water physics when I was playing in the water, hope you have better luck.

Ok, I\'ll look through the code again, I had not really updated it for .15 yet, so it might be something to do with the new runway launch, or it might be something in the new model scheme that I need to take into account. Is this 90\' rotation on the parts, or the ship as a whole, and is it when doing a runway launch or pad launch. I actually haven\'t even used this yet in my own .15 game, so I\'ll have to try it out myself.

Thanks Mu, I\'m still a bit dazed processing this, but great job taking the time to explain things for us. I had a couple initial questions/issues that came to mind: 1. Is there a way to manipulate or read which modules are running on a Part runtime? Specifically, is it possible to add a module, or retrieve a list of modules that are attached to an arbitrary Part reference through code? Looks like there\'s public PartModule AddModule(ConfigNode node); public PartModule AddModule(string moduleName); and public PartModuleList Modules { get; } and public void RemoveModule(PartModule module); @->2. How are conflicting resource definitions handled? As in multiple mod/plugins specifying the same resource name (LOX or LH2) with differing parameters (lbs/ft^3 or kg/m^3 or kilobananas/doo-hickey). Also, is there anything in place to allow differently named resources (LOX and LiquidOxygen) that should resolve to the same physical substance 'object' to do so? 3. Perhaps I\'m still a bit out of it, but in your 'generic reaction engine' example, how exactly are you calling part.RequestResource(p.id, p.currentRequirement); Seems the module class has a 'part' member that presumably gets set to the relevant part. @->4. The fuel feed system seems to be massively bugged in the initial .15 release. Even once that is fixed, some of us prefer to specify our own 'resource distribution' scheme. If we use part.RequestResource(), are we locked into the default distribution rules? Can we explicitly call a something-or-other on a specific part reference to get it to specifically handle resource...stuff only within itself(as in not propagating the task beyond itself)? I think that\'s it, but you\'re finally forcing me to learn reflection, attributes, and a whole bunch of that other silly C# stuff I\'d been ignoring, so um...what was I saying again? Anyway, thanks again for explaining it to us. Edit: Thought of another thing, is there a way to add a new resource entry in code at runtime? Looks like there\'s public PartResource AddResource(ConfigNode node); public PartResourceList Resources { get; } @->Edit 2: In light of the changes to the structure of the part cfg files, does the new paradigm extend to the actual Part definition, and if so, could you please give us an example of what a blank part cfg should look like? As in just a static do-nothing part before any module stuff is added? @->Edit 3: Fuel handling is usually done by mass flow, not volume flow(At least in calculations or stat listings of rocket engines, ie Isp, dry/wet mass, stoichiometrics). Having the resources specified in tank and requests in units of volume rather than mass necessitates more spreadsheet work when setting up parts. @->Edit 4: This post looks like a huge mess now, but I was wondering how the part GUI\'s, and icon infoboxes are to be handled. Still working on creating your generic rocket module example, but how/if it interacts with the game GUI is still a mystery. Same goes for a modularized fueltank, especially as I have it set up for dual fuel storage and burn right now.

I have terrible framerate with .15 also, but we found something of a workaround. Just ignore the pony, and give it a try. Have you actually found anything on the resource system? I haven\'t actually seen anything of it.

Since you\'re into the micropart business, have you considered 'inline' RCS modules? As in a .2m or so slice of a fuel tank that shoots jets out radially. They can\'t directly alter spin or grade, but I\'ve found them to be very useful for sticking on the ends of long ships where the torque does the most good. Also simpler and no alignment errors when it\'s all one part. Just thought I\'d share an idea. Looking forward to getting SE 2 stuff back in KSP. The default part balance is as frightening as the bugs right now. Happy modding.

Found interesting data while trying to drain Kerbin\'s oceans, and fix the lag maybe. -FlightGlobals.fetch.bodies will give you an array of celestial bodies, of which one is named 'Kerbin' and one is 'Sun' -Iterating that array for 'Kerbin' will give you it\'s CelestialBody -PlanetQuadTreeController CelestialBody.terrainController from one of those cb\'s yeilds null -However, PQS CelestialBody.pqsController is NOT null, have to play with this further -Also, CelestialBody.referenceBody called on Kerbin\'s cb will give you the 'Sun', might be helpful if r4m0n gets around to making MechJeb allow reverse hierarchy injection burns.

Found workaround to new loader issue, and ported to .15, changed to use base fuel and mass. No issues noticed in brief testing, other than it may be a little too easy to get orbital with this. Bugginess of .15 base game makes balance attempt pointless at this point.

Problem solved, add a \'Z\' to the beginning of your plugin name. See last post here for underlying problem: http://kerbalspaceprogram.com/forum/index.php?topic=12393.0

Tried a pure plugin reference plugin ... plugin set, and that did load and play correctly, so it\'s not the new plugin loader that\'s the problem. Going to have to get dirty now and dig into MuMechLib. I\'ll let you know when I get it working.

Thanks, still snarled in a MuMech Engine update that won\'t load, but this plugin is so simple I doubt it will actually need updating. If you don\'t actually attach a black box to your ship, none of the code here runs, so finding out if the stuff still wobbles is just a matter of removing the box temporarily. Unfortunately, I\'m one of the people getting unplayable gfx lag whenever Kerbin surface is on screen, so testing where the wobble is usually most noticeable is not really possible for me yet.

You\'re not the only one who\'s curious about the formats, I think what you\'re looking for is this: http://kerbalspaceprogram.com/forum/index.php?topic=11795.0 Probably not exactly the answer you wanted, but it\'s all I\'ve managed to find so far. As I\'m a dedicated 'programmer artist', I\'m sticking with dae/png until forced to jump through the new hoops. I\'d use ascii art if I could.

The plugin loader is throwing cryptic errors at me, so I\'m thinking I may have to ditch MuMechLib for the moment, and invoke copypastafu to get it to work until I can figure out why the new loader hates me. That will cause problems with the engine control window, however. Need to think this through on a fresh brain after sleepytime. Going to take a while.

Running into issues with the new plugin loader. Since you were the only other person I knew of who extended one plugin with another, I was going to ask you if it was throwing a fit with your plugin also.

Looking through my output log, seems the plugin parser is trying to load stuff from subdirectories under Plugins. If you stuck your project folders in there, probably a good idea to move them out now.

Tried a simple update with this, but no workey still. Not sure right now if r4m0n forgot to update his source code svn with the 1.8.2 MuMechLib code, or if it\'s something basic changed in LiquidEngine. The DA props do seem to be working, so I\'ll try a cfg transplant surgery until I figure out exactly how the code changed. Had serious problems trying to make a helo ascent stage spacecopter, due to C7\'s atmo engines being deactivatable with part menu, but rocket engines not being deactivatable, so getting a space capable engine with MuMech menu control is top KSP priority for me now. I also temporarily changed the Broadsword engines to pull generic fuel for both fuel and oxidizer for simplicity until I can get a handle on what\'s going on again. Oh, did I mention there\'s a DockingPort class in the code now? No idea if ActivateAutoDock() or Undock() do anything yet, but the class is there at least. Hope to have a working engine again soon.

Had some bizarre going on so far with this, first was the turbines attached to tiltrotor parts ending up pointing the wrong way, second was the ducted fans being um...symetrical. The problem is that they don\'t have a visual front/back differentiation, so figuring out which direction to face them is a bit of a challenge. Also seeing the old joint bending again, but I have a solution for that, if it still works.

When you said 'performance didn\'t seem any different than .14', did you mean the plugin didn\'t seem any different, or that the default joints are still slidy/wobbly? I\'m getting terrible lag on entering the flightscene right now, but I didn\'t notice any problems with the vanilla joints yet, so I\'m really not sure if they were changed.

Your input is requested. Pretty please? I\'ll give you some LOX?

DF 0.34.08 is finally out, so I\'m not likely to be working on this for a little while. The GUI code is now in a much more orderly formation, and the only technical parts left are restructuring/repurposing the vessel/fuel matrix as needed, and adding the fuel requests. If someone wanted to take parts of this and make their own fuel transfer plugin while I\'m off in Uristan, go right ahead. I did a bunch of fuel related stuff in my atmo engine plugin for my Broadswords, here\'s the code for that too: http://dl.dropbox.com/u/74137297/KAtmoEngine.cs Feel free to copy/paste/rewrite/toast/jam whatever you like out of them.

After much testing, tinkering, and general screwing around, I can say that protected override void onGamePause() { KFTDWindowCrap.Pause(); MonoBehaviour.print('K Paused'); MonoBehaviour.print('FD.Pause = ' + FlightDriver.Pause.ToString()); base.onGamePause(); } protected override void onGameResume() { KFTDWindowCrap.UnPause(); MonoBehaviour.print('K Unpaused'); MonoBehaviour.print('FD.Pause = ' + FlightDriver.Pause.ToString()); base.onGameResume(); } shows the static property FlightDriver.Pause seems to be usable in place of onGamePause()/resume with one notable exception. -When switching flights with the tracking station, onGamePause() is called if you use the ESC menu to switch OUT of a flight. onGameResume() is NOT called when switching back INTO a flight. Unknown yet if FlightDriver.Pause updates itself in this instance, but I suspect it does, so if you really need to know if the game is paused, it might be better to check against FlightDriver.Pause than handling onGamePause()/resume. Now I\'ve got two questions: -Does anyone know of a way to catch when a flight is ended(as in switching flights, ending them, or whatever)? Ending a flight even through vessel switching seems to clear whatever GUI callbacks you had setup(with no additional code on your part), and this is giving me problems as I need to know if I have to reinstate the GUI callback. -RenderingManager.AddToPostDrawQueue() takes an int 'queueSpot' as it\'s first param, however, there doesn\'t seem to be a provided getter function to return a valid entry for this. At first, I assumed this was a sort of unique GUID so the wrapper can keep track of handles, but then I noticed there\'s also public Callback[] postDrawQueue; which is an array, not a list, which would imply it has a predetermined number of elements. My questions, if anyone knows the answers are what are we supposed to pass as queueSpot, and are we limited to a predetermined number of registered callbacks, and if so, how many?