[0.23.5] Go At Throttle Up [May-11-2014]

[Gumis91]

This mod is awesome! I've been using Telemachus since beginning of my KSP adventure and always thought it has a great potential to be expanded. Now, IT HAPPENED! :-)

However, I ran into trouble integrating Telemachus with this mod. Pictures and cameras working like charm - no issues here. Unfortunately, data from Telemachus are not displayed.

I've done some tests to locate issue and what I've found so far:

- Telemachus is working properly, I can read all data about active vessel (as long as KSP is active)

- Methods highdata(), meddata() and lowdata() always returns empty result '{}'

- Method postdata() is never called

- checked Windows Firewall rights for both KSP and Python - both have access to public and private networks

- no changes in Telemachus or GATO configs

- ServerRelay is located in KSP/GameData/GoAThrottleUp/

- same situation for all possible addresses (localhost, my network IP or 127.0.0.1)

- latest version of both GATO and Telemachus

- host OS is Windows 8.1 x64

I don't know Python at all, but I'm a C# programmer and so far it looks that either GATO is not requesting data from Telemachus, or Telemachus is not updating (i.e. ignoring or unaware of subscription) GATO properly.

Any ideas? Any help will be apprecciated :-)

--- EDIT: ---

Nevermind. When I was trying to solve issue described above, I wasn't aware that GATO is a standalone plugin. I was absolutely convinced that plugin is responsible only for image data and other data are relayed via Telemachus - it turned out to be wrong.

My suggestions:

1) I would love to have monitoring of each stage separately - in that case there could be sort of 'booster specialist', 'spacecraft specialist' etc. in LARP game.

2) Real Fuels support would be nice as well.

Anyway, awesome plugin! (Can't wait to install another monitor to display MOAR data!)

Edited May 11, 2014 by Gumis91
issue solved

[Kalista]

Any plans to add vesselviewer support into this? Would be nice if the people using this could see atleast the vessel state during flight if not interacting with the parts thru it as well.

[theSpeare]

This is incredibly great. Thank you for compiling!

Orbital map would go a very very long way, similar to how RPM handles it.

[SuperDudeMax]

Default address once the relay is running: http://127.0.0.1:8080/static/lights.html

If it can't bind to localport 8080 it will probably just die. If you can, you should also be able to right click on the file and select "open with idle". You should then see the source code. Select "Run" from the menu and select "Run" module. This may give me some good debug text to help you. =)

I bet it failed to import something as you need all the various dependencies as well. I've packaged them up correctly in the zip file on the newest github release.

I've updated the release on github: https://github.com/withorwithoutgod/GoAtThrottleUp/releases to provide two separate zip files that should simplify the process.

SyntaxError - invalid syntax

It then highlights 'keyname' on line 34.

[thrandisher]

Looks pretty nice. Might have a use for all these ancient computers i have siting around now. Would diffinitly give that mission control feel with computers from that nostalgic era of the moon landing and so forth

[TacoScott]

SyntaxError - invalid syntax

It then highlights 'keyname' on line 34.

I'll check into this and report back. I wonder what version of Python you have. I havn't coded this for python 3 yet

[Adyx]

The first version was giving me a syntax error as well, the updated release version works fine though. Although after docking/undocking and switching vessels a few times, the various pages seemed to stop updating for the ship I had the antenna and cameras on.

[SuperDudeMax]

I'll check into this and report back. I wonder what version of Python you have. I havn't coded this for python 3 yet

That may be why, I'll install Python 2 and all that.

[diomedea]

I may our may not write the ability to customize interface. At this stage I want to keep the codebase as small as possible. I'd like to keep it tiny until the community decides a direction. I plan on writing some docs on how to make your own interfaces. It's pretty easy. Plus I'm going to be making tons more. Tell me what you want and I'll get it done.

Thanks, the above is pretty clear . I better wait and see those docs for making interfaces, then I'll be in a position to suggest if something else is needed for my "Control Room". Nice how you use GATU in team, that shows why the interface is built that way.

[ironpenguin]

Is it normal for the cameras to have this odd flickering effect? Its like they just keep rapidly flickering to a blank screen for a split second then returning. Cant figure out how to get it to stop.

[FishiMishi]

This is incredibly great. Thank you for compiling!

Orbital map would go a very very long way, similar to how RPM handles it.

If I downloaded all of the files on GitHub, do I just have to drag and drop them into a folder in GameData?

[TacoScott]

The first version was giving me a syntax error as well, the updated release version works fine though. Although after docking/undocking and switching vessels a few times, the various pages seemed to stop updating for the ship I had the antenna and cameras on.

Bug added to tracker. THank you sir!

[TacoScott]

Is it normal for the cameras to have this odd flickering effect? Its like they just keep rapidly flickering to a blank screen for a split second then returning. Cant figure out how to get it to stop.

Flickering is not normal, but is something I've run into before. The "cross fading" was an attempt to minimize this. The next release should have this resolved as I have a method to remove this as an issue.

Thanks!

- - - Updated - - -

If I downloaded all of the files on GitHub, do I just have to drag and drop them into a folder in GameData?

Download the 2 separate releases. The GoForThrottleUp.zip goes in the usual gamedata location, the server relay can live where-ever. There is somewhat updated install steps on the first post now.

[TacoScott]

I'll be doing another ksp "mission control" event with my friends after work today. I'll report back with some pictures and "lessons learned". I tweak all sorts of things after every event as we learn so much of what works/what doesn't.

[TacoScott]

Any plans to add vesselviewer support into this? Would be nice if the people using this could see atleast the vessel state during flight if not interacting with the parts thru it as well.

I was unfamiliar with this mod. I looked at the license first, it looks like it'll be solid should I need to fork or otherwise tweak the project. Then I looked at the actual mod. It is OUTSTANDING and I will be including this in the web interface. My quick look at the mod makes me think I can extend the relevant classes and make this all work. Stay tuned, I'm going to make this happen.

[Coffeeman]

This is INCREDIBLE! This is exactly what I was looking for (creating a full-immersion ksp sim capsule.) Could you perhaps tell me how I can get a raw stream of data? I can also help with python (in theory after AP tests!)

[KvickFlygarn87]

Now that I'm getting a lappy soon, this will be IMMENSELY useful! It's stylish, useful and generally awesome!

One question though, are you considering kOS implementation?

[mikes3ds]

Really nice job!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Let me know if you need help in development. I would be happy to help.

[TacoScott]

So. We did a new test run.

Turns out CherryPY as a back end webserver is terrible. I have updated the newest release to use "paste" as the webserver and it made things comically better.

https://github.com/withorwithoutgod/GoAtThrottleUp/releases

Here are some pictures of the event.

Javascript is disabled. View full album

We made it to the mun. We then crashed. =)

Edited May 13, 2014 by TacoScott

[mikes3ds]

I have been trying to speed up the frames per second for the camera. I was looking at the code, you use nextRenderTime = Time.time + freq; Lowering the "Freq" should increase rendertime? (Maybe it should be period? T=1/F) I am looking at the java script where I can update the frequency to reflect that change I made in C#, but I cant seem to find it?

I said this before assomedosom software!!!!! Good job!

[TacoScott]

I have been trying to speed up the frames per second for the camera. I was looking at the code, you use nextRenderTime = Time.time + freq; Lowering the "Freq" should increase rendertime? (Maybe it should be period? T=1/F) I am looking at the java script where I can update the frequency to reflect that change I made in C#, but I cant seem to find it?

I said this before assomedosom software!!!!! Good job!

Yep, lowering that should increase the FPS of the camera. In addition you'll want to look at this area:

https://github.com/withorwithoutgod/GoAtThrottleUp/blob/master/ServerRelay/static/js/main.js#L1524

the UpdateMutliCameras() function. I'm going to be including quicker render time in future updates. Like... later today probably but until then run wild! =)

[TacoScott]

Now that I'm getting a lappy soon, this will be IMMENSELY useful! It's stylish, useful and generally awesome!

One question though, are you considering kOS implementation?

At this stage the GATU is all about just presenting information, but I'm open for the future.

[mikes3ds]

Thanks, yah I found that part. But was not able to speed it up the rate the javascript updates. I will just wait tell later tonight after work.

[mikes3ds]

I am trying to think of a way to link the C# code with the python code, posting the data seems like it could slow things down. There might be a way to pass data through memory.

[TacoScott]

I am trying to think of a way to link the C# code with the python code, posting the data seems like it could slow things down. There might be a way to pass data through memory.

I'm working on methods to pass things around. Several options I'm considering are:

1. mjpeg stream
   
2. a credit/buffer system of sending camera data (similar to what I did in TacoZMQ for sending file chunks)
   
3. Developing my own socket protocol to pass data around instead of http posts
   
4. encoding image data to jpg, or something with a smaller memory footprint and then posting that.
   
5. having multiple co-routines capturing and posting image data from one camera at the same time. This would allow a buffer/queue of outgoing screen caps and keep the flow good I would think. It would increase fps and would not have too bad a performance impact. (I think the most reasonable and my current favorite)
   

Using a shared memory space and getting .net and python talking via that shared memory would be... trouble me thinks.

Linux would allow more true local sockets that could speed things up. Windows would be a no go for that really though.

here is the camera screen shot workflow:

1. Time comes to the point where we should capture camera data (next capture time > current time)
   
2. A Camera "Screen shot" is rendered into memory
   
3. that screen shot is converted to a png
   
4. that png is www-posted to a local webserver via a .net/unity coroutine
   
5. that web server acquires a thread lock on an internal data structure such that it can't be read/writen to "mid-read" or "mid-write"
   
6. the web server updates the internal data structure
   
7. the web server release the lock
   
8. the web interface of GATU can then see the newer updated image
   
9. gatu updates it's "next" capture time to be at the current time + the capture frequency. (current time + 1 second for example)
   

The advantage of the above workflow is that it's all pretty simple and uses built in (wwwform/encodetopng/coroutines) and well documented concepts and protocols. It also doesn't get into the space of having unity/ksp doing a lot of the processing or making something work in unity that really doesn't make sense.

Ultimately GATU is essentially rendering additional frames. At some point this will have to translate to performance impact. Whatever I can do to mitigate that I'm going to try to find a balance. Sending every frame will KILL us, Sending 1 every two seconds is too slow. I'll find a balance.

Long story short... I've got my head in the game. I'm thinking of ways to make it better. I think having multiple "coroutines" capture and posting the data at the same time will prove the best balance of performance and FPS. Stay tuned.

Edited May 13, 2014 by TacoScott