Peppe

I like this mod to remove tech tree from career mode, but have the experience, contracts, money: Tree Toppler

Direct3d is under the umbrella that is DirectX. DirectX has a whole bunch of non graphic API as well to support 2d/sounds/input/etc. Everything under directX is a microsoft product so designed and built only for windows. Wine tries to map directX graphic api calls to opengl. The Unity engine the game runs in has support to run openGl directly, so I would not bother with Wine. If your graphics drivers are up to date the main bottle neck in the game is CPU. What are you running?

Congrats on the release. Look forward to the new innovations and your support through all these versions is admirable.

Haven't had a chance to play 1.0/1.0.2 yet, but noticed this thread and the payload challenge thread and wonder one thing... How come there is doom and gloom on the SSTO/Spaceplane front while rapiers and jet engines are punching in close to or above a 50% payload fraction in the challenge thread. I know the speeds and top altitudes have changed, but surely there is room to take the lessons learned in that thread and make a 30-40% payload space-plane. Payload challenge thread: http://forum.kerbalspaceprogram.com/threads/116729-Stock-Payload-Fraction-Challenge-1-0-2-Edition

No problem. There are some liquid fuel only tanks for jet engines and the nuclear engine. They don't require oxidizer.

That tank in the later stage looks like the liquid fuel only. You want a tank with oxidizer as well.

I found this mod from the combo package in the MKS/OKS thread. Was not 100% sure from the config file, but it looks like 10MW karbonite generator converts to 25 electric charge second? Tested in game and that seems right using consumers I know use 15 Energy a second. The mini drill seems to be consuming the wrong amount. Says it will use .25 MW and consumes .25 electric charge, shouldn't it use .625 electric charge a second? Assume it is in a different unit than electric charge for a reason maybe I am missing a mod that helps track consumers + producers spread across a ship. Reading up on the units more seems like it is common in KSPI reactors.

Congratulations on the full/public release! The pre-releases were all working well for me, so i'm sure the full release will be fine for most users.

Wanted to say this mod manager is pretty amazing. I have been using it since the .24 release and it has made it easy to stay on the current/latest version. It all works smoothly with some minor issues usually on the mod hosting side, but overall the tool is simple and easy to use. The planned features look great as well. Would it be possible to have an option on github sources to download pre-releases? Example: scansat project: https://github.com/S-C-A-N/SCANsat/releases remote tech: https://github.com/RemoteTechnologiesGroup/RemoteTech/releases Obviously need to be an informed user to use a pre-release, but if you want to test/use the bleeding edge it would be nice to have that option. You have a great first release!

This sounds more like the part failure mod, http://forum.kerbalspaceprogram.com/threads/85798-0-24-1-Kerbal-Mechanics-Part-Failures-and-Repairs-v0-4-Help-Me-Balance! . I have not tried it yet, but would interesting if it's 'rocket parts' used for repair could use RoverDudes's repair/maintenance system. To balance resource systems you would probably need to make the fuel cost on kerbin super high and not have any of the resource available on kerbin. Then the player's incentive to seek out and produce their own fuel is to reduce their mission cost.

The numbers for the kerbin universe are on each wiki page for the planet/moon: http://wiki.kerbalspaceprogram.com/wiki/Kerbin How accurate is the real solar system mod? Not sure if you could use real world numbers or if they would have some of these numbers calculated already and posted somewhere on another wiki. You might try these numbers, but again the real solar system mod may be scaled in someway to work in the KSP engine: http://en.wikipedia.org/wiki/Standard_gravitational_parameter

Just started using this for .24 and it is excellent. Easy to use and just works. Thank you Llorx and all your contributors. One question, some mods say to delete their previous folder before installing. Does this mod delete the folder as part of it's extraction or should I have been manually removing the folders when the readme indicated it? I'm guessing it does not delete, so is there any easy way for me to do a re-download all?

That is for Remote Tech mod. If you don't use the mod don't worry about it. My calculation for it is +-3 degrees from the minimum safe separation between a set of satellites. Not sure it is truly optimal, but more a rule of thumb i tried to make for myself. I know i did not want the lowest orbit (drift -> failure risk) nor the max orbit (too much fuel cost), so how to find something in-between? My thought was, take 3 satellites equidistant to each-other -- with perfect orbits you could have orbits as low as the radius of the planet. For kerbin that is 600km. My orbits aren't perfect, so lets add some flex to the numbers. If we allow for +-3 degrees of drift on each satellite we could setup safe orbits ~720km that survive drift. The extra orbit height means the planet blocks less of our line of site to the other orbiting satellites increasing our time to failure.

Mode 1 and 2 being similar is a good idea. I think it will encourage using dishes with the right cone size for the job. Mode 3 sounds cool, but complicated and might make signaling too easy. Without a cone to worry about you could use dishes to relay a signal in much more flexible arrangements. Seems to negate the above, where now you don't have to worry about picking the right dish for the job. Sizing the dish and cone angle I think makes for an interesting game-play element. My mode 3 would look at a cone mode to fixed points around the body. Like poles and each horizon, so you can target the planet center (current mode) or the sides. targets (x) around body (o): -x- xox -x- Maybe enable the multidish range bonus by default. So if you need a cone angle of 25 degrees, but out 200Mm, you can do it with 2-3 dishes depending on how you scale the multidish bonus. Someone many pages back also thought being able to target the zenith from the surface in cone mode would be good. Not sure if the cone rotating on a surface might not update if the ship is inactive. If the mode 1 changes don't filter by the target, so truly anything in the cone will connect I think that will give us a way to relay through moons. If the moon can also talk to the ship and the planet, when it crosses the signal path it will not require a re-target to maintain the signal -- assume the ship's cone can see a relay sat around the moon? Assuming you have relays on all planets and moons, then moons will not block the signal. Only scenario that leaves to lose signal is something large like the sun/jool, where you might not be far enough away for your cone to hit a relay (planet or sat) without targeting away from kerbin. A dynamic way for the sat in this situation when kerbin goes behind the sun/jool to try to relay to a backup planet or list of backups -- until kerbin is available again might be good. Struggle to find a solution that does not make it too easy. If that sounds too easy maybe you just make the player bring a backup dish and they have to manually point to alternate relay path around the sun before they lose signal if they are worried about signal loss through the direct path.

Not sure how the KSP wiki is, but since this is a mod should most of the information be collected on remotetech's wiki rather than KSP's? https://github.com/Cilph/RemoteTech2/wiki/List-of-available-parts

I have not used KOS - kerbal Operating System, but i believe integration with it is the next layer planned for the flight computer. It would let you script advanced tasks to perform and KOS would perform them with local control. I believe it will work similar to what you are describing... if you play modded minecraft i imagine it would be like programming turtles in computercraft. If you already have a command group to activate the antenna, then you just set the delay for what you want. Say 5 minutes. Then hit the action group. Then reset your delay to zero and manually deactivate the antenna with the mouse. Probably doesn't feel logical, but if you have other actions to do during the entry and landing you can start far enough to trigger everything with one master delay. Say we setup a reentry 30 minutes out: We set a 28 minute delay Hit action group for parachutes. Wait/warp x minutes Hit action group/hotkey for landing gear wait/warp x minutes hit hotkey to extend antenna reset delay and manually retract antenna. warp to reentry Since we scheduled things with the same delay the reentry will open our shoots, then say 2 minutes later extend our gear, and then maybe we warped 5 minutes setting this up, so the antenna will extend in another 5 minutes. Basically perform the re-entry commands in space well ahead of your arrival with a delay and then shutdown the antenna.

You can do what you want with the existing flight computer. You can set a custom delay to queue an action group - expand flight computer and set delay in lower righty. Setup reentry, Delay the expand a few minutes, remove custom delay and retract anything that can break. You can test your craft to find good delays to use or over engineer a safe lander.

Sounds like issue 200: https://github.com/Cilph/RemoteTech2/issues/200 Targeting a body will only talk to satellites in line of site and orbiting that body. So something can be in the cone, but if it is outside the SOI of the target body it will not be communicated with. You might add your usage scenario to the issue and see if that might encourage a change in the code proposed by maxdreamland. I personally think dishes should only use cone mode no matter what they target, but maybe that creates a performance issue.

That whole section is new. Does not come off very clear. You are correct the far side satellites would not work with an eqalateral triangle, but there should be window where they can point at kerbin and see the sat over KSC. At any rate I would prefer lower orbits and all Omni's to cover surface to orbit comms. Dish's should point out... To moons/planets.

Here is a quick example of the affect of cone angle. Comparing one sat from each tier kerbin to minmus: If you are not using DTS-M1 or KR-7 for your moon to planet and back link you are probably have a very tiny window where sats can be to communicate. Minmus in the above shots is only 60Km. The 88-88 can see maybe half of minmus, but if you use the 88-88 to look back to kerbin it is 10x larger planet so the same sat will see an even smaller window/field of view of kerbin. You have to size your dishes for the job they will do.

Bugs all had to do with ID getting unloaded or not unloading when they should renaming never did anything.

What is the cone angle on the dishes you are using with planet/moon targeting? And what is the your distance to the target?

Sounded like that type of problem. Also the super long range dishes have a smaller cone angle than the game displays. I've put the values in their part files here: https://github.com/Cilph/RemoteTech2/wiki/List-of-available-parts The largest two dishes basically need to be about 10 times further out to see even half of kerbin using the cone targetting. ~10,000-20,000 Mm

Just to make sure, on minmus you are using the 50Mm or 90Mm dish? Any others will have a cone angle too small to see more than a small window of kerbin until they are 1000-2000 Mm out.

What is the issue with map vessel and focus? If it is related to 189, yes. If not probably not. https://github.com/Cilph/RemoteTech2/issues