Agathorn

If I understand some of what i'm reading in my research, it looks like i'm going to have to build a custom class that can pack and unpack itself for KSPField. Surely someone has done this before though that is what is driving me batty.

Well I really want the subnodes for flexibility I'd prefer not to hard code things like body names or else the mod won't work with mods that change those. So I tried doing this: public override void OnLoad(ConfigNode node) { print("FlightDataRecorder: OnLoad"); print("FlightDataRecorder: " + node.ToString()); if (node.HasNode("BODY")) { ConfigNode[] bodyNodes = node.GetNodes("BODY"); foreach (ConfigNode bodyNode in bodyNodes) { print("Found body " + bodyNode.GetValue("name")); bodyValues.Add(bodyNode.GetValue("name"), Convert.ToDouble(bodyNode.GetValue("value"))); } } base.OnLoad(node); } public override void OnSave(ConfigNode node) { print("FlightDataRecorder: onSave()"); print("DUMPING BODY VALES"); foreach (var key in bodyValues.Keys) { print("key:" + key + ", value:" + bodyValues[key]); ConfigNode bodyNode = node.AddNode("BODY"); bodyNode.AddValue("name", key); bodyNode.AddValue("value", bodyValues[key]); } base.OnSave(node); } But it didn't make any difference. In fact from what I can see the OnSave() is being called BEFORE the OnLoad() when you add the part to a Vessel in the VAB. OnSave() gets called, but OnLoad() never does until you move into the Flight scene. So trying to keep the values from OnLoad is pointless. Nothing I can figure to do will allow the values loaded from the part.cfg to make it through to an actual instance of my part

It sounds like some people are having problems with TreeLoader which this pack uses.

Well i'm not even trying to make it persistent, as in saved with the game save, I just need the values that are defined in the part.cfg (or an override) to be made available to my PartModule when in Flight.

That sounds like my exact problem then thanks! On a sidenote, I was going to use KSPFields but I wasn't sure how to do that for complex data types like nested config nodes, which I would store internally as dicts. How would I do that?

Rather the other way around, because some of us would like the flexibility to use the AppLauncher if possible rather than further cluttering the screen with TWO separate bars. If you could figure out a way to forward a registered button on over AS AN OPTION for the user, I think that would be great. The new AppLauncher may not be perfect, and your toolbar may be better overall, but the new on has many things going for it, the biggest of which is its there. It isn't going away and its bad enough finding a spot to put your toolbar, now I have to deal with two of them.

I'm still asking though "WHAT" specifically isn't loading? This is a collection of a crap load of mods and moving parts and without knowing specifically what you are having problems with, we can't really help.

This should be such a basic thing done by tons of mods out there but I can't figure it out I must be doing something fundamentally wrong. I even tried storing the data in private variables on that initial load, but as expected since the game spawns off a new instance of my class when the part is added to a vessel, that does no good.

Very nice Trigger thanks!

No, the problem is the data doesn't even exist when the part instance is loaded with the actual craft. Its all gone. Even the non-nested primitive data values. It is all there on the first load during game load, and all gone during load of a part on an actual vessel.

I meant community documentation. Some people have figured it out as i've seen mod updates saying they support it. - - - Updated - - - Yeah some already support it - - - Updated - - - That would be nice, thanks.

How do I get the ConfigNode data from .cfg into an INSTANCE of my Part? I have a PartModule with this: public override void OnLoad(ConfigNode node) { print("FlightDataRecorder: OnLoad"); print("FlightDataRecorder: " + node.ToString()); } and a config like this: MODULE { name = FlightDataRecorder foo = bar num = 42 BODY { name = kerbin value = 1.0 } SITUATION { name = landed value = 0.0 } SITUATION { name = flying value = 1.0 } SITUATION { name = prelaunch value = 0.0 } } When the game first starts up and all the parts are being loaded, I see that fire and all the ConfigNode information is in there. However when I start a game, goin to the VAB and add my part, then go to the LaunchPad, that method fires again for that instance of the part, but NONE of my custom ConfigNode information is present.

Going to be a real mess having two toolbars though What would be awesome is if Blizzy can find a way to: 1) Enable the new applauncher in all scenes 2) Make it so that buttons registered on his custom toolbar get "forwarded" into the applauncher (which was made to enable to in all scenes)

Why are you even bothering to post in this mod's thread if you don't like what it does?

Would it be possible to get a recompile anyway? From what i'm hearing its "A good thing to Do" due to major changes in both Unity and KSP.

Does this mean KONQUEST is delayed?

Is there any documentation on how to put buttons into the new 0.24 application bar?

LOL. Scarily true and i've been guilty of it myself.

This rocks thanks so much!

Sorry I knew that. I wasn't clear but I was simply trying to verify that was STILL the case with the 0.24 update.

I see there is a separate assembly DLL for the x86 and x64 version. So um, which do you compile against? Is there a benefit to compiling against both and releasing x86 and x64 versions of the addon?

I assume the proper install is get the old version, and then apply the dev DLLs?

LOL. Its a frenzy out there right now!

Ok so yes I did some more reading and your right that the filtering is still far better in mipmaps than on GPUs. I thought they had gotten better than they really had. BUT I still want to address the memory issue because there is a misunderstanding here. YES they are loading in RAM and take up MORE space. But when you are doing the actual draw calls, with the lower resolution Mips you are in fact saving texture bandwidth. That is what I am talking about. They ARE a performance improvement in actual rendering, even though they use more memory to store the mips. But yeah, I guess the filtering tech in GPUs hasn't come as far along as I thought they had, so mips are still better overall. The big problem I have with mips though is if not done right they really can create really bad muddy textures, when a too low resolution mip is loaded for a model.

Ok lets just say we are both right. Yes, the aliasing issue is possibly dealt with better by mipmapped versions, though i'd argue that the scaling in GPUs is so good now that that particular benefit is not really an issue anymore. The MAIN reason for MipMaps, originally when they started back in the day, was to reduce overhead. Back when computers struggled to display even the crappiest graphics, you had to optimize things everywhere you could and one way to do that was to use lower resolution textures on objects that were smaller on screen IE as they got farther away, switching to a lower resolution to save memory. So let's just agree to disagree and say we're both right?