opensesame11

CKAN still thinks the most recent version is "KSP_Version" and when it tries fetching that from spaceport, it asks for "KSP_Version" instead of "0.4". It's been ~24h so I don't think CKAN is going to fix itself

I joined the last day of April, 2013, because while I liked the game and the demo a lot, I couldn't resist having the Early-Adopter package (0.19) which entitles me to multiplayer, when they do add it, free of charge. - - - Updated - - - For me, the early adopters pack was why I bought it, but it was also the time where the game had just had some if it's biggest, most fundamental features added.

When you start working on the new output variables next year, can you also add SAS feedback outs for tranlate XYZ and Throttle (Throttle for mechjeb and whatnot)

Thanks for the help zitronen. I'll keep my ear to the wall about your next update.

Can you add a variable to the output stream for X rot torque, Y rot torque, and Z rot torque? I'm making a simulator cockpit thing and want to have XYZ torque indicators like inside the game cockpits or the bottom left corner of the screen that shows trim. The problem I have is the arduino can output the joystick input but if I turn on SAS, the indicators will stay blank. Just a request; Ignore it if have better things to do.

The crazy-stupid thing about this is a lot of that has been implemented into mods. It's possible, so why not throw it into the game. The only issue with them is that mod-makers cannot make all their mods inter-compatible and it doesn't really fit all too well with KSp, but that's what game devs are for. Felipe, why not just send out emails to Ferram, Majir and whoever made the realistic Kerbin Mod and ask for the rights to sell their content. Honestly, I don't think they'll have too much issue with you making money off their work if it'll make the game better, because that's why they make mods.

Honestly, if you have ANY mod making experience, please help Christopher Andrews crank out DMP version 0.16. These are the issues that need solving. https://github.com/godarklight/DarkMultiPlayer/issues/207 All the network communications backbone is in place, and what remains is really just bugfixes and optimizations, though mostly getting permissions, groups and resource sharing is what we need done. Fix docking - Possibly use lock-system to make sure dockings are deterministic. Fix a rotation bug, Likely a difference in vessel.terrainNormal. Fix the vessel altitude positioning bug, Needs vessel.PQSAltitude as the PQSTerrain does not seem to spawn accurately enough for our needs. EDIT: PQS seems to be mostly fine, something strange is going on here... Profile DMP to see if we can reduce lag. If possible, find an alternative to KillVessel/LoadVessel for vessel part replacements Fix KillVessel from hanging the tracking station if we kill the selected vessel. Clicking on a player while in flight should target them, clicking on them in Tracking Station should ask to spectate. Groups. Vessel permissions. Shared career mode (#164). Fix the EVA-Board hijack (#200) Fix the Docking to a future vessel bug with a warning first (#161/#120) - And if they dock anyway, Jump to the latest subspace, if the parts are the same, allow a docking. If not, eat it. Clean up the warp system - Use LockSystem for voting, skip inactive votes, Fix "Kicked for creating subspace" (#67/#68/#71). IPv6 support (#76) Plugin documentation. Secure player tokens server side, which means SHA256 hashing them at bare minimum. We might have to leave the token idea for security completely and go for public/private key pairs. GUI overhaul

If they implement damage to parts, I'd like to see the cabinet doors break open in IVA mode... All those snacks in the PPD-10 Storage Container. mmmm

If the KSP devs don't mind working with yet another mod developer or just take a hint from them, the Fine Print mod effectively doubles the immersion and complexity factor of the contracts system, adding atmospheric exploration goals, space station construction and extending the game from grinding points to actually doing things you'd normally do. Also, could they try to make the Mk3 parts have the same functionality as the SPP parts? A quick retexturing would bring it up to speed, and LF+O, Monopropellent and LF tanks would be easy enough to implement. The only issue I see it the difficulty of integrating probe cores, docking ports and cargo bays to the Mk3 system. It would be great for those who would like a little more room in the cargo bay and round off the spaceplane parts suite. Probably the most important thing that I'd like to see in the future is a working IVA. The ability to process samples and actually do things inside the vehicle would be the best thing since EVA was introduced. The proper storage of collected samples and such would greatly improve game immersion (which is at an alltime high already) as well as allow kerbals to move experiments via the new transfer function as well as access the transfer dialogue by exiting the craft from IVA dialogue. This is what I'd like to see, but I see some really good ideas, too: Fuel Cells sound cool, and when are you guys going to tease some multiplayer functionality?

I made a plane and it's pretty manoeuvrable, and it takes off at 20m/s and has a glide range of well over 150km, so I thought, why wouldn't it be able to land on a runway twice it's size?

Here's the formula: Startingweight=(e^(deltaV/(Isp*9.81))-1)/(9-e^(deltaV/(Isp*9.81)))*payload*9+payload Subtract payload to get the weight of the fuel apparatus. Divide by 9 to get the mass of the empty fuel tanks.

Yes, I'm aware of Kerbal Engineer and MechJeb, though while they may be dynamic, you have to guess the amount of fuel to add and then check if you've fallen short, met or surpassed your target delta-v, where my tool (which would be useful mostly in the game, as the time to alt tab and start it up would outweight the benefits as opposed to Kerbal Engineer) will give you an exact amout of fuel in liters. In terms of usability, this isn't very good. It's a 20 some line program that I threw together because maybe someone else needed a calculator that does this. I plan to make it more user friendly, but the bulk of my efforts went to the mathematics. Any one can plug starting weight, ending weight and Isp into the rocket equation, but this gives you the exact number of litres you need accounting for the addition of fuel tank weight. A spreadsheet at this point in time would be essentially the same level of efficiency. My program uses a few std::cin s and std::cout s for io, so I could do better. I hope this answers your confusion. Please feel free to ask any more questions, because I'm not really good at answering them properly.

This is the first thing I've made for KSP, and I plan to make it into an addon, but for now, it's just a quick C++ program that runs off of the command line. It uses the rocket equation to tell you how many liters of liquid fuel you need to add to your craft to give it a target amount of delta v. This is useful if you want to drop extra tanks at each milestone, like a landing or escaping an SOI or something similar. Without any more hesitation, here it is. I don't think the temporary file host I'm using will keep it for very long, so I'll try to move it to SourceForge. Also, I haven't really tested it on any other systems yet, but since I made it in visual studio 2010 express, it will probably whine and complain of you don't have VC++2010 Redistributable pack, so download it if you get an error like that. Have fun with your new knowledge.

Are the subassemblies 0.22 compatible? I think that the game's new subassembly system might be slightly different.

Thumbs up for the suggestion. I hope it gets implemented in the future.

The easiest way to implement this would be to export code managing time and user input to a server which would spit out locations and attitudes to the clients. Of course the flaw is that the physics would be handled with the server, so this method is impossible until a multi-threaded physics engine is produced and would limit games to a LAN. You're right about that. I agree completely. Other people may see the need for a large multiplayer server, but I guess my mp gameplay image is radically different to that. I'd just use mp so I could help my friends out and run a collaborative mission with them in real time. Thanks Nutt007, I'll do that. In my opinion, asynch will never be a reality for KSP multiplayer because with asynch, people play in the same manner as single player but with time paradoxes and probably at a cost, because running a server capable of doing this would not be easy or cheap. Cooling problems could occur as well as bandwidth and CPU timeshares. Synchronous adds the problem of small playerbases and long waits for someone else to finish their long task, but it would be feasible with todays technology and is just like what Nutt007 said, but in realtime, so some people could use the same savefile at the same time. This is in the case of asynchronous multiplayer. Asynchronous mp really doesn't work for many games, and I've frankly never played an asynch mp game. Synch wouldn't be as free in terms of getting things done as quickly, but I think some chat system might be able to convince the slowpokes to finish what their doing so the final month of the Hohmann transfer could finish. I agree, it's pretty impractical, but when it gets released, maybe people will want to play with their friends bad enough to endure the waiting, but that's just me. About the what not to suggest, no one started this thread asking the devs to start working on multiplayer, this was a discussion regarding the mechanics of a multiplayer system and the pros and cons of other systems. You probably aren't going to read over this so I'll re-cap: Synchronous is manageable by current systems and wouldn't take much rewiring to work, but users would have to endure time-warp problems, depending on how squad implements that. Asynchronous is either managed client-side, exactly how kerbal livefeed works, or managed server-side, requiring a logbook of everything everyone does and what happened to everyplayer every second, something that would take immense CPU power and Unity optimization for it to work.

Elaborate, please. I made a post about this in this thread and I think it's pretty airtight, so I really don't understand what you're talking about.

I'm a total noob (1st post, woo), and maybe my opinions aren't as just, but maybe it could work like so: Rocket Control: If a rocket is launched, control is only given to that player until said player opens control of that craft to the public (or a white-list) and enters a spectator mode/goes to the space center. Clogged Space Centers: To keep them unclogged, the server would create one per player that joins somewhere on Kerbin to a maximum of *insert number here*. Let's say for this example, 64. You may end flights at another space center, but landing there or occupying that space at the same time the owning player of that runway/launch pad rolls out a spacecraft, your craft is effectively recovered/destroyed and the player's creation is spawned. Possibly, a countdown timer is presented to both players and the person launching a craft can choose to abort loading because they wouldn't want to see the craft at their space center destroyed. Time Warp: This issue is effectively solved in the Introversion game, DEFCON: Everybody Dies. The basics of it is, if someone has a slower warp selected, that's what the server uses. Of course physics warp would have to be disabled because if someone has 100000x selected on their large Joolian mission and someone in a space plane selects 4x, that mission will surely blow up, but maybe these aspects can be handled by the server administrator though configuration files. Docking: Docking could be just like spacecraft control, but who will be left will be decided by a vote by the two players docking, or in the case of a draw, a coin flip followed by the looser proceeding to spectator mode. Also, docking should be limited to a white-list, like spacecraft control, just so someone couldn't just rendevous and grab your satellite by the tail and reenter it. Weapons: Macey Dean has showed me that, "Yes, it is possible to mash other people's ships to a pulp with torpedoes with a low part count ship." This possibility means that some *explicit* could sneak up on you and blow you up, but just like in minecraft, griefers are banned, and so are weaponizers. Maybe just like Kerbal Livefeed, a live picture feed, updating roughly every 5 seconds is made between all ships so people can sense incoming doom. In the event that people would like to have a real-time war in KSP, the livefeed system could be reconfigured to only allow feeds between teammates, defined in the savefile. Possible referring to the cluttered space centers, each team would get closely spaced space centers so they could coordinate launch attacks. Maybe even a voice system could be implemented, or teamspeak could suffice. Generally, in my eyes, the multiplayer functionality of KSP shouldn't be engraved in stone, and just like the conics system in the KSP config file, people can change it to their needs and their friends needs and have KSP multiplayer behave how they like it, that way everyone's happy. (Then again, not everyone's happy)