• Content Count

  • Joined

  • Last visited

Community Reputation

34 Excellent


About c4ooo

  • Rank
    Rocketry Enthusiast

Profile Information

  • Location Night side of Kerbol

Recent Profile Visitors

1,586 profile views
  1. Does anyone know how to the the anomolies for the transitions between orbits in patchedConicsSolver's flight plan? Edit: To add on, I am programming an external orbit viewer. I can draw individual orbits, but I am not sure where to get all the required data. patchedConicSolver.flightPlan only seems to have the orbits created by maneuver nodes, not by gravity assists and stuff. Edit 2: I have figured out most of the orbit stuff I need to know, but I still can't figure out how to get the anomalies for the orbit patches ends/starts.
  2. New release! Firstly I've a "controller" widget, as well as support for USB Joysticks, allowing you to control your rockets: Secondly, I've small changes that should be pretty insignificant. In the future, I plan to switch from a window based UI to a divider based UI, and make the whole thing look more like an actual MFD, as well as adding more cool display widgets to make this a useful application! If anyone has tried this, please do offer some feadback, I want to improve it! (And I promise i'll stick around to see your posts )
  3. c4ooo

    Yet Another Remote Kontroller

    I hate to triple post, but it's been a while an I've made some changes. First of all, I have refactored most of the plugin code into separate files, and moved the MFD code into a separate repository. This should make everything easier for me to manage, and the refactor will allow me to add support for multiple client connections. when I get around to it. Secondly, I improved the protocol. Instead of trying to reexplain the protocol every time i change it, which probably has led to some confusion, I simply have created a set of Java and C++ bindings. The bindings come with an example script, and I think providing the bindings should make this plugin easy to work with. I have added some features to YARK, such as an "11th" SAS mode that allows the client to specify a custom vector to point the ship at. If anyone is confused by the helper methods in the ControlPacket Class/Struct, I will be happy to document them!
  4. Can I PermaPrune Squad default parts to speed up the game loading? Or will it not effect the loading times?
  5. c4ooo

    Realism in Stock KSP

    I think more "easter eggs" and land marks should be added to make exploring Kerbin and other planets more interesting. Not sure what those would be, but maybe caves you could fly through or something would be awesome. Also more realistic terrain like forests with dense vegetation that you could crash into would be awesome to see, although this seems technically challenging to implement, and not really relevant since this is a *space* game after all.
  6. I yoinked the code and it seems to work somewhat. However there are two problems I have with it. First of all, it seems to overshoot all the time, but this should be easy to fix by adjusting the values in around line 242. Second of all though, although Rolling and Pitching seem to work fine, adjusting the Heading makes the craft/navball rotate "straight" to the left/right instead of along an arc. For example, after setting my target pitch to 45, roll to 0, and heading to 0, the code orients the craft like this: As Increment target heading, I expect the craft to rotate along the green line, but instead it rotates along the blue line. Do you have any idea what could be causing this? I replaced the getReferenceAttitude(activeReference) on line 235 with Quaternion.LookRotation(north, east), where "north" points to the north of the planet and "east" points east. Edit: IDK why i always find solutions soon after I post about something, but I think this code works for calculating goalOrientation: https://pastebin.com/G8LABpbm
  7. Is there a good way to detect a "Revert to launch"? Neither the ActiveVessel.id nor the SceneManager.GetActiveScene().buildIndex seem to change.
  8. Yes! Sorry for the late reply, I haven't been active much, and apparently I am not subscribed to email notifications for this thread :(
  9. @Benjamin Kerman This is what i get when i tried rolling the vessel: (IDK why but Vector3d.ToString() makes it a rainbow...) https://i.imgur.com/fZkVZuo.png Next i tried pitching the vessel down (harder to do accurately then rolling) and got this: https://i.imgur.com/vOJGRm6.png
  10. How do i orient a craft's angularVelocity vector to extract the ΔPitch, ΔRoll, ΔHeading? Mechjeb does this to orient the attitude vector to get the pitch roll and heading: Vector3d CoM, north, up; Quaternion rotationSurface; CoM = Vessel.CoM; up = (CoM - Vessel.mainBody.position).normalized; north = Vector3d.Exclude(up, (Vessel.mainBody.position + Vessel.mainBody.transform.up * (float)Vessel.mainBody.Radius) - CoM).normalized; rotationSurface = Quaternion.LookRotation(north, up); Vector3d attitude = Quaternion.Inverse(Quaternion.Euler(90, 0, 0) * Quaternion.Inverse(Vessel.GetTransform().rotation) * rotationSurface).eulerAngles; However doing something similar but replacing Vessel.GetTransform().rotation with Vessel.angularVelocity results in what seems like meaningless numbers.
  11. 'Angle x 50' would be better do to ease of use I suppose. (The current ratio is Angle x ~91.0222, which isn't an integer as you can see :V ). Although if you would be fine with negative headings (range of -180 to 180), then you can make the ratio 'Angle x 100', and have a resolution of 0.01 degrees. As for the targeting planets issue: since the 'set navball mode' code also uses the "TargetExcists()" function, I assume it is not possible to set the navball to "Target" speed mode or set SAS to "target" mode if you are targeting a planet, not a vessel.
  12. YARK Multifunctional Display is a program that uses the YARK plugin to fetch flight through a TCP connection and display it on virtual instruments situated in widgets. This could be useful if you want to build a simpit with simulated displays or have an extra monitor. Below is a screenshot of an earlier build, the console is no longer eye-bleach blue :V Instruments are situated in "Widget" windows, which can be configured through a console, or by mouse interaction. List of Widgets: NavBall (navball) Attitude Indicator (ati-in) Air Map (airmap) Soyuz NavBall (soyuznavball) Configuring YARK-MFD The layout of the windows is saved in config.txt. The layout is saved automaticly, but the first line should be formatted as such to connect the MFD to the KSP server: connect <IP> <port> start.txt is read next, and contains a list of console commands that configure the initial layout of the widget windows and serves to save the layout between uses. Here is a list of the important console commands: savestate //saves the state of the windows to the start.txt open <widget name> [<width> <height> / <pos x> <pos y> <width> <height>] - Opens new wiget window widgetlist - Displays a list of widgets close <name> - Closes Widget Window resize <name> <pos x> <pos y> <width> <height> - Resizes Window set <key> <val> - Sets registry key to value get <key> - Displays value of registry key Of course, windows can also be moved resize using mouse drag and drop. (Although there is no way to open new windows without the console yet). The console is opened automaticly so "resize" or "close" should be used to move/close it. (Don't do "open console") Configuring YARK-MFD (.2) Download / Source YARK-MFD requires at least openGL 3.3, and is currently only compiled for 64 bit windows. YARK-MFD can be downloaded here, and the YARK plugin (required) here. Source code for YARK-MFD is here. Compiling YARK-MFD requires SDL2, glm, freetype and glew (see /Lib folder).
  13. @zitronen I sent a pull request, but unfortunately I could not test the code becouse I don't have any arduinos at hand. Should work fine though. I made the 16-bit angles be stored in the range of [-360,360), so that there is no need for negative headings (headings is in the range (0,360] while pitch is in the range (-90,90)). Not sure if this is the best option long term. Edit: I just came to the realization that the Normal Vector's heading (likewise to Radial Vectors pitch and heading) can be calculated easily from the prograde Vector, so there's no need to send it :V That is unless I got something confused again.