kellven

It\'s not functional for actually doing anything right now, I just posted the code in case I had solved a problem someone else was still having. -Where is this 'refuel' thread? There\'s only two things it does right now: -Handle GUI stuff in a separate static class. -Read/store information about vessels and fuel tanks in another separate static class. I haven\'t added any checks on distance yet, other than the parts needing to be within the ~2km 'off rails' zone. It\'s still in the phase of making sure it\'s working with valid data. I think I found an array of <vessel> in the FlightGlobals, and may end up using that instead, if having the fuel transfer parts reporting themselves doesn\'t work out, though it appears to be working perfectly as it is now. The real problem is the GUI handling, KSP + Unity wrappers make the GUI system downright arcane, and that\'s what I was fighting last night. Once I get the GUI setup in a working fashion, actually moving the fuel will be fairly straightforward, as everything I could possibly need to know to get it done is already stored in dictionaries and a master matrix. I think I\'m just going to land the ships next to the launch pad for testing now, too much time/effort getting them rendezvoused in orbit.

Unknown how/what changed in .15, hiding this in a spoiler to prevent accidental BFBVFS. If you\'re still running .14x for some reason, you can still use this. Just a little quick plugin to transfer fuel between ships, shouldn\'t take too long, right? Wrong. The code to actually find and store the vessels, fuel types, and tanks was untouched since I first compiled this monstrosity yesterday. It worked perfectly then, it works perfectly now. Many hours later, the GUI is still being a moody unresponsive teenage punk, and the scene transition and part message handler are still baffling arcane nightmares. Rant over, here\'s what I\'ve got now: For those of you who do not have bionic image enhancing eyes, there are actually two ships in the inky void there. I think I finally have the ESC menu fail bypassed with a ductape, caramel, and sprinkle combination, but it\'s so unwieldy I feel like a script kiddie. This is unacceptable as I do many foolish things, but I do not do script kiddie. I was really hoping to get a basic version out this morning, but that\'s just not going to happen. I apparently ended one ship\'s flight by accident, and am very very tired, so I\'m going to admit defeat for now, and try again tomorrow. Updated a bit. Edit: Just in case anyone wants to see me code in it\'s current snarled state: http://dl.dropbox.com/u/74137297/KISFuelTransferDock.cs Still doesn\'t do useful stuff, but the only true bug I could find with this version was that the vessel matrix doesn\'t clear it\'s contents when ending/switchinging flights. Of course, that\'s only because I never told it to. License GPL

I should probably point out that the actual problem with the VariableTanks was that they serialize the current fuel value, but not the max fuel value. Someone noticed that when vessel switching, this causes the gauges on the stack icons to reload with the current working max set to the old current fuel amt. So the tanks still have the correct value, but the bars reload to 'full', and empty themselves proportionally faster. It also means the tanks cannot be refilled past whatever value they held when they got serialized. **____End of 0.14 posts____**

Looks very nice indeed, though it\'ll likely make the rocketplane it\'s attached to look even more silly in comparison. I\'ll have to look at that engine sim when I have time.

Just wait for .15 & .16, modularization will end up with a master resource table, and you just tweak a part to say hold 100 units of fuel @ .002 density, or 10MW @ 0 density. There was talk of a standardized fuel/energy system at the start of .14, but modders just don\'t play well together, so Squad has to do it themselves.

Still no word on .15, frustration. I took a look at that problem you we were having with the gauges instead. public static float Consume(float Amount, Vessel vessel) MuMechVariableTank b = (MuMechVariableTank)p; b.getFuel('Energy', Amount); elsewhere public class Battery : MuMechVariableTank You\'re not getting calls to getFuel() in Battery because 'b' is of type MuMechVariableTank. Even if you cast it\'s value to (Battery), it still won\'t work, as 'new' method resolution is done by the compiler based on variable type (from examples I\'ve read online); virtual override is run time, and does not have this problem. Since you can\'t use an override, you will have to test '(p is Battery)' somewhere after 'foreach (Part p in vessel.parts)', but before you test '(p is MuMechVariableTank)'. The problem with testing for MuMechVariableTank is that Battery is derived from it, and will return true; since 'is' includes ancestor classes in testing. Something like this may work. public static float Consume(float Amount, Vessel vessel) { foreach (Part p in vessel.parts)//Check each part { if (p is Battery && (p.State == PartStates.ACTIVE || p.State == PartStates.IDLE)) { Battery b = (Battery)p; if (b.type != 'Energy') continue; if (b.fuel >= Amount)//Battery contains more energy than amount, take amount and return 0 { b.getFuel('Energy', Amount); return 0; } else//Battery contains less than amount, take it and search for next battery { if (b.fuel == 0) continue; Amount -= b.fuel; b.getFuel('Energy', Amount); } } else if (p is MuMechVariableTank && (p.State == PartStates.ACTIVE || p.State == PartStates.IDLE)) { MuMechVariableTank b = (MuMechVariableTank)p; if (b.type != 'Energy') continue; if (b.fuel >= Amount)//Battery contains more energy than amount, take amount and return 0 { b.getFuel('Energy', Amount); return 0; } else//Battery contains less than amount, take it and search for next battery { if (b.fuel == 0) continue; Amount -= b.fuel; b.getFuel('Energy', Amount); } } } return Amount; } If you stick that in MSVS C#, and hover over b.getFuel in the top block, it will show the Battery.getFuel() signature, hover over b.getFuel on the bottom, it shows MuMechVariableTank.getFuel(). The problem is that if any other code calls getFuel() from a variable of type MuMechVariableTank, whether it\'s value is cast to (Battery) or not, will call MuMechVariableTank.getFuel(). It should at least fix your call to the member, however.

I haven\'t tried this yet, as I stopped playing KSP until the .15 release is sorted out, but it\'s good to see you got it all together. I\'m not sure what models you used for the engines and battery, but it looks much less silly than what I was using back when i was using ion thrusters. Just curious how you handled Ion thrusters. The real problem with them (aside from finite electricity generation and storage) in the real world is that their thrust:mass is a tiny, tiny fraction(~ 0.00002). The figures I ran when calculating KSP engine conversion parameters gave me something like an engine with 445.46 mass for 1 thrust pulling 523,560 KW and a part radius of 25-50m representing an array of ~52 VASMIR 10MW thrusters. The numbers are probably wrong, but I stopped working on it when I realized the scale of the thrust:mass and power consumption issues. Atmospheric engines give the same benefit of 10x fuel efficiency at reasonable dimensions, so I restricted myself to those instead. Just wanted to know how you went about implementing Ion engines in a KSP usable part.

I believe the stock engine gimbal doesn\'t take into account engine position like the the control surfaces do anyway. It\'s a vanilla thing, but I believe C7 said something about a re-write of the control input in .15, so I\'m looking forward to inputs being mapped much better to their actual effect. If it works like I hope it will, it will make for much better response from engine turning, and probably make MechJeb much less jittery as well. Not an issue with this specifically, but something to look forward to in .15(possibly)

Thanks for the support, zack2014. It might be unwarranted in this case actually, I could probably work around the issue, and get the gauges to display properly, I\'m just being lazy and playing another game while I wait for .15 to come out. I\'m not exactly a patient person, and had to get my head out of KSP untill the whole QA phase is sorted. I understand that it\'s good that Squad is going through and polishing things so the .15 release is 'consumer grade', but it clashes violently with my own style of kicking things out to the public as soon as it does what the tin says. I try to do (most) bugfixing as I write code with extreme logic constraints, but that\'s not how professionals write code, it\'s less profitable

A virtual method might be preferable, but as long as the parameter passed in the GetFuel call is not cast as a MuMechVariableTank, you can just use 'new' to specify method name hiding. It will call the derived 'new' method as long as the compiler sees the method call as being of your derived type. If it sees the method call as the base MuMechVariableTank type, it will only call the base method. derivedTank tank = new derivedTank(); tank.GetFuel(); //calls derived method foreach(baseTank t in listOtanks) { t.GetFuel();//calls base method, even if listOtanks has a member that\'s a derivedTank ref } It\'s a workaround, not a fix, and I haven\'t looked at the engine code to see how/if casts are being done, but it might work for now. I\'m sure r4m0n really doesn\'t want to kick out a new lib revision when .15 is (possibly) so close.

Here\'s r4m0n\'s icon code: { fuelBox = stackIcon.DisplayInfo(); fuelBox.SetLength(2.0F); XKCDColors.NextColorAlpha = 0.6F; fuelBox.SetMsgBgColor(XKCDColors.DarkLime); fuelBox.SetMsgTextColor(XKCDColors.ElectricLime); fuelBox.SetMessage(type); fuelBox.SetProgressBarBgColor(XKCDColors.DarkLime); fuelBox.SetProgressBarColor(XKCDColors.Yellow); XKCDColors.NextColorAlpha = 1.0F; } fuelBox.SetValue(fuel / fullFuel);if (fuelBox == null) And here\'s where he sets fullFuel: protected override void onPartStart() { stackIcon.SetIcon(DefaultIcons.FUEL_TANK); stackIconGrouping = StackIconGrouping.SAME_TYPE; fullMass = mass; fullFuel = fuel; base.onPartStart(); } And here\'s onPartStart(): Nobody knows the exact sequencing or logic of the on...() method calls, but it looks to me like whenever a vessel is loaded, the fullFuel gets set to whatever it\'s fuel field was when it was saved. So yes, if you have battery MuMech tanks, they\'ll reset their cap to the last current value when (de)serialized. Since that\'s the value the icon gauges use, the actual amount in the tanks persists, but the bar resets it\'s 'full' position to whatever the bar was at when you switched vessels. I didn\'t touch r4m0n\'s tank code, just the engine code, so I\'d have to break tank compatibility to fix the gauge issue. As .15 overhauls the whole system, I\'m just going to wait a few more days until it\'s out before rethinking the system. Edit: If anyone\'s worried, I didn\'t modify the mumech engine code directly, just made a separate derived class for me to use, so my plugin won\'t screw up any others.

Gives me an idea for coanda effect surfaces, especially as you have all of these nifty fans laying about. Wait a second, that gear doesn\'t look right, are you testing .15? >(

Think I found the bug, it\'s not that the fuel tanks are refilling themselves when vessel switching, it\'s that the icon gauges are resetting to the new 'maximum', which was the previous current level. Nobody knows exactly how KSP saves data between 'scenes', but I think it\'s an issue with MuMech tanks having a custom 'maxfuel' parameter, and custom icon gauge code. The vanilla tanks don\'t have a cap, only a current value, which makes testing them difficult. I can definitely say that my Munship I left with a sliver of LOX burned through it\'s entirely 'full' gauge in a couple of seconds, so the gauge may be wrong, but the value is saved/loaded correctly.

Looks like MechJeb 1.8 or 1.81 broke the tiltrotors :< Jeb might like the new 'rifling' course correction enhancement, but Bill\'s about to be sick, and Bob\'s about to pass out. The MuMechLib.dll from DA 3.1 still rotates the radial rototron/tiltrotors properly, but can\'t use the stuff from MechJeb 1.8. I will look at the code later to see if I can spot the problem, most likely just a missed radial check somewhere. Actually, looks like this was spotted yesterday, above the wall of videos. I blame MTV for making me ignore things around a block of video, and YouTube for making me ignore the block of video itself. The world was so much simpler with radio.

Oicani, it appears to me that most of the VTOL designs you had in your video failed because you had mismatched thrust on the engine stacks, not one of KSP\'s many inherent flaws. Using quad engine VTOL is very tricky, to keep a stable liftoff, you need to keep the net center of thrust pointing through the net center of mass. The last plane where it actually worked looked like you accomplished that, which is why it launched properly. As for going out of control, that was because the engines didn\'t die simultaneously, and thrust ships tend to have momentum issues. Planes(using wings) have some level of stability in KSP because the fixed lift from the wings resists torque on certain axes, pure thrust vessels have zero stability, and tumble much easier. I\'d suggest using identical engine stacks(VAB clones), try to position them over a fixed center of mass, and be sure to include sufficient wing area to give you enough tumble resistance, even if you\'re not using them for lift. I\'ve had success with an 8 engine VTOL, but I use my own custom parts that make it much easier to create and predict a mostly fixed CoM. I\'m currently having a different problem with the rototrons/tiltrotors rotating opposite each other, but I\'m hoping a reinstall of all the mumech stuff will fix it. Seems MechJeb1.81 may have included an older dll in the package than is in the SVN.

Finally put a pic up to show off my stupid rocket tricks awesome world-shattering modding skills. Here\'s a couple more: Actually, I still had massive issues getting these things to stand up on the launchpad, but that\'s an issue with NS\'s parts\' connection settings. My old workaround to wobble was setting breakingforce/breakingtorque to 1k, using mountains of struts set to 40k, and hoping for the best as it lagged the VAB past slideshow. With the joint issues sorted, realistic cfg settings can be used without the connections going nuts, meaning you can have the structural integrity values actually mean something besides how badly the ship slides and wobbles. I have no idea what was changed internally in .15, so this may become redundant, but if the old joints are still in use, I will add fields to the cfg for the spring settings, and a bool switch to use locked or limited joints. Once that\'s done(if it is), every relevant value the joints use will be settable in the cfg, and the plugin will just be applying your settings uniformly across the craft.

Probably an issue with the MuMechVariableTanks not serializing something properly(the same tanks the COSMOS pack uses, if you wanted to check). None of my parts/code actually add anything back to the tanks anymore, the engines just have a dynamic burn switch for oxidizer. I will take another look at r4m0n\'s tank code, but I\'m sort of stuck between two problems. I\'d been poking at C7, and he\'d been dropping treats like a pinata about what\'s in .15. It appears someone took a good whack at Mu over the weekend, and a solid mountain of info came out. While it doesn\'t look like a whole lot got done in the .15 update from looking at the feature list, under the hood, it seems they did a near complete recode of the whole game. Iterative improvement like that is a very good thing to see, and that they aren\'t afraid to do heavy restructuring, most companies would pass out at the thought of heavy recoding like that. But it also means nothing I write now will have relevance past the update. The other problem is that I have no more idea when .15 will come out than anyone else does. It could be 0600 Monday morning, or two weeks from now. I\'ll look at the tank code again, and if I see something, try to fix it, but I don\'t want to write a lot of code that\'s going to be wasted effort sometime in the next week. I\'ve got a lot of ideas for functionality I want to add, and most of them are in a 'comply to code' state already. I\'m not going to work further on them until .15, and it looks like it\'ll take some time to digest the structural changes introduced. --All clear, block of text over-- There\'s a third problem of course. Toady One is hording wheelbarrows and minecarts all to himself, and teasing us with reports on his testing. It\'s just cruel that both KSP and DF are 'almost updated' at the same time, it\'s a clear failure to communicate, and it\'s inexcusable. Edit: Forgot to mention that I left the old engine models in so they could be stack attached like normal rockets at the bottom of a stack. I have plans for keeping a bottom connector engine like that, with air intakes poking out of the top rim radially.

It\'s a value set in the cfg file that determines the thrust curve. http://kerbalspaceprogram.com/forum/index.php?topic=8560.0

Oops, sorry. Took down the picture of Thobewill10\'s model by mistake. This is a set of engines and tanks. The tanks are just MuMechVariable tanks set to hold 'LH2' and 'LOX', with appropriate stats for their contents. The engines are hybrid atmospheric/space ramjet/rockets, stats were converted from Skylon SABRE engine stats. Basically, they\'re air breathing LH2 jet engines until you hit 30km, after that, they need LOX as well as LH2 and function as rocket engines. The ugly grey and black models are by me, the non-ugly model was made by Thobewill10. Everything was balanced around SE V2a, and the stock fuel tanks. A lot more could be done now that r4m0n opened up his plugin to extension, but like most people, I\'m waiting on .15 release. Every time I poke one of the devs, they keep spilling more treats about what\'s in the update. The info I have already, makes coding anything else for .144 pointless, so it\'s sort of nap time until .15 comes out.

Been deliberately ignoring KPS for a few days. It looks like C7 not only got atmospheric engine code into the main game, but from the last video he posted, it covers everything I was adding to MechJeb to extend the engines. Very good news, not only can I now use C7\'s fantastic part models(as they\'re going to be in the base game), I also can just tweak the new atmospheric engine class, rather than creating it out of whole cloth like r4m0n and I were doing. In other words, I can now start actually modding again, instead of coding to extend the game. Be sure to thank C7 when the update gets released, really top notch job.

Now I\'m very confused. I\'ve got a function to pack a bunch of cfg-parsed-fields into a list<> for iteration sanity. If I understand what Alchemist wrote, I can just call that function from OnPartLoad and be done with it. But I thought each physical part on the ship got it\'s own instance of the corresponding part class...how can the instance of a class possibly exist at game loading if it\'s not created until you pick it in the VAB? I\'m probably just tired and not thinking this through, otherwise Squad\'s invented a code time machine.

Oh, I see now. Anyway, I was thinking about an adapter plugin between ROS and the servos, but I really don\'t have the time to write it.

If you mean MechJeb, this is MechJeb. The autopilot wouldn\'t have a clue what to do with a bunch of servo controls though. You can set the speed of the rotation in the part.cfg yourself.

Just wanted to let you know, I think C7 may have gotten a dedicated atmospheric engine module into the code for .15. Not really sure yet, but that would simplify a lot of things code wise.

And just what may I ask is wrong with two plugins for one part? If we\'re already at 1 plugin per part(which we are very near), 2 makes little difference.