Jump to content

Dagger

Members
  • Posts

    132
  • Joined

  • Last visited

Everything posted by Dagger

  1. Next version cfg file will be much better. You can see it here: https://github.com/LunaMultiplayer/TiltEm/blob/master/TiltEm/PlanetTilt.cfg I'm still not satisfied with the "TILTX" and "TILTZ" names... There must be some more technical name...
  2. There are still bugs as the tilts are not consistent across times so have that in mind
  3. So regarding the navball I've been doing some tests with the (still unreleased) 1.1 version (you can compile it tough) and it looks right as the "north" is pointing to the true north of the planet This is how a plane going north just after takeoff looks in default KSP without the mod and with the mod: Ignoring the camera rotation, both planes are going to the "north" and you can check it in the commnet line that the heading is correct. Same applies when going east (ignore the camera rotation): I'm aware of the planet rotation bug, from what I see I should somehow apply a rotation based on the epoch or some other orbital parameter so it's consistent across saves... I'm working on that PS: Another test I did. In this case Kerbin has a tilt of 45º and the plane is going east, I extended the ecliptic line and the angle is correct
  4. Yeah I think I must apply rotation to the navball too... Will have a look at it
  5. First I want to finish the kopernicus plugin, I'm thinking about doing it as another ".zip" in the release artifacts. Will se once I've finished it I don't think they will be broken, orbits are independent of the tilt of the planet No idea about other mods but it shouldn't affect it Everybody said that it was impossible and I never really tried it until I got a bit tired of LMP It's the angle against the "UP" universe vector (consider it against the equator of the sun plane) Probably yes, I will have a look at it later on To be honest I dind't fully tested it as I'm not so good at playing KSP. Anyway if you find a bug feel free to open a github issue and I'll solve it
  6. Yeah That's the only case where 3 axis are useful, for the T=0. Will make a patch and add both values once I get the kopernicus patch
  7. Each planet can have it's own axial tilt. You can configure them in the .cfg file
  8. When talking about axial tilts you are only talking about the angle of the rotation of the planet against the ecliptic so for now I only accept 1 value for it but shouldn't be difficult to add more degrees to it. Remember that the axial tilt of a planet is the same during all the orbit. It doesn't rotate/moves (technically it changes by very few degrees but it takes thousands of years) The coordinates and orbits of the vessels are not dependent on the axial tilt of the planet so from what I saw it works "fine" (fingers crossed ;)) Example: This is how a 90º orbit looks like when Kerbin is tilted:
  9. To be honest I didn't tested it in every single case but any bug you found let me know
  10. I honestly don't know how CKAN works but feel free to do it altough I'm working in a custom plugin for Kopernicus atm. Also if you need to upload some file to the repo do a PR
  11. I'm working on it to make it as a kopernicus addon so better don't use it in your planet packs still
  12. Tilt'Em Adds planetary axial tilt for KSP planets Licence: MIT (don't even ask me for permission to fork it ) Download link Installation instructions Source code I always wanted to have planetary axial tilt with the default planets but I've always read that it was impossible to do it on unity. Principia managed to do it, but you have to use it's cool but complex n-body physics. This mod adds axial tilt to the default planets and keeps the default KSP 2-body physics. Follow the installation instructions to check how to install it and how to edit the planet tilts for each individual planet
  13. Yep LMP career is shared. There are no plans to change this at the moment, too much work and bugs are first in the priority
  14. Nope there's no way of doing that because of how KSP works. But you can install the mods and then generate the mod file from KSP so you have the part names already inserted
  15. Yep. Thats it For writing it uses a simple ToString (which makes sense as config nodes are string based) But for reading it uses a "if stair" (as Types don't accept switch statements) and it can only read basic types (bool, int, float, vector, etc). You can override this with reflection or some other libraries and implement your own read, it might be a bit dirty but it will work.
  16. That's because the "BaseField" class doesn't implement specifically the GUID type in it's "Read" method.
  17. All the PartModules inherit from a "PartModule" base class, but they implement different fields on the child classes so that doesn't help much as the parent class is too "flexible" If you only relay the protovessel you will not see the panels extending/retracting and you will have to reload the vessel. That's what DMP does, it reloads the vessel every 30 seconds but unfortunately the reloading process s very CPU/memory intensive and that's why you see stuttering on DMP. The only way to do that is to call the same method on the part sync and also send the protovessel field to the other players that are far away from that vessel so when they laod it they have the latest data
  18. The problem is getting/relaying the data basically. Example: The deployable solar panels inherit from "ModuleDeployableSolarPanel" When you extend a panel you must replicate that action to the other players. For the players that are within load distance (< 20km) of that vessel they must call the same function (Extend()) over the same part module and on the same part of the original player. For the players that are far away, they must update the protovessel (the vessel serialized as it appears in the save files) with the new part module value (extended = true) on that same part. It's not an easy job, specially since every part module is different and nobody designed them with multiplayer in mind, therefore the only solution is to make a XML for every part module.
  19. 1) There's actually a message from LMP that says that so it's the expected behaviour. Loading a savegame creates paradoxes as you are going back in time and that's not allowed, also it doesn't make any sense in a multiplayer game 2) Probably a bug, I'm working on the new version and the code has changed a lot so I don't know if it's reproduceable in the lastest nightly. Hopefully not
  20. I did a lot of improvements in nightly so the next one will be even smoother I just need to find a nice way of syncing part modules....
  21. I see that class in the api (https://kerbalspaceprogram.com/api/class_vessel_teleporter.html#adf79a0a401fd2d6512111f68a448e93d) but I can't use it even in 1.4.4 I'm also interested in this as with LMP I'm having issues when moving a vessel that is on physics range (unpacked)
  22. Hi guys, I just wanted to remind you that this mod is made on my spare time, at this moment we are only 2 developers and it's not an easy task to make something designed for single player available to several players, the mod is still in beta, it's not in the addons release forum as it's not stable. If there's some bug/improvement and you want it solved ASAP, feel free to fix it and do a push request as other developers have done. Besides this, let me remind you of the wiki page (https://github.com/LunaMultiplayer/LunaMultiplayer/wiki) most of the issues I've seen are explained there
  23. Found it! Using the sidereal rotation period it's a simple rule of 3. Example: https://wiki.kerbalspaceprogram.com/wiki/Kerbin Kerbin sidereal is 21549.425 seconds so we know it makes a 360º turn in that time If we have a interpolation of 2 seconds---> 21549.425 ----------- 360 2 --------------- X 2*360/21549.425 = 0.3341 That's the amount of degrees that I should add to the LAN that a player sent me Thank you all for your help!!
  24. Thanks a lot!! It worked. By trial and error I've found that adding "0.033" to the LAN value of the received data and with an interpolation delay of 2 seconds the positioning is almost perfect! Now I will try to do the maths and find how to get such value
  25. Just had a look at the code and it seems nice the issue is that I play with orbital parameters and not lat/lon/alt as they allow me to have a more fluid movement. I guess that in this case I should fix the "LAN" orbital parameter only? I think that's the only one that can be affected by the planet rotation considering there's no axial tilt... Picture for reference:
×
×
  • Create New...