[Release - Final] kOSPropMonitor - IVA kOS Monitor

[dsonbill]

44 minutes ago, karamazovnew said:

Works now, but seriously, the font is too small  And yeah, the input lag is.... quite big  

Took me a bit of time (I just spent 1 hour writing useless tips), but I finally realized just how brilliant your method is. It basically does 99% of what I was about to suggest and all in one screen. Wow.... 

One minor bug, I usually test my flights with KCT's simulations. But if I exit the flight back to VAB while in "keyboard focus" mode, the interface is stuck and I have to exit the game. Mouse moves, right click works but camera controls and left click don't work. 

Don't worry about the arrow keys, we can disable them in the game's main menu. The only problem is that some other addons shortcuts (such as KAS which opens his interface on pressing P) still trigger, but that's true of the normal kOS terminal as well. In fact, in IVA I can't even use the kOS terminal unless I first press your button, so good job on that. If you could find a solution, make sure to tell the guys at KOS as well . Regarding the "has keyboard focus" is it possible to just alter the background color of that RPM screen? 

By the way, why don't you use a transparent image layer to replace most of the #### characters and gain some extra space? Lights could keep them as I like how they push eachother outside the screen. But can't they be more "like lights"? I mean something like green background for the characters? Maybe even add two more properties for them: background and fontcolor. 

More questions:

- Is it possible to use the name of the CPU (if altered) instead of the "kCPUx" names in the processor list? It could remain as default. 

- Is there any event when changing the active processor? I'd like to change the button labels and the lights based on what processor is active through a "refresh gui" script.

- RPM has one button currently bugged, the Engine Ignitor button. You could use that for your main page. Instead of leaving it as standalone, you could attach it to that and use some of the other buttons more wisely. For example: X as CTRL-C (probably will jump us out of IVA), Green Arrow as activate/deactivate processor, LEFT-RIGHT for resolution change, UP-DOWN for line history, Standby for standard RPM standby. So you don't actually loose any of the "customizable" buttons. Heck, one more option would be to even use the STANDBY button itself and replace the "boot" page of RPM. 

By the way, since I can't test this now, if I show the kPM page on multiple RPM monitors, what would I see. Would they all be identical? If not, nesting pages would be cooler than ice  But I don't see how you could add link between the active monitor, active page, last button pressed conditionals and events into KOS. If you could... wow boy. But let's leave that for later, what we have is nice enough if polished. 

 

 

 

 

Thanks for the input! I've been reading over your post a few times, but I still need to scan the first part more and think on it. The main reason we're using standalone now is because I haven't found a way to alter the resolution of the RPM screen. I'm going to look into doing this soon though, as it would be a great idea. I'm thinking about doing what you said, and taking over the home screen - I'll make my own app selector for it and take over all the buttons.

There's currently no processor change hook, but this could be arranged. It's probably very important anyway.

As for replacing stuff with a texture, 2 things - I am bad at art stuff, and I'm planning on adding a default color changer, so the other stuff can be colorized to something else as well. If you want to lay something out, I'll definitely check it out.

And speaking of that, feel free to do the same for the terminal. You don't have to set the terminal template up - just make a mock-up in a text editor.
The default is 40x20, the resolution I'm using is 100x50. If you can come up with something nice that fits 40x20, it'll be a big help.

 

Also, the screens are completely independent, though vessels will have a common source for things soon to fix the input lag and keep multiple screen instances from making the things lag.


Have you considered my proposition about 1 dedicated instance and configurable pages in the normal MFD?

Edited May 20, 2016 by dsonbill

[Dunbaratu]

7 hours ago, dsonbill said:

@Steven Mading, thanks  Getters and setters are a pretty decent way to do buttons and lights - it just makes sense.

Either of those scenarios is definitely acceptable. The naming is the main thing I'm not happy with as far as the interface to scripting goes. Whatever you guys end up going with will be awesome - but this is definitely acceptable for now.

 

It's more that we're concerned about two things:

1 - Namespace protection.  It gets messy when every mod writer has to be aware of every other mod writer's names.  The amount of communicating between mod authors can grow at a factorial rate if we're not careful.

2 - We should probably provide an API for other mods to do what you're doing, to make it more future-proof.  So that if we change the underlying implementation of things it doesn't break your mod.

 

It's something we talked about among ourselves for a while but it was never high priority before.  But if you're having to dig down into the guts of kOS and fiddle with it to get things to work it might mean it's a higher priority than we thought.

Edited May 20, 2016 by Steven Mading

[dsonbill]

12 minutes ago, Steven Mading said:

It's more that we're concerned about two things:

1 - Namespace protection.  It gets messy when every mod writer has to be aware of every other mod writer's names.  The amount of communicating between mod authors can grow at a factorial rate if we're not careful.

2 - We should probably provide an API for other mods to do what you're doing, to make it more future-proof.  So that if we change the underlying implementation of things it doesn't break your mod.

Absolutely agreed on both points - I more meant I don't mind being at least a little hacky still, especially since I'm still using the shares. But I do understand that letting these hacks gain momentum can be problematic in communities like this - as long as I'm paying attention, I'll adapt at whatever rate you guys go at.

[karamazovnew]

Sounds like a challenge

|----------------------------------------|
|LABEL LABEL LABEL LABEL LABEL LABEL EXIT|
|kOS Terminal:  kCPU 0                   |									
|DEBUG FLAG FLAG FLAG FLAG FLAG FLAG FLAG|
|FLAGS FLAG FLAG FLAG FLAG FLAG FLAG FLAG|
|                                        |
|kOS Operating System			         |
|KerboScript v0.20.1                     |
|Proceed.                                |
|PRINT "REPEAT AFTER ME".                |
|REPEAT AFTER ME                         |
|PRINT "NOT YET!".                       |
|NOT YET!                                |
|PRINT "STOP IT!".                       |
|STOP IT!                                |
|PRINT "CUT IT OUT!".                    |
|CUT IT OUT!                             |
|PRINT "YOU'RE SILLY".                   |
|YES YOU ARE.                            |
|                                        |
|LABEL LABEL LABEL LABEL LABEL LABEL HELP|
|----------------------------------------|

Here's a photoshop mockup:

As long as you can change the background image when you press one of the buttons (no idea if possible, really), you can do a lot of cool stuff. Because 40 characters is not enough for 7 labels of 5 characters, why not sacrifice the two right buttons for something else? I've labeled them HELP and EXIT here but they could be anything. And of course, only the set labels would appear, not all of them  That means that we can still make long labels, as long as we ignore the nearby buttons. The same goes with the flags. I simply can't fit more. But 4 letters should be enough for most applications. I think you can also put images ON TOP of the text, so a nice grid semi-transparent "buttons" image would look nice for the lights. Oh and, to save a bit of space, the "enabled/disabled" state for the processor would need to be shown by the color of the name.

EDIT: oh and you can have 13 lines of code, or 12 and separate the lights more or do something else with the extra line. No idea if as you enter code you overwrite the labels below.

Edited May 20, 2016 by karamazovnew

[dsonbill]

44 minutes ago, karamazovnew said:

Ok - I REALLY like what you've done here. Let me slap something together and see how I like this.

EDIT: Would you like to upload something official for this? Your mock-up is *really* good!

Edited May 20, 2016 by dsonbill

[karamazovnew]

11 minutes ago, dsonbill said:

Ok - I REALLY like what you've done here. Let me slap something together and see how I like this.

EDIT: Would you like to upload something official for this? Your mock-up is *really* good!

Many thanks . But until I actually have a framework of what can be done, I'll sit back and gather some inspiration. Plus, I'm out for the weekend (stupid vacation!). Meanwhile, just use the files RPM or B9 have, the proportions are all in there, just change the colors a bit. The rest is just transparent filters and text colors in RPM's code. I think B9 used the most features of what RPM can do. Once your main files are up and running I'd love to give it a go. Maybe I'll take a shot at RPM itself, long overdue to be honest

Here's something cool: http://www.awn.com/vfxworld/interfacing-mars-territory-studio-and-martian

Although there's something about Orbiter's simple interface which still gets to me. 

 

[Dunbaratu]

Man, that looks pretty sweet.

I'd been thinking about how to do color text under the current terminal system (which includes sending color escapes over the telnet version to keep them consistent.)  I'll have to keep an eye on what you're doing here to try to make sure we use consistent script commands to make it happen.  (So a script can use the same code to draw to the RPM terminal as to the kOS or telnet terminal.)

 

20 hours ago, dsonbill said:

I do seem to experience the occasional problem where the processor share won't have the above getters and setters added, but I think I may have a work-around or even a possible real fix.

Could this be a classic race condition problem?  Neither your PartModule nor our PartModule is in control of exactly what order the main game chooses to initialize the PartModules on the parts of the vessel as the game loads the scene.   Maybe you're trying to use KOSProcessor before KOSProcessor has had a chance to perform its own initialization work?  I'm just making a random guess.

[hvacengi]

11 hours ago, dsonbill said:

Absolutely agreed on both points - I more meant I don't mind being at least a little hacky still, especially since I'm still using the shares. But I do understand that letting these hacks gain momentum can be problematic in communities like this - as long as I'm paying attention, I'll adapt at whatever rate you guys go at.

I'm in the process of writing our 3rd party api (and will probably make some actual progress on it this weekend, but I've been saying that for 4 weeks).

Essentially it's going to work out like this:

• The 3rd party mod will have to reference both the KOS and KOS.Safe libraries (I want to make KOS optional, but that's pretty hard to do with current architecture)
• It will be technically possible, but strongly discouraged, for a 3rd party to add functions and bound variables (due to namespace collisions as mentioned above).  This is needed because some of the existing addons reach into the global namespace and we aren't going to break all of them instantly.
• The primary avenue for adding features will be by adding an attribute to your "addon" class, so that it will be visible as a suffix on the global `addons` list.
• Using suffixes on your base addon, you can make functions or variables.  You will be able to use all existing kOS defined structures, or introduce your own new structures with specific functionality.
• We will probably end up with some level of guidelines or "best practices", including licensing information (which won't matter to you since you're already GPL3) and "how to play nice in the sandbox" types of things.

When I have the framework ready for testing I'll make it available on github and ping you so that you can test it out and see if it's missing anything or is super clumsy.  I know that @Ziw will be helping me out by testing it to migrate Infernal Robotics to the new method as well.

[dsonbill]

 

6 hours ago, Steven Mading said:

Man, that looks pretty sweet.

I'd been thinking about how to do color text under the current terminal system (which includes sending color escapes over the telnet version to keep them consistent.)  I'll have to keep an eye on what you're doing here to try to make sure we use consistent script commands to make it happen.  (So a script can use the same code to draw to the RPM terminal as to the kOS or telnet terminal.)

 

Could this be a classic race condition problem?  Neither your PartModule nor our PartModule is in control of exactly what order the main game chooses to initialize the PartModules on the parts of the vessel as the game loads the scene.   Maybe you're trying to use KOSProcessor before KOSProcessor has had a chance to perform its own initialization work?  I'm just making a random guess.

I actually didn't realize I had to set the bindings on every boot - but this makes a lot of sense. If you guys would like to make it part of your API that 3rd party namespace stuff gets set automatically on boot, you can, but I also like the idea of being in control of setting up the environment on boot.

As far as color goes, I assume you've seen how RPM does it, with things like "[#FFFFFF]" being replaced automatically. The function in the terminal is probably pretty obvious, but I thought I'd make a video so you can see without having to do it yourself: 

 

5 hours ago, hvacengi said:

I'm in the process of writing our 3rd party api (and will probably make some actual progress on it this weekend, but I've been saying that for 4 weeks).

Essentially it's going to work out like this:

• The 3rd party mod will have to reference both the KOS and KOS.Safe libraries (I want to make KOS optional, but that's pretty hard to do with current architecture)
• It will be technically possible, but strongly discouraged, for a 3rd party to add functions and bound variables (due to namespace collisions as mentioned above).  This is needed because some of the existing addons reach into the global namespace and we aren't going to break all of them instantly.
• The primary avenue for adding features will be by adding an attribute to your "addon" class, so that it will be visible as a suffix on the global `addons` list.
• Using suffixes on your base addon, you can make functions or variables.  You will be able to use all existing kOS defined structures, or introduce your own new structures with specific functionality.
• We will probably end up with some level of guidelines or "best practices", including licensing information (which won't matter to you since you're already GPL3) and "how to play nice in the sandbox" types of things.

When I have the framework ready for testing I'll make it available on github and ping you so that you can test it out and see if it's missing anything or is super clumsy.  I know that @Ziw will be helping me out by testing it to migrate Infernal Robotics to the new method as well.

That sounds perfect. I'm sure there won't be many of us doing this in the meantime, as finding out how to add bindings like that is not exactly a cakewalk for most. Having said that though, one could easily just look at what I have up and get the wrong kind of inspired.

As for having to link to libs, it's something I'd have to do anyway. Unfortunately there doesn't seem to be a simple way around this.

Thank you again for all the effort - kOS is definitely getting the comprehension it demands.

[Adik3714]

That's it. Thank you very much for your effort. I've been looking for this since I knew there's RasterProp and KoS.

Edited May 22, 2016 by Adik3714

[dsonbill]

23 hours ago, Adik3714 said:

That's it. Thank you very much for your effort. I've been looking for this since I knew there's RasterProp and KoS.

I felt the exact same way - it really bugged me that it wasn't a thing, as it's so perfect for it!

And now here it is!
 

EDIT: Version 1.1 Released!

• Fixed Keyboard Input
• Fixed Tracking
• Reintegrated with BasicMFD
• API Updated

Edited May 22, 2016 by dsonbill

[DuoDex]

Moved by request

[KAL 9000]

How do you access the kOS terminal from the RPM terminal? I don't see a button for it.

[Dunbaratu]

Okay, so I installed both RPM and KPM using raw ZIPs (RPM has a warning that using CKAN is buggy and doesn't install it well).

I saw the rasterprop monitors, and found the button in the upper-left of them with the word "kOS" on it.  I clicked it twice to get it to kOS mode.

It drew the cyan outlined rectangle. (The one that on your screenshot has the words "Circularlization Burn     SAS" in it, but in mine there's no text in it yet.)

There is nothing else.  The screen is blank.  I tried pressing the Next/Prev buttons and they didn't toggle through the available kOS CPUs like it says they're supposed to.  The screen remained blank except for the cyan rectangle.  I tried typing into the kOS terminal (non-KPM one) and nothing appeared in the KPM terminal.  I tried clicking the circle button to direct keyboard input to the KPM terminal and it had no effect (i.e "W" still moved the pitch control down instead of doing anything in the KPM screen.).

What am I doing wrong?

 

[dsonbill]

1 hour ago, Steven Mading said:

Okay, so I installed both RPM and KPM using raw ZIPs (RPM has a warning that using CKAN is buggy and doesn't install it well).

I saw the rasterprop monitors, and found the button in the upper-left of them with the word "kOS" on it.  I clicked it twice to get it to kOS mode.

It drew the cyan outlined rectangle. (The one that on your screenshot has the words "Circularlization Burn     SAS" in it, but in mine there's no text in it yet.)

There is nothing else.  The screen is blank.  I tried pressing the Next/Prev buttons and they didn't toggle through the available kOS CPUs like it says they're supposed to.  The screen remained blank except for the cyan rectangle.  I tried typing into the kOS terminal (non-KPM one) and nothing appeared in the KPM terminal.  I tried clicking the circle button to direct keyboard input to the KPM terminal and it had no effect (i.e "W" still moved the pitch control down instead of doing anything in the KPM screen.).

What am I doing wrong?

 

Oh god, what have I done? >.<

Could you upload a log somewhere? I fear I've done something horrible if you of all people are having trouble getting it to work.
In the meantime, I'm going to install fresh from my spacedock download and see if it's anything obvious.

 

Edit: I'm guessing it looks something like this when you press the button? That's what it would look like if the dll didn't load up. Still not sure what would have caused this, though - it's present in the download.

EditToo: Is there any way kOS could be loading after kPM in your install? kPM is just barely named appropriately enough to load after kOS.

Edited June 7, 2016 by dsonbill

[Dunbaratu]

5 hours ago, dsonbill said:

Oh god, what have I done? >.<

Could you upload a log somewhere? I fear I've done something horrible if you of all people are having trouble getting it to work.
In the meantime, I'm going to install fresh from my spacedock download and see if it's anything obvious.

 

Edit: I'm guessing it looks something like this when you press the button? That's what it would look like if the dll didn't load up. Still not sure what would have caused this, though - it's present in the download.

EditToo: Is there any way kOS could be loading after kPM in your install? kPM is just barely named appropriately enough to load after kOS.

I put the output_log.txt here:

https://drive.google.com/file/d/0Bxkeai7oN35fOXp3SnF3M1J6aGc/view?usp=sharing

(It was too big for pastebin.)

This part looks suspicious:

AssemblyLoader: Exception loading 'kOSPropMonitor': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 
Additional information about this exception:
 System.TypeLoadException: Could not load type 'kOSPropMonitor.kOSMonitor' from assembly 'kOSPropMonitor, Version=1.0.5986.38170, Culture=neutral, PublicKeyToken=null'.
 System.TypeLoadException: Could not load type '<>c__DisplayClass62_0' from assembly 'kOSPropMonitor, Version=1.0.5986.38170, Culture=neutral, PublicKeyToken=null'.
 System.TypeLoadException: Could not load type '<>c__DisplayClass62_1' from assembly 'kOSPropMonitor, Version=1.0.5986.38170, Culture=neutral, PublicKeyToken=null'.

 

[dsonbill]

Ok, I believe the problem is you're loading up kOS 0.19:

AssemblyLoader: KSPAssembly 'kOS' V0.19

Since I'm referencing kOS atm, it has to be the same version (we're built for 0.20.1 - I should probably put this fact in the splash).

I actually though of a way that may enable 3rd party plugins to not have to reference the main kOS/kOS.Safe assemblies, but I need to think it out a bit more and maybe write up a little example.

 

 

@KAL 9000, the button in the upper right should now be "DPAI/kOS". If it doesn't appear this way, please upload a log so I can see what went wrong

Edited June 8, 2016 by dsonbill
Yay proper terminology!

[Dunbaratu]

4 hours ago, dsonbill said:

Ok, I believe the problem is you're loading up kOS 0.19:

AssemblyLoader: KSPAssembly 'kOS' V0.19

Since I'm referencing kOS atm, it has to be the same version (we're built for 0.20.1 - I should probably put this fact in the splash).
 

It's not really 0.19 either. It's a custom-built development version of kOS I have, but point taken.  If the version numbers MUST be exactly what you expected that's probably going to be a future maintenance mess.  Hopefully the new feature we're working out will help, as it will allow other mods (like yours) to add whatever variable bindings you like to kOS just by decorating one of your classes with a [KOSAddon] attribute and then kOS will detect that it is thusly decorated it and call a hook method you provide in which you can set up your desired bindings.  At least that's the general model we're going for.  Instead of you having to call KOS's DLL's methods to get things set up, kOS will call yours if you add the attribute decoration that tells it you want it to call you.

As this occurs with a bit of runtime reflection, instead of static binding, it (hopefully) won't be as sensitive to precise DLL versions having to remain the same as they were at compile time.

Edited June 8, 2016 by Steven Mading

[dsonbill]

34 minutes ago, Steven Mading said:

It's not really 0.19 either. It's a custom-built development version of kOS I have, but point taken.  If the version numbers MUST be exactly what you expected that's probably going to be a future maintenance mess.  Hopefully the new feature we're working out will help, as it will allow other mods (like yours) to add whatever variable bindings you like to kOS just by decorating one of your classes with a [KOSAddon] attribute and then kOS will detect that it is thusly decorated it and call a hook method you provide in which you can set up your desired bindings.  At least that's the general model we're going for.  Instead of you having to call KOS's DLL's methods to get things set up, kOS will call yours if you add the attribute decoration that tells it you want it to call you.

 

I've taken a look at the new API branch that's being developed, and it should at least help with the issue. No more reflection to get the SharedObjects! Yay!

It will definitely require some restructuring on my part, but it looks like it'll be perfect.
Thank you guys for working on this - I know I've probably forced you guys to take this on sooner than you would have liked.

[LabRats]

Any plans on updating this to kOS v1.0?

[Drew Kerman]

dsonbill popped up in the kOS thread last week or so saying he was interested in getting back to things. He didn't mention this specifically but here's hoping...

[dsonbill]

Sorry for the horrendously late reply! I'm definitely planning on updating this, it just needs quite a bit of refactoring to work with the new 3rd-party API. Atm, it's functionality is quite hackey. I'll try to get around to it soon though

 

EDIT: Here's a preliminary release for KSP 1.1.3, kOS 1.0.0, and RPM 0.27.1 - keep in mind this has not been altered from the old version aside from being built with the new assemblies. I'm working on adopting the new 3rd party API in kOS and fixing a few bugs.

 

EDIT 2: Version 1.2.0 released with new API! Not backwards compatible by any means!
 

http://spacedock.info/mod/712/kOSPropMonitor


EDIT 3: Just as a heads up to everyone, undocking is pretty screwed up right now. I'm trying to figure out how I want to fix it at the moment.  Undocking fixed!

 

EDIT 4: Sorry about pulling back 1.3.0. It wrote to the console constantly. I'm not going to re-release it though - we're also skipping 1.4.0 and going to 1.5.0 for what's coming next.

• Monitors all have independent states now. This is probably one of the last things that will be done with main functionality of the console.
• The arrow and enter/cancel buttons have been implemented with negative button states.
• Added a bit of new API. I've written a nice example script thing that shows off the whole API and how to set the different monitors' states.
• The new API doesn't change what you see already in the splash screen.

I'm very close to finishing this - I just have some bugs about monitor reinitialization and then it should be good to go. This may or may not be the last thing I develop for the plugin but we'll see. I have some other ideas about info panels/lights etc that may be pretty cool. I'm also open for suggestions about things that could be implemented. For now though, the flags and MFD buttons are more than enough.

 

EDIT 5: 1.5.0 Released!

 

EDIT 6: Added initial support for color terminal in repo. Possibly adding custom flag and button label color API before releasing new version.

Edited October 9, 2016 by dsonbill

[BoZo]

Any chance this brilliant mod will be updated for the newest version?

[Drew Kerman]

giving another poke for this, although @dsonbill hasn't been around for a while. Doubt any of the main kOS devs have time away from kOS itself to look into reviving this for v1.2.2 but that would be sweet. Just tested it and yea, no go

[dueb]

9 hours ago, Drew Kerman said:

giving another poke for this, although @dsonbill hasn't been around for a while. Doubt any of the main kOS devs have time away from kOS itself to look into reviving this for v1.2.2 but that would be sweet. Just tested it and yea, no go

If you want, and while waiting for an official update, you can give try this quick & untested recompile and tell me how that work for you: https://www.dropbox.com/s/8kotf6nnru6zr3a/kOSPropMonitor_RecompileForKSP1.2.2x64.zip?dl=0

(If for any reason you want me to remove this link feel free to ask, I'll do so.)

 

Edit: I forgot to include JsonFX.dll

Edited March 12, 2017 by dueb