Jump to content

SiliconPyro

Members
  • Posts

    465
  • Joined

  • Last visited

Posts posted by SiliconPyro

  1. 3 hours ago, linuxgurugamer said:

    Very nice.  One suggestion:  You have A & D for left and right, now about making S vertical?

    You know, I did for some time and I think it was accidentally removed during a code refactoring.  Thanks for the suggestion.

  2. 1 hour ago, Shpaget said:

    The rescue counter doesn't increment. Or I'm running them over.

    Gravity seems a bit strong and quite selective.

    Otherwise, not bad. Keep at it.

    You have to reach a checkpoint and drop them off.  That will be explained in a future update.

    Not sure what you mean about gravity being selective.

  3. Redjoker is 100% correct. If you program your Teensy to act like a standard joystick with the fader as a throttle, KSP will have no problem with it.

    Since I have also have been thinking about building one, I kept looking at the thread and this mod appears to be the best way to do the software side of custom controllers if you are using an arduino. http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2817-Dec%29

    This plugin is unnecessary if all you want it a new input device, but if you want to get clever with your controls, like using toggle switches or even getting data from KSP and presenting it on a display built into the controller, then the hardware plugin is perfect.

    Please update us on your progress. There are a lot of us working on dedicated control devices.

  4. Right now, when you place your mouse over your craft's path, it just shows you a little dot where you can make a maneuver node. It would be helpful if it also showed you a little more information, such as your projected altitude and speed at that point. In addition, if you have a target selected it could show your target's position on its own path, so if you are pointing to one hour ahead, it would show where your target will be in one hour.

  5. Seems to me that the optimal solution, assuming you haven't just flown straight up thus requiring 1,500 m/s to circularize, would be to set a maneuver node at apoapsis, note the est. burn time, then start your burn at 1/2 that early. Keep your nose on the node while doing the burn.

    Seems simple enough, but I don't know if maneuver nodes really calculate for efficiency. It would tell you how to burn to keep your apoapsis below a certain altitude though.

  6. Say I have a rocket with poor acceleration. It has staged its primary lifting stage and is in a sub-orbital trajectory with an 85km apoapsis. My intent is to keep the apoapsis at 85km. Is it more efficient to start my circularization burn as soon as I reach 70km and steer below the horizon to keep my apoapsis from rising, or burn later and risk passing the apoapsis during circularization, possibly requiring me to steer higher?

    Obviously a circularization stage with a higher acceleration is ideal, but in this case, I'm just wondering what the most efficient option would be.

  7. Here's a solution: Export your UV layout in SVG format. The option is on the bottom of the window when you click to export. You can import SVG as paths in GIMP, and paths allow you to create precise selections which you can then bucket-fill.

    Follow these steps

    1. Export SVG UVs

    2. Open the SVG with Inkscape. Select All. Click Path->Union. This absolutely necessary otherwise each triangle will be imported as a separate path.

    3. Save the SVG file.

    4. In GIMP Import the SVG in the Paths window.

    5. Click "Path to Selection". Click Select->Grow. 4px is about ok. This is necessary because of filtering artefacts, when you zoom away from the model in the game.

    6. Fill the selection with the colour you want.

    You can also use your own custom UV islands if you want, all you need to do is make sure that only the relevant triangles are selected when you make a union in Inkscape.

    Another way of creating custom UV selections is to only export the relevant UVs from Blender, by only selecting the relevant triangles in Edit mode, then exporting the SVG UV layout.

    EDIT

    By the way another perk of using SVGs is that SVG is a vector format, and that allows the lines to stay between pixels, which is exactly how it should be. Raster UV layouts create a 1px offset. It's a small problem which becomes bigger as your texture sizes become smaller.

    I need to go home and try this right now.

  8. Unfortunately, no. It's the decoupling that ejects the panels. Just like with the engine shrouds, that attachment node has to disconnect to trigger them to separate. In terms of the visuals, this makes sense anyway, since the panels are the supporting structure for whatever is stacked above it. If the panels detached without decoupling at the top, you'd have a rigid "invisible" attachment between the top and bottom sections of the rocket. :)

    Now, if you did some sort of part-clipping thing where the fairing base is the only thing attached to your rocket directly, then you could do it. But that would require placing something at the top of the fairing in order to make the panels appear in the first place, and that would probably be somewhere inside your ship when you decouple the panels. That's probably not a good thing.

    Right, that's about what I figured.

×
×
  • Create New...