swamismurf

@Silisko: Does your folding antenna come as two parts? An antenna and a folding base, or are they just one object? If it\'s like your landing legs, I assume just one object.

The potential for a mobile/multiplayer P2P version of KSP is here in this plugin. MUDs used to do something like this back in the day for cross-system connects. This is a really rough idea of implementation. Rough. KSP Multiplayer Module: A part which when attached to a ship: 1/Second as connection permits, updates the locations and parameters of all vessels and parts. 10/Second updates the status of all parts on the currently focused vessel. TX behavior might have to be adjusted to keep the connection from being saturated. If module can remain active even when 'packed', then you only need one. If it does\'t remain active when packed then you need a part for every focuasable ship, along with an 'is_focused' flag. If Alice leaves a focuseable tagged ship, then the M/P updates stop happening, as if Alice went offline. An online/offline message must be transmitted to all connections. All of Bob\'s spawned ships are now on rails. When Alice reconnects, Bob\'s ships are updated/teleport to their current locations. The code must be smart enough to only transmit one set of updates, no matter how many copies of the part exist in the world. You would need a local 'receiver' module to update all parts when it RXs updates. The same limitations above apply to the RX behavior as to the TX behavior. There should only be one per player active. The M/P module must be able to spawn non-existent ships and debris in their locations and orientations. It appends the name of the ship with the name of the player to make 'ownership'. Perhaps a UID would need to be appended to the end of the ship name to prevent collisions. The name would look something like this: {ALICE-'SHIPNAME'-UID} The name would be parsed internally by the plugin and mapped to the appropriate ship. What stops a player (ALICE) from screwing with another player\'s (BOB) ships? Nothing. Two copies of a ship actually exist, one locally on ALICE, and one on BOB. When a player switches to another ship not owned by her, it can diverge and a new ship is spawned. Possibly colliding with {BOB-'SHIPNAME'-SAMEUID} because the ships are in the same location. Comedy ensues! What keeps time in step? I don\'t know. ALICE and BOB will definitely use warp. On one level, it really doesn\'t matter. The plugin doesn\'t care. The updates will still happen at the same pace. When ALICE uses warp, it will appear to BOB as if ALICE\'s ships have teleported in. Perhaps the module would need to do bookeeping to force the position to update. Perhaps a 'ALICE_isWARPING' tag must be TX\'d along with 'ALICE_WARPRATE' and 'ALICE_GAMETIME'... Negative warp-rates may be required to keep in sync due to the significant latency in the connection. This one is a stickler. Perhaps the module must TX to a local cache which keeps a record of all transactions and interpolates between positions. If Harvester is developing some 'universal' time system, with fast forward and rewind, it might not be hard to implement. He\'d have to essentially do that for every transaction node. What about security? What security?

This is how we do in flight tweakables. Click on the part to open adjust settings window, adjust settings, commit. If one were to extend this and combine it with the ASAS or MechJeb, would modifying the KIP parameters from frame to frame force the ASAS/Jeb to update its behavior?

When we rotate a part, can we make it rotate an attachment node on the end? I\'m thinking of a folding stanchion to lower a cargo boom, or scissoring solar panels.

It must be like holding it in too long... just look at what it\'s done to his face!!!

I support peer-review and signing, and having a central location to find trusted modules.

I find the eyes to be somewhat disconcerting. It\'s like no-matter where you are in front of your computer, it\'s like he\'s not /quite/ looking directly at you.

It\'s because you lack the Kerman vision donut (similar to human\'s rods and cones, but totally unlike it in almost every respect) which allows you to see that this is a beautiful piece of art! >

Now that persistence will be implemented in the new version, I\'m wondering what sort of part modifications would be needed for automated deorbit? 0. Would custom part scripts still operate after disconnection if the 'operates after disconnection' flag is active? 1. Will scripts be able to tell KSP 'Don\'t unload me, I\'m not done yet!'? This would then allow the parts to remain active and perform their actions even if they are far away from the current craft. 1. Retro-thrust module: Can liquid engines now fire in reverse? Are solid engines the only ones that can be made into retros? 2. SAS (the moment wheel kind) does not appear to function, even with ActivatesEvenIfDisconnected = True. Or am I on crack? Do some experiments! 3. Same with ASAS and RCS. Why do we need SAS? If the rocket part we want to recover is tumbling, there is a small chance that when we fire the de-orbit stage it will be pointing pro-grade, boosting it to a higher orbit, instead of to a lower one! Therefore, we need to force the part to an orientation suitable for the retros.

More Fuel = More mass. More mass = Lower Thrust to Weight ratio. Lower LTW = less delta-v overall. In rockets, smaller is better.

By Unity, I meant KSP\'s connection implementation. I stated: 'Divide all masses and thrusts/moments by 10.' this means all force/resistance type numbers should also be divided by 10. Until Harvester implements some type of connection fix which would allow massive tanks (perhaps the connection size variable would control this behavior) this might reduce the 'part dancing' enough to allow players to keep building bigger rockets with higher delta-v budgets.

I\'ve been thinking about the problems caused by heavy rockets and the much more 'realistic' fuel tanks by the modders. The problem, as I see it, is that the parts are too heavy for Unity to deal with. The solution is simple. Divide all masses and thrusts/moments by 10. You could then have 10 times more fuel/engines/boosters without the parts pogoing and melting. @Harvester: Mod the parts folder so everything is 1/10th its current mass. If you modify the original parts, then everyone else will 'balance' theirs to match and the problem of super-heavy collisions will be ameliorated. I\'m going to try this on all parts packs I download from now on.

Is it not more Kerbal to know such ephemera ... and disregard it?

Inquiring minds want to know: What is the Mun\'s surface gravity? What shall be it\'s diameter? This is critical information for mission planning purposes!

I\'ve had an idea for a collection of parts uniquely designed to eventually land (and take off from) Egar. I have no skills with Blender, Maya, etc. I do have skills with Autocad and have cranked out a rough model in an attempt to illustrate what I want. I am looking for collaboration with a pro modeller on this project willing to convert my Autocad model into a KSP dae model. This means I will need assistance creating a UV map as well. I\'ve attached the model as a DXF, along with an image. PM me if anyone is interested.