Plugin for multiple vehicles ???

[Chris_C]

Now I could be completely wrong but I'm assuming if you have a part module (plugin) that it's update method is only executed while a single vehicle is actually active (ie being flown)

That being the case for some ideas if you wanted multiple flights to have their parts plugin executed some kind of work a round would be needed. ( for example mapping from multiple satellites simultaneously)

I notice that with the GPS plugin although it probably doesn't execute anything in the GPS satellites it can at least iterate through each of the flights names and then get the position of each satellite with a name starting GPS...

It then occurred to me that you could have a base station "vehicle" that in a similar way iterated though flights to build a list of all flights containing a specific part, the only problem is I assume you'd have to create a plugin instance (somehow) for each part and then execute their updates...

Of course in an ideal world there would be some kind of flight centre plugin.

Does anyone with more plugin writing experience than me (not difficult) have any thoughts on this?

[iamaphazael]

My understanding is that the PartModule class (from which all plugins are subclassed) has methods not only for when a part is placed, loaded into the flight scene, activated, etc, but that there is also a method that is called when the module is first loaded into memory. Deadbeef's subassembly loader is an example of this kind of usage. So, I'm not exactly sure what it is you want to do, but the upshot is that it's possible to run code without having it be tied to a part that's on an active vessel.

[Chris_C]

My understanding is that the PartModule class (from which all plugins are subclassed) has methods not only for when a part is placed, loaded into the flight scene, activated, etc, but that there is also a method that is called when the module is first loaded into memory. Deadbeef's subassembly loader is an example of this kind of usage. So, I'm not exactly sure what it is you want to do, but the upshot is that it's possible to run code without having it be tied to a part that's on an active vessel.

I'm not exactly sure what it is you want to do,

ok lets take for example you want to do mapping with multiple vehicles - when the module is first loaded into memory - odds on there isn't a created list of all your flights (but I don't know for sure)

If you're mapping it would be handy to have more information than just the vehicles position, ideally the specific instance of the plugin for that vehicle, so you could get that vehicles plugin's private variables...

There could be other reasons for wanting access for each flights plugin instances, this is just an example off the top of my head...

[EndlessWaves]

The game's list of existing vessels (used for the tracking station, map screen etc.) can be gotten using FlightGlobals.Vessels

PartModule extends MonoBehaviour so Public void Update() is always run and public void FixedUpdate() is always run when in physics range regardless of active vessel status (not to be confused with OnUpdate and OnFixedUpdate, which do have some active vessel limitations I believe).

Obviously if you're trying to query other people's or stock partmodules then there may be additional checks to make sure they're running on the active vessel so there's no guarantee you can ever get that to work, but certainly for custom PartModules it shouldn't be a problem.

Although obviously if you can get the results from saved information then that's often a better bet than running stuff in the background.

[OrbitusII]

What's been said so far is correct, Update and FixedUpdate run regardless of what vessel is active, assuming things are within the loading range. You could create a plugin that makes sure the vessel that things are being calculated and enacted for is the active one, but it would kind of defeat the purpose of having multiple things within the loading range work all at once. I haven't messed around with writing plugins in KSP but there is indeed a list of existing vessels, which is necessary for things like persistence.