Jump to content

erendrake

Members
  • Posts

    536
  • Joined

  • Last visited

Everything posted by erendrake

  1. Here is how I see this going. 1. Read data into matlab 2. Do some crazy calculations and derive output, write to file 3. Read file into KOS, perform action. 4. Explosions
  2. Sorry about that. If we had not been so close i would have waited.
  3. Really cool idea. Thanks for sharing
  4. Great! Im really excited about RT and KOS working together, Ill have more news soon.
  5. @marianoapp Just FYI, when you announced you really cool work on this we were about to release a new version of KOS that adds a few new features. The commits for this release are on the master kos branch as of a few hours ago. I wont be adding any more commits to the KOS master branch until we are done with the merge I just wanted to give you a heads up.
  6. Just fyi we are just about to release a new version that adds direct control to RCS, I am planning on making the rest of the RemoteTech Integration a Top priority in the next release. If you have any input on the API changes you may have made it would be a big help.
  7. You are very welcome. Im not the only one who works on this and i know everyone appreciates the support
  8. Sorry i missed your message. That is a bit of a strange one, and something you should be able to do but cannot easily. The problem is that when you create a HEADING the values you supply get a bit mangled. I think you should be able to SET FOO TO HEADING(90,0,0). PRINT FOO:PITCH. //SHOULD give the pitch back to you Looks like i have work to do
  9. So im ready to release v0.11.1. This release is mainly about Direct flight control, and enabling autonomous docking. https://github.com/erendrake/KOS/releases/tag/v0.11.1 It will go up on spaceport soon.
  10. You are right about more advanced technology makes for bigger drives with less power usage, but we dont have advancement in tech yet in KOS so i am assuming you are using the same reel to reel tape from 500B to 500KB. I would really like to have tech tree integration and it is on my list and then all of this will make more sense. Some of these BODY numbers can be very well known simply by observing its orbit, others would require powerful telescopes. I am not sure you could get exact values without more direct observations? I was considering rounding some of these values and adding some kind of achievement/techtree mechanism to add the rest of the precision back over time. I would really like to do some kind of tech tree thing for KOS can you tell
  11. Its the very next thing for me to do after i get v0.11.1 released, I have http://erendrake.github.io/KOS/ but i would not consider it complete
  12. Another pre-release! I think this is the last pre for the direct control and docking milestone https://github.com/erendrake/KOS/releases/tag/v0.11.1RC NEW STUFF Added to BODY:ATM:SEALEVELPRESSURE Added Ctrl+Shift+X hotkey to close the terminal window (jwvanderbeck) Added a DockingPort Part Type, You can access it by "LIST DOCKINGPORTS IN ..." Improved RemoteTech integration (jwvanderbeck) SHIP:CONTROL:NEUTRALIZE releases the ship from KOS direct control. Added PART:CONTROLFROM which centers the transform on that part. Power requirements are now directly tied to the active volume's size, the ARCHIVE's size is unlimited so it is capped at the equivalent of 50KB.
  13. Another pre-release! I think this is the last pre for the direct control and docking milestone https://github.com/erendrake/KOS/releases/tag/v0.11.1RC NEW STUFF Added to BODY:ATM:SEALEVELPRESSURE Added Ctrl+Shift+X hotkey to close the terminal window (jwvanderbeck) Added a DockingPort Part Type, You can access it by "LIST DOCKINGPORTS IN ..." Improved RemoteTech integration (jwvanderbeck) SHIP:CONTROL:NEUTRALIZE releases the ship from KOS direct control. Added PART:CONTROLFROM which centers the transform on that part. Power requirements are now directly tied to the active volume's size, the ARCHIVE's size is unlimited so it is capped at the equivalent of 50KB.
  14. This sounds like a fun project! I would love to talk to you about how it would be implemented. Lets setup a group hangout and get some comments on it. It also seems like the mainframe would be responsible for switching active vessels? Spawning new ships on the pad?
  15. If marianoapp wants to, I'm sure we could merge our effort and make one really great scripting project. It's a lot of work to build something like this on your own, having a team to back you up can really help.
  16. This is really cool work! Enabling multi part missions is something scripting engines are great for and before now it has only been for those with newer machines. Thank you for sharing!
  17. My attitude is that none of us as as smart as all of us. Each of us has a focus and marianoapp's is clearly performance, Which we sorely need.
  18. I think its a great idea, My main goals have been to add new features to KOS to enable tasks like docking, science, Mod integration. I have also spent a bunch of time trying to make documentation that doesn't suck. I have spent very little time thinking about performance. It looks like great work and i will see if marianoapp minds if i merge in his improvements
  19. I just switched to a gh pages refdoc and i like it so far. the wiki is hard to manage and you can accept pull requests for documentation. We have talked about requiring pull requests with features also update the documentation
  20. "Should" is a messy word when you are talking about someone else's project. If I was maintaining RT one kerbal would never be enough for a full command station and I likely would have tied it to larger pod parts like the hitchhiker to give that part another function. Since I am not a contributor I have very little input. I will be fine with whatever Cliph and the other contributors choose.
  21. I apologize for awful wording and punctuation it was apparently too early for me to make sense. I agree with you, its planning. That is why you installed TAC.
  22. Good call. I like the idea that stations should be useful. For those who use TAC and claim this bar is too high,TAC is mostly there to make the game harder. It's what you signed up for.
  23. Most of the time they should be totally seperate. There are some static classes/members around that might cause commands to bleed over in strange ways. I'll have to audit these to make sure they are safely used
  24. It does appear that I have some work to do on these controls. It shouldn't be hard to change the behaviour to set. Steering helper fighting the direct method for control is going to be tougher but still shouldn't take long.
×
×
  • Create New...