jsalexan

Fair enough on not redistributing. I don't redistribute code anyway without permission simply out of respect for the authors. I hadn't thought about the support aspect very much but now that I think about it, I'll try to step up more when somebody on the forum puts in a request for help and maybe that will help take some of the load off you guys. Anything I do to the code stays with me unless it might be useful for somebody else, in which case, it's submitted back to the original authors for inclusion into the primary codebase IF they think it's a good idea as well. At no point should forked code be generally available unless no other choice is given (MIA author, etc). It's up to them whether or not it's useful enough to include. Fair is fair and the credit belongs to the authors because what ever I'd do to it is derivative at best anyway. Besides, when I write something, I'm not looking for fame, I'm looking for a feature and it's generally because I couldn't get it any other way. I don't care whose name is on the final product as long as I get to play with it

I can certainly grab Kevin's updated source, it'd give me a good excuse to override the copy I was digging at trying to get this exact thing to work with something that will definitely work. One question: can you use decimal seconds like .25 if you want it to move into place in a quarter of a second?

Yup, this is the awesome I've been waiting for. Any chance of getting a prerelease for testing of the integration?

This is the piece I've been waiting for, I'm going to throw out the half-baked implementation I've been working on to keep myself occupied until you came out with the real deal. I'm definitely looking forward to this release of IR!

I'm brainstorming and trying to discover avenues that can be explored that will meet as many of the possible use cases KOS could run into. Here's what I've dreamed up so far, it's loosely based on a couple of networking protocols like IPX and TCP/IP and how a OBDII car network works (including OnStar or alarm gateway to an outside controller if you're into that). KOS-NET Protocol <-- Right amount of description, probably not kerbal enough but will do for a working name until somebody comes up with something better. Definition/Specifications Version 0.00a Supports network, part group, part class, individual part and method registration via broadcast to all KOS enabled parts inside the current vehicle. Every KOS part has the capability to be a network client and controller in one, that way if two vehicles are created from one and they both have KOS on board, they both will have a viable network. Supports basic stock part class integration - possible inheritance based new part class that would act as a drop-in replacement for existing part classes to add KOS support. Template for other authors? Most users aren't going to be interested in addressing every docking light of their orbital shipyard individually. They're likely to be interested in addressing things as definable groups or by type. Grouping and naming of individual parts in the VAB/SPH that stamps a field containing the group name onto the part instance - is this possible? Supports rudimentary routing between different vehicles via doing a sendmessage to another vessel if somebody wants to write the distance/time delayed router code. Stock and stock derived parts wouldn't have the full KOS functionality but there's no reason they couldn't be made to work. Broadcast network simulated via Sendmessage is still the most viable message passing protocol because it just sends to all parts and doesn't care about things like part IDs. Every part with public methods already supports sendmessage so less work is required to get things talking and more can be done to figure out what they need to talk about. When KOS boots up or on part dock/detach/stage, it would broadcast a registration command to all parts inside the current vessel ID, they would respond with their payload including vessel ID. Supports remote part discovery because the discovery command contains the originating network for the discovery request. Once routing is working, the rest falls into place. KOS enabled parts register themselves by class, group name, name they'd respond to, type and method calls available (DHCP/DNS analogues) every time a network init broadcast is detected This network model sidesteps the issues with traversing the entire part tree every time you need to refresh the parts list and the parts list being essentially a list of random IDs. Internet-like resiliency to the vehicle network so when bits are docked or fall off (on purpose or accidently) the network can reshape dynamically without a lot of overhead.

I like the idea of registering with KOS but it may be a more interesting ride than you might think. I've taken apart enough of Infernal Robotics (to use my favorite example) to know that it maintains its own internal list of parts that it uses for its servo groupings. When you click a GUI element the event goes to the DLL which looks up the parts and starts a physics change on each one of them. It's pretty slick and perhaps some of the coding techniques can be borrowed for this project as well, perhaps store a master list of API functions in a list alongside the actual method calls and part IDs. The gotcha with addressing parts individually is that sometimes you want to address more than one part at once The gotcha with SendMessage is that it's a broadcast over the entire gameobject, so technically all parts will "listen" to a sent message but only the ones that implement a given method will actually do anything about it. The reason for all this foofaraw is that IR, for all its ability, stores its own part grouping independent of the game. To my knowledge IR is the only mod that does things this way but it's an interesting approach that addresses a lot of limitations in the core game and more mod authors may pick up on it if there is sufficient complexity in their mod that they need it. IR Servo Groups are different than KSP Action Groups and are only addressable via the IR plugin DLL method calls that every part instantiates. It may be possible to just enumerate the parts and then get the methods off each part and then call the individual parts to get the rest of it and build a tree internal to KOS. I'll have to do some playing on that one.

Kevin, I've been looking into this pretty deep because I REALLY REALLY want it to work with infernal robotics. TLDR; Version: Create two things in your code: KOS-Vars(key,value) adds or updates the key value pair in your variables collection alias the script processor "tell" command to unityengine.sendmessage(methodname,message,value) You're done. The rest is up to the other plugin authors to implement. They'd need to implement the public method your code would call with 2 parameters per the sendmessage documentation. They could set values via calling unityengine.sendmessage ("KOS-Vars",key,value) Longer wordy version: What could be done would be to send a message to the root node (these propagate downwards to all other elements on the vessel). the message could consist of a string containing a group address, a command and a value. You would simply implement two routines: a method to do the sendmessage broadcast to the entire vessel and a callback routines that would take variable name/value pairs and turn them into internal variables. This command: Tell "IR-Interface" "Group1/MOVE" -5. Calls: UnityEngine.SendMessage("IR-Interface", "Group1/Move", -5) behind the scenes http://docs.unity3d.com/Documentation/ScriptReference/GameObject.SendMessage.html Then it's up to the mod creator to implement an "IR-Interface" method that parses the command string and moves group "Group1" to current position -5. If a plugin doesn't support your event, it's ignored. Any mod developer that implemented an IR-Interface using the same format of commands would be controllable via this method. The IR-Interface would do a sendmessage to "KOS-Vars" telling it "<IR>Group1Value" = 14 This method would be useable, expandable and would not require much coding on your part at all and by creative use of enumerator strings you could Tell "IR-Interface" "ListGroups" "IRGroups" and get a message back of "IRGroups" "Group1/Group2/Group3" on your KOS-Vars Interface The downside of doing this is that there would be nothing stopping you from calling any public method on any part so you may want to lock out the built in part commands. Tell "explode". ENTIRE ship blows up Tell "Activated" 1". Everything on the ship activates One good thing is that you wouldn't have to worry about getting addresses for specific parts, the downside is that unless the part plugins themselves kept a list of their own and provided that in the interface (Infernal Robotics does), you wouldn't have any way to direct commands to only specific parts. This is actually the method I'm going to try to hack together this weekend on my own just to see if I can. If you're interested in anything that comes out of it, I will PM you the code for rewriting to get the spaghetti out and include it in the core codebase. If I can get it to flash the lights on the ship on a timer in a loop via this method, it'll count as a working proof of concept and I'll then try to somehow bribe sirkut into implementing a command handler on his side (or take a stab at it myself for my own use) at that point. It should be fairly trivial to make this work from the KOS side. Jeff

He's got a dual simultaneous launch in one of his videos. I think the only limitation is that the two ships need to be in physics range of one another. This will be a godsend in docking if you can keep the remote ship's docking port always pointed towards your docking port.

List parts on vessel given the vessel object: Stolen from orbital construction codebase public static double DetermineMassOfVessel(Vessel v) { double totalmass = 0; foreach (Part p in v.parts) { MonoBehaviour.print("Part:" + p.name); MonoBehaviour.print("Mass:" + p.mass); totalmass += p.mass; //we also need to coutn the resouces in each part, and multiply that by density... but that can wait. double resMass = (double)p.GetResourceMass(); MonoBehaviour.print("ResMass:" + p.GetResourceMass()); totalmass += resMass; } MonoBehaviour.print("Mass of vessel: " + totalmass); return totalmass; }

You may not even need RT for that, it could just see if an antenna is in range of the currently selected ship and if it is, how far away it is and if it's connectable. Calculate your delays and set a timer in the remote kOS to switch to that remote ship and execute the program. You'd need to do this to ensure the ship is loaded into the physics engine. Would get interesting if you're in the middle of a landing or something when the switch unloads your current ship out of the engine though.

I was looking a little at the RemoteTech code on GitHub. There's a couple of public interfaces in the plugin that might be of interest to send commands to. At first glance it looks like all that needs to be done is to include the RT antenna parts in the internal list of antennas. Just query the existing RT interface for ship in range and that sort of thing. Remote programs would have to set up their own time delays prior to run I think but it could be done.

Payload, To respectfully disagree with your statement about kOS interacting with Infernal Robotics: interacting with an action group is not quite the same thing as interacting with Infernal Robotics. toggling action groups is nowhere near the same thing as setting a direct value or incrementing/decrementing a value buffer by a set amount. It's close, and an awesome mod in its own right and one I'm watching very carefully because it makes a lot of things like autonomous probe networks and multiple launch base missions, automated kethane mining outposts, etc possible above and beyond its robotics applications. This is one of those mods that I'm really excited to see and I'm looking forward to making some amazing things with it!

Here was my attempt at a walker. It's got the same drinking problem yours does with the addition of I have to move in really tiny increments otherwise it likes to dive face first into the ground. I'm hoping that kOS becomes compatible with Infernal Robotics soon so scripting complex actions in the robotics goes way beyond action groups and praying things don't fall over.

Here's a walker I was playing with earlier. It has a 1 meter (ish) per second walking speed and can make 90 degree turns via gyro bending of the frame in as little as 50 meters. A proof of concept but at least it's a walker. I love this mod! Thanks Flikr for not letting me embed. http://www.flickr.com/photos/101031351@N03/9631747881/

Holy moly, this is a cool mod! When you get the outstanding bugs stabilized I'd also like to add my voice to the allowing of RemoteTech integration and add on another twist: Maybe create messages to be sent directly to an installed plugin's event handlers similar to what you're most likely doing to access the game interface directly. From a coding perspective something along the lines of: Activate MJ. Activate IR. MJ Smartass Surf(90,90,0). Target "Jool". MJ Maneuver Hohmann. IR HydraulicLifter1 Increment -2. IR HydraulicLifter1 Set 40. Set X=<IR:HydraulicLifter1>. Just some thoughts to hopefully inspire you to greater integration with other mods and bring some serious awesome (even more than it already is) to the game.

The bearing with a solid center that doesn't move so things can rotate around a central core is one of them, the other idea is very similar to the snake robot thing, but doesn't need as many bending directions (just one direction should be good enough but more would be cool) As for the other idea, grab a plate, stick a motorized hinge on it and then another plate. that's the basic concept. Make it taller to bend farther. For my instance, I only really need it to bend 20-30 degrees maximum off the center of the vertical axis. I did some playing in KSP to try to simulate it. It might be simplest to call it a ball joint, bender or just a really big hinge What would be really cool is if you could program each pivot to be a set number of degrees (from 1-30 say) and have two states, normal and bent.

I'd like to add my own heartfelt hopes for this part as well. I've been looking for this exact part for some time and if anybody can pull it off, its you two. Thank you both Devo and Sirkut for taking this already incredible mod (damned robotics) as a starting point and turning it into something even more incredible, useful and up to date! if I could add one other part request, it'd be a pivot that worked exactly like one of your existing powered hinges internally but within the context of the usual part sizes and a cover. Useful for launching vertically straight and then "bending" a stack in space. If it were limited so it could only bend as far as the plate could turn (depending on internal pivot height), so much the better. For a working example of what I'm suggesting, take two 2 meter plates, put them on the top and bottom of a motorized hinge and imagine that they're round and have a stretchy covering around the sides to make them look like round parts in stock sizes.) Regardless of whether this idea gets implemented or not, this mod is a tremendous addition to the game and I appreciate all the effort and hard work you've both put into it.