Sli

I gave this a shot expecting a similarly unreliable experience as per KMP and was pleasantly surprised. Even playing from NZ on a US east coast server the lag was not noticeable and syncing was fast and didn't bug out. Great stuff! My only comments would be that, as a UI designer, I found some of the menus and dialogues a little unintuitive and frustrating to close at times. - Having the menus appear over the parts menu when it opens means that if you click on the buttons in them you also incidently select parts behind. - There is no "close" button on any of the dialogues (screenshot, chat etc) and yet it's not clear that the buttons on the main menu have been "toggled" either. - It would be nice if the shortcuts for these were also listed next to the respective categories, rather than having to go in options just to find out. - The listing for players and what they are doing is quite hard to see with the overly light gray background. - Having to "select" a server first, then click connect above (without the server button showing any "toggled" state) is a bit confusing. Surely a connect button to the side of it would make more sense? Also as a suggestion, given that this is more like another "game mode" than a typical add on, it would be really nice if the UI matched up a bit more with the general UI for the game. It sticks out a bit in my opinion. If you wanted the help i'd be happy to mock something up - check out my alternative Telemachus UI project here as an example of the sort of stuff i've done before.

I have no issues with my Android smartphone. Are you using chrome, or the stock browser? Can you connect from other devices using those IPs, or is it just your smartphone?

Glad you like it and thanks for letting me know about these issues! I can't remember exactly why I chose to have the throttle that way around, but now that you mention it you are totally right. It's probably due to the fact that when I was first replicating some of the UI features in illustrator, I copied the look of the navball throttle display to one side and the geforce meter the other way. The g-force scale isn't added (I don't think there is currently an API call) but it's drawn left to right. Funny that. The time warp module isn't working as I couldn't get the t.timeWarp call to return a value yet. The atmospheric density bar is in a similar boat, although the call does work, it's just I used the wrong one.

Hey everyone. I've finally got around to polishing off the UI that I started work on at the beginning of this year and now I'm excited to let people try it out and give me some feedback. Here's a quick run down of working features: - Draggable widgets that allow for a customizable UI. Here's 63 SAS Buttons. - A huge variety of buttons, dials, screens, scales and controls. See all. - A fun and bright UI that works well with Kerbal Space Program. - Automatic saving of layouts (same device) and the ability to export/import them. Currently screens of the same resolution only. - Common KSP Keyboard shortcuts for some modules (SAS, RCS, GEAR etc). - Touch screen support for most buttons and controls. Due to this not being a native app, performance is limited depending on your device. - Responsive UI to work on different screen sizes. Not currently optimized for phones, but fine on tablets and above. You can find the current release at https://github.com/chrisnic/mkon. Please check you are using a supported browser (Chrome, Firefox, Safari), minimum resolution of 700x500 and if using a tablet, a reasonably speedy one. I have been testing on an iPad 4 and an Asus Transformer Prime for reference purposes. I will be posting a "how-to" breakdown in the next few days. Here's a wee photo of it in action. Before it gets asked... there is currently no navball or throttle controls. These will be added soon once I am happy with the performance. I have had lots of messages from eager people and so for now the code is out there as a bit of a taster. The modular approach to adding 'widgets' means that once we have streaming support (camera views!) and a non-restricted API (as per 2.0 spec), there is no limit to what can be added really. I'm happy to take requests too, if other people have ideas on what buttons/switches they'd like to see. Right now priority is performance and bug fixing however, so if you find something that doesn't seem to be working right, give me an idea of your browser/OS/device/resolution and i'll look into it.

I'm working on a version using Three.js and I believe the last guy that tried it also used 3D custom textured spheres, rotated using the rawpitch values from the API. It's quite a performance hog on mobile so I haven't done much else on it for the moment.

Could I make a request for landing gear and brake status as well? Currently there is only the command to toggle these on and off, but not their current state? Thanks! Deedo, that is some nice work on integrating a map. You have inspired me to add a similar map module to my own UI which I will be releasing shortly!

Hey, be sure to check the documentation here: https://github.com/richardbunt/Telemachus/wiki/Web-Socket-API as it answers your question. You do not need the value or brackets [] for those buttons as they are simply toggled on or off. The only one that requires a value is setThrottle I believe. So just { "run": ["f.light"] } should be fine.

Aha, excellent! Regarding the fix with r.resource & r.resourceMax - I am getting values back now, however they do not return with the original resource 'type' I subscribed. So for example if I subscribe "r.resourceMax[LiquidFuel]", in the data that is returned it will only be "r.resourceMax" with no [LiquidFuel]. While this might be fine for one item, if I have oxidizer, liquid fuel and monopropellant all subscribed, I can't ascertain what values are what since all three come back with the same key. No explosions yet (other than my bad flying around ksc). I will let you know if anything else comes up! Thanks!

I have been using the "+" call without any issues. Do you have a ws.onclose(function() { console.log('connection closed'); } set and is this being triggered? Another option is to open up chrome dev tools, go network tab and refresh the page > find the entry called "data link" click and look at the headers (if there are any). The headers can be useful. Also be sure you are not sending bad requests at any stage post-connection. If you send a subscribe key without an array value (so "+": "v.altitude" instead of "+":["v.altitude"]) I have found it has a habit of just stopping completely. Sometimes it requires a complete reboot of KSP in order to get rolling again. I have had lots of instances where the server just stops completely that seem to happen periodically when there is no activity for a long time. (It does not seem consistent though).

Ok, so I had a bit of a play tonight and these are the issues that cropped up. Please feel free to correct me if any of it is a bit of occasional coding derpiness creeping in. - r.resource[LiquidFuel] and r.resourceMax[LiquidFuel] don't appear to be parsed right. (LiquidFuel as an example). I get "r.resource":-1 and "r.resourceMax":-1 returned, which indicates the content of the square brackets is being cropped off. Now this may be due to the fact I am using JSON.stringify to prepare the data before using the websocket.send(data) function, but since the socket requires an array for the value of "+" I can't see how else to send those resource api strings. - RCS, SAS and Light button state calls return "" : 1 or "" : 2 when the game is paused, rather than a true or false state. - n.roll only returns 0 as a value? - I am getting very occasional timeouts where the server seems to stop completely and it involves a reboot of ksp in order to get it going again. I haven't been able to replicate this consistently yet though. Hope this helps!

Seems to be working ok! I haven't got any metrics to compare performance yet, but using sockets has simplified a lot of the code I needed for adding/removing modules without a refresh. I have however found a few bugs in transitioning already and I will report back once I've had a bit more of a play. The default ip should be 127.0.0.1 when run locally that will work only on the main PC. Local network ip's will usually begin with either 10.1.1. or 192.168.1. If you want to connect from another computer or device you will need the ip that the router assigns for your main pc on the network to connect to it. Most routers have a DHCP client list that is somewhere in the settings or alternatively you can use ipconfig /all in command prompt on the main pc and look for the assigned ipv4 address there. If you can make the IP the router assigns to your main pc static via that list that would be ideal (so it doesn't change at any point in the future). You shouldn't need to do any port forwarding unless you want remote connections beyond your network to your router. It's possible however that a firewall or anti-virus software is blocking port connections (Telemachus uses 8085 in the new build), so best to check that too!

Absolutely! I've done some work with Node.js and Websockets in the past and it can be lightning quick (I built a small multiplayer game with it). At the moment I am seeing a small amount of lag in getting data over wifi, so hopefully the switch to sockets rectifies this, else there will be a lot of prediction going on to keep things looking smooth haha. I started work on implementing a three.js navball... Please excuse the colour, I wanted to keep the fps on the gif quite high. Works a charm locally on my desktop but there are massive fps and delay issues for this on the tablet that I will have to look into, that is at least partly related to the interval at which it gets data and partly just because mobile browsers suck at running anything javascript related, especially jQuery.

Ok, so here's my prototype UI that i've been working on the last few nights. - It's a lot more visually orientated and the modules are based off of the look and feel of the existing UI for KSP. - It's designed as more of a ksp 'remote' for mobile devices and display for second monitors rather than a raw telemetry readout. - It's completely modular - add as many modules or as little as you need via a drag and drop grid. - The layout is saved automatically between refreshes and can be exported/imported so you can share your own custom control screen. - You can add custom resource modules (i.e to track Food, Water, Kethane...) in addition to the stock ones. - There is a template structure for the individual modules that you can use to (in theory) code your own. I can confirm that it does run smoothly (albeit with a few bugs) on both an iPad and Android Tablet, but I won't be prioritizing optimization for phones due to screen size limitations and general clunkiness. The add module GUI has filters for different types. There are buttons, scales, dials, screens/displays and resources. You can drag and drop any element to where you want it and delete by hitting the cross at the top right. Pretty much all of the modules are functioning. Note the added 'Oxygen' resource which comes from TAC life support. Just to show the animation in action.

Excellent, working great! I'll post what i've been up to later today.

I'm working on my own custom UI at the moment but i've hit a bit of a hiccup. I'm using @font-face to serve some custom web fonts, but i'm getting 404 errors in the console when the browser tries to serve them. I know that the code is solid as it works fine on my own apache build and a remote server - it's only when the web files are served by the Telemachus http server that they resolve like this. Is this some sort of routing issue or blocking behaviour that prevents files with custom extensions (.woff, .ttf, .svg) from being served properly? EDIT: I had a look on github and found, what I believe to be the culprit: Any chance of an update to permit .eot, .ttf, .otf, .woff, .svg and also .gif as these are pretty common. Cheers! EDIT2: I can confirm that it is definitely the way the http server handles file extensions that is causing this. Here's my temporary css 'hack' to force the fonts to be handled: @font-face { font-family:'BebasNeue'; src: url('../css/fonts/BebasNeue-webfont-eot[COLOR="#B22222"].css[/COLOR]') format('embedded-opentype'); src: url('../css/fonts/BebasNeue-webfont-eot[COLOR="#B22222"].css[/COLOR]#iefix') format('embedded-opentype'), url('../css/fonts/BebasNeue-webfont-woff[COLOR="#B22222"].css[/COLOR]') format('woff'), url('../css/fonts/BebasNeue-webfont-ttf[COLOR="#B22222"].css[/COLOR]') format('truetype'), url('../css/fonts/BebasNeue-webfont-svg[COLOR="#B22222"].css[/COLOR]#bebas_neueregular') format('svg'); } Renaming all of the font files to '.css' means the files are served. On the browser end (at least in chrome) these files are still interpreted as 'fonts' once they are loaded and get handled appropriately.