OnPack in PartModule?

[Tosh]

Is there a way for PartModule to be notified when a Part gets packed for orbit?

Surely I can override the Part itself and make its OnPack() method raise some Event... but I want my PartModule universal and connectible to any Part...

[Romfarer]

I'm pretty sure onPack is called at the same time as another "on" method. I was fiddeling a lot with that when i was making remote control. Maybe onSave does it?

You could also check every frame if the Part.pack is set.

Or ask Mu to add a onPack method to PartModules.

[Tosh]

You could also check every frame if the Part.pack is set.

Something tells me that this won't work... When part goes "packed" KSP expects it has all the joints and rigidbodies deleted immediately; including those ones that plugin might have created. Doing that in OnUpadate or OnFixedUpdate may be a bit too late

Or ask Mu to add a onPack method to PartModules.

From my experience of "asking Mu" -- most likely he won't do

[Romfarer]

What are you trying to accomplish?

[Tosh]

What are you trying to accomplish?

Apparently, a PartModule that adds some joints and rigidbodies to any part it's attached to. Specifically, it would automatically spawn struts (i.e. joints) linking all the SymmetryCounterparts together.

I need it for my new landing gear (so I could easily implement strut spawning in Part class itself) -- but I'd like this 'strut-spawner' to be universal. Just imagine you're side-mounting 8 SRBs -- and they automatically get all the struts they need!

Main problem originates from "packing-for-orbit" mechanism: all the additional joints and rigidbodies must be removed before Part's main rigidbody is. Part class descendant overrides Part.onPack for doing it; PartModule cannot.

[Romfarer]

I dont think i really understand the problem.

So when you add the landing gear (rocket or airplane landing gear?) to a vessel in VAB or SPH you use onAttach to also add struts linking the landing gear to the part it is attached to or struts linking the landing gear counterparts together. Why do you then need to remove the rigidbodies from the joints? Is it imaginary struts or actual struts?

[Tosh]

So when you add the landing gear (rocket or airplane landing gear?) to a vessel in VAB or SPH you use onAttach to also add struts linking the landing gear to the part it is attached to or struts linking the landing gear counterparts together. Why do you then need to remove the rigidbodies from the joints? Is it imaginary struts or actual struts?

They're pontoons . Just a new version, with working wheels.

And they just must be linked together (not only to craft's hull! See two horizontal bars in the bottom.), if I don't want the plane to break apart when landing on the ground. And -- yep, they must be actual struts... i.e. Unity Joint objects.

Joints connect rigidbodies. KSP delete rigidbodies in OnPack. If there's a joint still connected there, then KSP fails.

Currently, I'm using KSP Strut parts to fix pontoons in place, and I'm just tired of adding them manually. I'd like some automation here.

Edited August 11, 2012 by Tosh

[Romfarer]

This is something i would definately add to my planes

It seems to me that the problem here is: How to programmatically add struts in the SPH. Struts that appear automatically when you add the pontoons to a plane, linking the pontoons to the part they are attached to and between the pontoons. After they are placed they will look and operate exactly as if the user added the struts themselves.

You should probably consider to just leave that up to the user as there are "infinite" ways to connect those things. And even if you do manage to add them programmaticly, the structure of the plane will probably requre additional struts anyways.

[Tosh]

Darn, I'm tired of 'em sliding apart on landing every time I descend just a lil' too fast. I need 'em stronger.

Next, I'm tired of adding struts manually each time I change pontoon placement just a tiny bit. Struts are always needed here.

Moreover, everytime I create a rocket with side-attached SRBs, I link those SRBs together with struts. I could really use strut auto-spawning.

And there's not a problem to add joints programmatically. It's even not a problem to destroy them right in time when overriding Part class. I've already implemented that cr... stuff a couple of times.

But as soon as it comes to PartModule...

FFFFFUUUUUUU

Edited August 11, 2012 by Tosh

[Alchemist]

That's stupid. PartModules don't have half of the events (you can't even make something passive for an activatable part!), Part can't read IConfigNodes from part.cfg (PartModule reads them, but they aren't copied when spawning an actual part, too). What do they want from us to do? Mixing these things to get at least something to work? I don't get it when new better system works even worse

[Tosh]

What do they want from us to do?

Apparently, nothing

There's not a question like this. "They" (KSP developers) want the system to be convenient for themselves in the first place. "One function per part" principle (i.e. using Part class only) might become a limiting factor at some point; so Mu started game engine refactoring, proposing his PartModule system. But then, refactoring was somehow postponed in favor of adding new functionality...

That's quite a common situation in software development. I'm currently facing exactly the same one in my own business : I'd like to ditch some code I wrote in 1998 (!!!) and redo it from scratch -- but I haven't gotten time to do that...

I don't get it when new better system works even worse

Maybe we gotta give it some time to evolve? Or to be ditched completely in favor of something more appropriate; generally it's hard to tell beforehand.

[Romfarer]

Maybe we gotta give it some time to evolve? Or to be ditched completely in favor of something more appropriate; generally it's hard to tell beforehand.

I mainly use part modules for persistance purposes and i think it is brilliant at that. For example making the kerbals on EVA remember what vessel they came out of.

Then again, i completely agree that more onSomething methods are needed in the part module class.

[Alchemist]

The feature is that the stock classes really can be converted to PartModules (or at least most of them, not sure about the strut connectors if there is this issue). If the ability is passive, just autoactivate the part - results in inability to stick active and passive abilities on one part.

But most of the things we are creating are over this level, so they can depend too much on some specific cases. And here is the difference between editing your own project and adding modules to something closed - if they run into limitations of their own system they can change it, when we get into such trouble we can either abandon this idea or make it in a rather unsafe and glitchy way. So here's where we are given something that doesn't wok at all in half of the cases.

As I understood, the devs tried to make something with simplier interface for it to be more efficient, but it ended incapable of some of the important things we had in Part. And all this configNode system proved to be very unfinished, too.

It would be okay if this system was really evolving with feedback from plugin developers - this way we'd make it capable of everything in just a couple versions, but the developers are too busy adding new features.

And here's what I hate about programming for something like this: instead of actually developing something you are forced to be searching for hacky ways around some badly placed corners.

[Tosh]

It would be okay if this system was really evolving with feedback from plugin developers - this way we'd make it capable of everything in just a couple versions, but the developers are too busy adding new features.

I reiterate once again: the system ever exists for devs in the first place. And they're busy enough with feedback from the gamers (yep, with so-called "bug reports"... including those on game-breaking bugs).

I believe there's helluva lot of things having much higher priority than creating an "ideal plugin interface". And that "priority" is the matter of management, rather than programming itself.

And here's what I hate about programming for something like this: instead of actually developing something you are forced to be searching for hacky ways around some badly placed corners.

All I can say here: deal with it. "Actual development" for 80% consists of passing around that darn corners... even in most thought-out and well-designed systems. Sadly I really do know what am I talking about; I've seen a lot of them systems...

---

Uh, guys, I hate the discussion derails to generic programming/management problems.

Once again, is there any chance (or hack ) that class A could be notified on class B calling its protected method, without modifying B's code? Quick search through System.Reflection assembly reference gave me nothing...

...and KSP is not the one having the prize for Most Ugly Software Design. KSP's near the end of that list, to be honest

[Kreuzung]

@Alchemist, you can have passive code in void Update() and void FixedUpdate() (it's not an override, just define them yourself and they will be called).

Note that they are also called in the VAB, I always use if(!HighLogic.LoadedSceneIsFlight) return; to prevent that.

[HarvesteR]

PartModules don't have a virtual method that gets called when the vessel packs and unpacks, but parts send the OnPartPack and OnPartUnpack messages to all components attached to the same game object, so if you have public void methods with those names, they should get called when the parts pack and unpack.

Cheers

[Tosh]

PartModules don't have a virtual method that gets called when the vessel packs and unpacks, but parts send the OnPartPack and OnPartUnpack messages to all components attached to the same game object, so if you have public void methods with those names, they should get called when the parts pack and unpack.

Cheers

Ah-ha.

Thanks a lot, I'll give it a try

[Kreuzung]

@HarvesteR:

Whould it be possible to get a list of all messages Part and all stock parts / part modules send? I'm curious if I don't know something that whould make things a lot easier...

[HarvesteR]

@HarvesteR:

Whould it be possible to get a list of all messages Part and all stock parts / part modules send? I'm curious if I don't know something that whould make things a lot easier...

Currently, there aren't many of these messages, as they're part of the new PartModule interface, which we are slowly building up to replace Part subclasses. I've been adding them as needed here, but here's what we have now:

OnPartPack - sent when a part is packed

OnPartUnpack - sent when a part is unpacked

OnVesselPack - sent to the vessel object (the root part on the ship), when it packs

OnVesselUnpack - sent to the vessel object (the root part on the ship), when it unpacks

OnVesselLoad - sent to the vessel object (the root part on the ship), when it loads its parts

OnVesselUnload - sent to the vessel object (the root part on the ship), when it unloads its parts

OnVesselDie - sent to the vessel object (the root part on the ship), when it dies

OnPutToGround(PartHeightQuery) - sent to all parts on a ship when it's placed at the runway or launchpad. Used to override the default ground-finding algorithm, for instance, in case of a landing gear that is supposed to start deployed, or the launch clamps.

Coming in 0.17:

OnCenterOfThrustQuery(CenterOfThrustQuery) - used in the editor scenes to find the center of thrust for the whole vessel. Parts that produce thrust are required to fill in the values in the query object.

OnCenterOfLiftQuery(CenterOfLiftQuery) - used in the editor scenes to find the center of lift for the vessel. Part that produce lift are required to return a lift force value based on the reference velocity vector on the query object.

IIRC, that's all of them for now.

Cheers

[Tosh]

OnPutToGround(PartHeightQuery) - sent to all parts on a ship when it's placed at the runway or launchpad. Used to override the default ground-finding algorithm, for instance, in case of a landing gear that is supposed to start deployed, or the launch clamps.

Oh. That's useful indeed in my case... Thanks for an information!

[Arrowstar]

Harv, are those new messages going to break backwards compatibility with currently available add-ons?

[Tosh]

Harv, are those new messages going to break backwards compatibility with currently available add-ons?

They're messages. Class may have a message handler if it wishes to, but it may just omit it.

UPD. w00t!

Here are them auto-struts:

They work exactly as intended.

The funny thing is that they don't need no OnPack at all . It turns out that, unlike some other physical components, FixedJoint and ConfigurableJoint do not give a dang are their rigidbodies still alive. My apologies: false alarm, eh...

Edited August 17, 2012 by Tosh

[HarvesteR]

They're messages. Class may have a message handler if it wishes to, but it may just omit it.

The funny thing is that they don't need no OnPack at all . It turns out that, unlike some other physical components, FixedJoint and ConfigurableJoint do not give a dang are their rigidbodies still alive. My apologies: false alarm, eh...

Ahh yeah, this is why we didn't bother much with packing and unpacking for the new PartModules. Joints are only active while their rigidbodies are non-kinematic. When vessels pack up, their joints get paused automatically (This is the beauty of the new part packing/unpacking system we created in 0.16. It's that much simpler now).

Cheers

[Tosh]

This is the beauty of the new part packing/unpacking system we created in 0.16. It's that much simpler now.

Ah, it's the packing system that has changed? I didn't even know that.

WheelColliders now don't need to pack too; so I could finally remove packing code from the Cart :thumbsup:

Topic closed, thanks. I've no more questions about onPack