Quinton

Hopefully I\'ll have some time to update this further this weekend and address a number of useful pieces of feedback I\'ve gotten from folks here. One thing my collaborator (who did the modeling) was interested in was building openable doors that the panels would be folded up behind during launch. We\'re not sure if we\'re going to try to do this as multiple pieces (might be more in the spirit of reusable KSP components) or a fancier all-in-one part. Things I learned about working with multiple colliders: 1. The game only converts one mesh (named 'node_collider') into an actual collider. The game renames this mesh to 'collider'. This happens sometime before your onLoad() method is invoked. 2. It seems best to not name other meshes 'node_collider...' as we ran into some odd issues with some nodes going missing (though it may have been pipeline issues with getting our DAE out of Lightwave). We ended up naming our sub-collider meshes 'boundbox...' so we could recognize them by name. 3. if you\'re going to animate things, it\'s convenient to have the colliders be children of the meshes you\'re animating, so they 4. the fixupColliders(Transform t) utility function here (http://code.google.com/p/f13aerospace/source/browse/trunk/F13Utils.cs) walks a Transform tree and any node with a name starting with 'boundbox' gets converted from a renderable mesh into a collider mesh. 5. In onPartUpdate() you can apply local transforms to adjust the position of the children based on input (this is hacky, hardcoded, and always active -- going to clean this up soon) - http://code.google.com/p/f13aerospace/source/browse/trunk/F13SolarPanel.cs Anyway, hope this is helpful. I really need to figure out how to set up the drag model right and adjust it based on the panels being deployed or not -- my goal is to ensure if the panels are deployed in atmosphere they get torn off in a horrible and hilarious manner.

That\'d be handy to document. Quickest way to find out would be to put some print()s in each method, try different paths (launch game, go straight to launch pad, etc), and check the logfile for what order things happen in. I\'ve noticed some of the methods seem to get called multiple times, etc, as well, but haven\'t checked to see if that was for multiple instances of the same part, or what.

I think the nicest way to handle plugins/parts/etc would involve an actual change to the game, but if the developers are in the mood for a feature request or suggestion, mine would be: Game looks in the Addons folder for any .zip file, which may contain Parts/... and Plugins/... paths. Adding stuff to the game for the enduser becomes 'download cool-stuff-addon.zip and drop it in the Addons' folder, and removing it becomes as easy as deleting it. Or, to get extra fancy, an addon.zip file may contain an addon.cfg which has information about the addon (author, version, description, etc) and UI could be provided to see installed addons, disable or enable them, etc.

It\'s still *really* rough -- not sure it warrants an announcement on the plugin release subforum yet, but if you want to take a look at the source or try it out, it\'s here: http://f13aerospace.googlecode.com/

In onPartLoad() I\'m walking the Transform tree and any node name starting with 'node_collider' I create a MeshCollider for and delete the MeshRenderer from. The game seems to do this automatically for the one node named (exactly) 'node_collider' and it renames it to 'collider' at the same time (at least that\'s the state everything\'s in when my onPartLoad() is called). The good news is this seems to work -- my unfolded solar panels will happily collide with objects. Next step, I want to figure out how to adjust the drag so unfolding them while in flight becomes a really bad idea (ideally they should not survive the event, being torn off the craft). When folded up against the side of the ship, they should add some, but not a catastrophic amount of drag.

Is there any example of a model with child objects for the collider? I\'m working on a Solar Panel Part that unfolds in multiple segments. The DAE has an attachpoint mesh which has a panel1 child, which has a panel2 child, etc. There\'s also a node_collider mesh with panel1, panel2, etc children. The game recognizes the node_collider and pulls it out (taking the children with), but the game is rendering the collider children, which is kinda weird.

It may be interesting to model one or more busses, where every generator or consumer of energy specifies which bus it\'s connected to by name -- and some components may be able to be toggled between busses or plugged/unplugged via a 'breakerpanel' UI of some sort. By default components use the 'A' bus (to keep it simple), but that could be overridden in the part.cfg or dynamically. Over time available generation may depend on things like: - is the Sun obscured or not (Solar Panels) - how old is the component (Batteries, RTGs) Attempting to inject more than some specified limit of energy through a bus could result in a blown breaker or a Kerbaltacular electrical fire or the like... Attempting to draw more than the available energy through a bus probably results in all components on a bus suffering. Energy sources or containers may be able to produce only so much instantaneous energy -- solar panels maybe insufficient to power your IonEngine with a Battery to buffer things, and a single Battery may be able to provide only so much instantaneous energy, etc... EDIT: I\'m working with a friend getting some fancy unfolding solar panels put together, but once we\'ve got that working (modeling side is looking good, need to fiddle with addon code to unfold the panels), I\'m going to be interested in actually rigging the panels up to the electrical system. Hoping to have a bunch of time to hack on stuff this weekend.

In keeping with the finest Kerbal Engineering Practices, allowing three or five entirely different autopilots to vote (or perhaps argue) over the correct control inputs seems reasonable...

Maybe step back a level and associate a set of key/value pairs with each Vessel that Parts could use to coordinate state (this is probably a good feature request for the KSP developers for future versions, but could be mocked up now).

I\'m just talking about the list of exported class names / method names / parameters (which is all the VC# object browser shows) -- basically what I\'d find in the header file in a C/C++ project. It sounded like the concern was about decompilation and the like and I certainly understand that being considered off-limits, but if I misunderstood, apologies. I\'m happy to stand by whatever rules the developers and moderators want here. It would definitely be helpful (for avoiding breakage if nothing else) if there was a list of which classes were considered part of the 'public' addon API as it were -- presumably Part and some other stuff, which you have to extend to implement new part behaviours. I assume that everything is subject to change as it\'s early yet and things are in heavy development, but guidelines are always helpful. EDIT: I\'m blind. There are pointers to some getting started wiki articles (setting up VC#, building a basic do-nothing plugin, etc) in the Posting Rules stickied post. EDIT2: Deleted some posts asking about things clearly pointed out in the rules thread or the wiki pages it links to. Sorry about the noise!

For other programs on the same host, unless you\'re completely spamming the network stack, UDP will tend to be both reliable and in-order. Non-congested switched ethernet and wifi are pretty reliable too, but dropped packets can happen. If you keep one telemetry message per packet and give them a sequence number or timestamp, it\'s not hard for your groundstation to sort them on arrival if necessary. Last time I used UDP for telemetry was on an autonomous vehicle for the 2005 DARPA Grand Challenge -- entirely too much fun even though we didn\'t put anything in orbit. alphafalcon: I\'m still getting up to speed on C#, but I suspect that like Java you can get some kind of unique hashcode or ID for an object -- so if you sent both the name and the ID of this.vessel, you\'d be able to disambiguate if necessary.

I\'d be tempted to use broadcast UDP for telemetry data, if the C# network APIs allow that. Then you don\'t need to worry about connecting, disconnecting, etc. You just have your 'Groundstation' or whatever open a UDP broadcast socket for listening and it\'ll receive all your telemetry from all active instances of your module... can modules discover what ship they\'re attached to and get the name or a unique ID of some sort?