dsonbill

I'm incredibly familiar with Moonsharp, as I'm using it extensively for a personal project. I've created a system that runs lots of scripts all in different threads - I have no simple interlink to unity values, but that's not too hard to bridge over, as I did it with this for a small project for another game that I ended up not releasing. More on the system mentioned: While I never intended for this stuff to make its way into KSP, I might think about building a new mod with that instead which integrates with MAS. It could bring good research for its eventual use in its intended home. I've also been forced to modify Moonsharp to allow for some dirty execution, so I may need to find a way to consolidate the fact that I need that version loaded, while you are probably using another version of Moonsharp. I may just rename everything to Moonderp.

What's the timetable feel like for MAS? I know this is an awful question to ask. If you foresee it taking long enough, I might just play around with this a whole lot more.

Well, the background handler still works, and the monitor still works as usual - I kept the PFD in there just for fun: The data from the pages obviously can't be displayed as it's been stripped down to nothing - only the content processor can write to the console now. kOSPropMonitor already exists here - that's what's being overlaid onto the PFD above. (The labels are off because I just learned about [hw], somehow). The only functionality that's really broken is page switching, which isn't that big of a deal. It wouldn't be too hard to rebuild a lot of what RPM does with kPM for the MFDs, but it would be a lot of work. I'm not really sure how far I want to take this. It might be time to pick through MAS instead of RPM. I really need to decide if it makes any sense to integrate kOS into it, or go for a standalone prop.

This is a somewhat hard one to do if you aren't experienced. There's 3 or 4 files and like 10 functions you need to write to do this, though it's mostly copy-pasting and adjusting for radiator rather than solar panel. Then you have to make the props and add them to IVA. I might do this. I already see a lot of what needs to be changed.

@MOARdV What would you recommend I do with kOSPropMonitor? I always kind of wanted it to have a lot of interface into RPM - the variable system, buttons, and MFD. Right now, it's a nice MFD page that gives the ability to read all the buttons in kOS and display and capture input from IVA. Now that you're moving on to MAS though, I'm not sure where this all fits in. Maybe I'll just start ripping RPM apart or something. Edit: Currently reading documentation for MAS Edit 2: And it works too. What have I done. What a sight! Here's the repo - https://github.com/dsonbill/SimpleMFD Take a look at this too, if you get the chance: https://github.com/dsonbill/SimpleMFD/commit/aec84a6689c43a379a7be1fd9c180712af03a8c1

@alexustas I'm updating kOSPropMonitor to the latest version of KSP and kOS and maybe adding a few more features. Would you like me to maintain a patch for ASET MFDs? Also, I see on your YouTube channel that you have a version of the kOS Terminal prop where the numpad is working. Will you be making all the keyboard buttons work, or do they already? I can add a thing to make the buttons function for kOSPropMonitor.

That looks really great, and I understand what you want from the page thing. I have a rough idea of what I'll do for the page system - I'll write something up soon. I'm setting up my dev environment now and testing the new versions. There probably isn't anything broken with kPM so far, so this probably won't take long. I know that is something a lot of programmers have thought, though.

Sounds like something that would also be useful inside of RPM. RPM has it's own font thing, and I'm not sure how it'll work with other languages once that is implemented. I'll either have some sort of work around or I'll start working on doing something similar for RPM when the time comes.

This is exactly what it is! So don't use it for that! The beauty of the template that I posted is that you can easily remove the flag panel if you don't like it, and replace it with more lines of code Your kPM/Library/Patches/Patch.cfg would look like this: //@INTERNAL:NEEDS[kOS|kOSPropMonitor]:FINAL //{ // @PROP[RasterPropMonitorBasicMFD] // { // @name = kPMDisplay // } //} @PROP[RasterPropMonitorBasicMFD]:NEEDS[kOS|kOSPropMonitor]:FINAL { @MODULE[RasterPropMonitor] { //Make All Buttons Except G Global @globalButtons = button_UP,button_DOWN,button_ENTER,button_ESC,button_HOME,button_RIGHT,button_LEFT,buttonR9,buttonR10, button_STBY, buttonR1, buttonR2, buttonR3, buttonR4, buttonR5, buttonR6, buttonR7, button_A, button_B, button_C, button_D, button_E, button_F // Change Home Page @PAGE[home] { @text = kPM/Library/Patches/kOS_home40x20.txt } //kOS Page Definition PAGE { //Main name = kOSRPMPage button = button_G textureURL = kPM/Library/Textures/kPM40x20Alt disableSwitchingTo=pluginEngineIgnitor,pluginVesselView,sas,smartass,targetmenu,graphs,aviapfd,navball,extcamAll,resources,flightlog,crewinfo,shipinfo,targetcam,orbitgraphical,orbit,map,description,test,home PAGEHANDLER { //Class name is kOS Monitor name = kOSMonitor //This is the terminal template template = kPM/Library/Terminals/terminal40x20.txt //This is the highlighting replacements = kPM/Library/Replacements/default.json //Processors are named sanely method = ContentProcessor buttonClickMethod = ButtonProcessor //Labels buttonEmptyLabel = LABEL flagEmptyLabel = FLAG //kOSProcessor TermWindow consoleWidth = 40 consoleHeight = 17 //ADJUSTED FOR REMOVING THE FLAG PANEL //Text Tint textTint = [#009900ff] textTintUnpowered = [#ffffff3e] } } } } And your kPM/Library/Terminals/terminal40x20.txt would look like this: {buttonLabel0} {buttonLabel1} {buttonLabel2} {buttonLabel3} {buttonLabel4} {buttonLabel5} EXIT [#60F8F9]CPU: {currentCPU} [#60F8F9]ID: {GUID} {keyboardFlag} {l1} {l2} {l3} {l4} {l5} {l6} {l7} {l8} {l9} {l10} {l11} {l12} {l13} {l14} {l15} {l16} {l17} {buttonLabel7} {buttonLabel8} {buttonLabel9} {buttonLabel10} {buttonLabel11} {buttonLabel12} {buttonLabel13}} I'll try to think about a better cursor. It may be very possible now that you mention it. I have something in mind that you will be very happy about if I get to it. I may just have to write my own RPM background handler finally.

Bugs: 1. Yeah, complete garbage. I'll look into fixing this one again. 2. This is not the ID of the cpu, but rather the ID of the monitor, which is completely useless to you guys since I made it so you just access them based on their number. I'll look into making this the CPU tag instead, since it makes much more sense. 3. Yeah, probably can't fix that one. Suggestions: 1/2. Can be handled mostly with the template system. I'll post the template here so you can see what it looks like: {buttonLabel0} {buttonLabel1} {buttonLabel2} {buttonLabel3} {buttonLabel4} {buttonLabel5} EXIT [#60F8F9]CPU: {currentCPU} [#60F8F9]ID: {GUID} {keyboardFlag} [#60F8F9]FLAG {flagLabel0} {flagLabel1} {flagLabel2} {flagLabel3} {flagLabel4} {flagLabel5} {flagLabel6} [#60F8F9]PANEL {flagLabel7} {flagLabel8} {flagLabel9} {flagLabel10} {flagLabel11} {flagLabel12} {flagLabel13} {l1} {l2} {l3} {l4} {l5} {l6} {l7} {l8} {l9} {l10} {l11} {l12} {l13} {l14} {l15} {buttonLabel7} {buttonLabel8} {buttonLabel9} {buttonLabel10} {buttonLabel11} {buttonLabel12} {buttonLabel13}} Also, the buttons can be reassigned from the config file. 3. Having multiple pages per monitor would be a huge benefit. I was thinking about doing this for a while, but I'm still thinking of an implementation. This may be the big addition for this release - we'll see how it goes. And yeah, the color thing. We'll see. Also definitely interested in implementing the vector graphics from RPM - I'll take a look into that this time around as well. Here's some information on the color system. The replacements file isn't even included in the git repo, so that may cause some weirdness with the version you guys are using. Here's the preliminary replacements file I'd made: { "run ": "{CUSTOM1}run {COLOR}", ".ks": ".{CUSTOM1}ks{COLOR}", "local ": "{CUSTOM2}local {COLOR}", "global ": "{CUSTOM2}global {COLOR}", "is ": "{CUSTOM2}is {COLOR}", "until ": "{CUSTOM2}until {COLOR}", "wait ": "{CUSTOM2}wait {COLOR}", "lock ": "{CUSTOM2}lock {COLOR}", "unlock ": "{CUSTOM2}unlock {COLOR}", "set ": "{CUSTOM2}set {COLOR}", "to ": "{CUSTOM2}to {COLOR}", "function ": "{CUSTOM2}function {COLOR}", "return ": "{CUSTOM2}return {COLOR}", "if ": "{CUSTOM2}if {COLOR}", "parameter ": "{CUSTOM2}parameter {COLOR}", "list ": "{CUSTOM2}list {COLOR}", "switch ": "{CUSTOM2}switch {COLOR}", ":": "{CUSTOM3}:{COLOR}", ".": "{CUSTOM3}.{COLOR}", ",": "{CUSTOM3},{COLOR}", "<": "{CUSTOM3}<{COLOR}", ">": "{CUSTOM3}>{COLOR}", "=": "{CUSTOM3}={COLOR}", "*": "{CUSTOM3}*{COLOR}", "/": "{CUSTOM3}/{COLOR}", "+": "{CUSTOM3}+{COLOR}", "-": "{CUSTOM3}-{COLOR}", "(": "{CUSTOM3}({COLOR}", ")": "{CUSTOM3}){COLOR}", "true": "{CUSTOM4}true{COLOR}", "false": "{CUSTOM4}false{COLOR}", "{CUSTOM1}": "[#4286f4]", "{CUSTOM2}": "[#EFCE39]", "{CUSTOM3}": "[#9D39EF]", "{CUSTOM4}": "[#291FE2]" } This is handled by the FreeFormat function, which uses the ReplaceString function: public static string FreeFormat(string input, Dictionary<string, object> p, bool toUpper) { if (toUpper) { foreach (KeyValuePair<string, object> kvpair in p) input = ReplaceString(input, kvpair.Key, (kvpair.Value).ToString().ToUpper(), StringComparison.InvariantCultureIgnoreCase); return input; } foreach (KeyValuePair<string, object> kvpair in p) input = ReplaceString(input, kvpair.Key, (kvpair.Value).ToString(), StringComparison.InvariantCultureIgnoreCase); return input; } public static string ReplaceString(string str, string oldValue, string newValue, StringComparison comparison) { StringBuilder sb = new StringBuilder(); int previousIndex = 0; int index = str.IndexOf(oldValue, comparison); while (index != -1) { sb.Append(str.Substring(previousIndex, index - previousIndex)); sb.Append(newValue); index += oldValue.Length; previousIndex = index; index = str.IndexOf(oldValue, index, comparison); } sb.Append(str.Substring(previousIndex)); return sb.ToString(); } I'll get back to this post soon on why it's written like that. I guess it's never too late to document your code. All I can say is wow. Here's a list of every variable that you can set from the config file, kPM/Library/Patches/Patch.cfg: //Buttons [KSPField] public int processorSelectorUpButton = 7; [KSPField] public int processorSelectorDownButton = 8; [KSPField] public int connectButton = 4; [KSPField] public int toggleProcessorPowerButton = 9; [KSPField] public string multiFunctionButtons = "17,18,19,20,21,22,23,10,11,12,13,14,15,16"; //Directional Buttons [KSPField] public int upButton = 0; [KSPField] public int downButton = 1; [KSPField] public int leftButton = 6; [KSPField] public int rightButton = 5; //Enter and Cancel [KSPField] public int enterButton = 2; [KSPField] public int cancelButton = 3; //Terminal Fields [KSPField] public int flagCount = 14; [KSPField] public string template = ""; [KSPField] public string replacements = ""; [KSPField] public string buttonSide = "##########"; [KSPField] public string buttonSideSmall = "#"; [KSPField] public string buttonEmptyLabel = " "; [KSPField] public string flagSide = "##########"; [KSPField] public string flagSideSmall = "#"; [KSPField] public string flagEmptyLabel = " "; [KSPField] public string textTint = "[#009900ff]"; [KSPField] public string coloredTextTint = "[#ffffffff]"; [KSPField] public string textTintUnpowered = "[#ffffff3e]"; [KSPField] public string textTintButtonOn = "[#009900ff]"; [KSPField] public string textTintButtonOff = "[#ffffffff]"; [KSPField] public string textTintFlagOn = "[#009900ff]"; [KSPField] public string textTintFlagOff = "[#000000]"; [KSPField] public string keyboardActiveLabel = "KBRD"; [KSPField] public string keyboardActiveTint = "[#FFF72B]"; [KSPField] public string keyboardInactiveTint = "[#000000]"; [KSPField] public int consoleWidth = 40; [KSPField] public int consoleHeight = 20; [KSPField] public bool longGuid = false; [KSPField] public bool coloredTerminal = true; [KSPField] public bool replacementsToUpper = false; These are the things you can set in the pagehandler: //@INTERNAL:NEEDS[kOS|kOSPropMonitor]:FINAL //{ // @PROP[RasterPropMonitorBasicMFD] // { // @name = kPMDisplay // } //} @PROP[RasterPropMonitorBasicMFD]:NEEDS[kOS|kOSPropMonitor]:FINAL { @MODULE[RasterPropMonitor] { //Make All Buttons Except G Global @globalButtons = button_UP,button_DOWN,button_ENTER,button_ESC,button_HOME,button_RIGHT,button_LEFT,buttonR9,buttonR10, button_STBY, buttonR1, buttonR2, buttonR3, buttonR4, buttonR5, buttonR6, buttonR7, button_A, button_B, button_C, button_D, button_E, button_F // Change Home Page @PAGE[home] { @text = kPM/Library/Patches/kOS_home40x20.txt } //kOS Page Definition PAGE { //Main name = kOSRPMPage button = button_G textureURL = kPM/Library/Textures/kPM40x20Alt disableSwitchingTo=pluginEngineIgnitor,pluginVesselView,sas,smartass,targetmenu,graphs,aviapfd,navball,extcamAll,resources,flightlog,crewinfo,shipinfo,targetcam,orbitgraphical,orbit,map,description,test,home PAGEHANDLER { //Class name is kOS Monitor name = kOSMonitor //This is the terminal template template = kPM/Library/Terminals/terminal40x20.txt //This is the highlighting replacements = kPM/Library/Replacements/default.json //Processors are named sanely method = ContentProcessor buttonClickMethod = ButtonProcessor //Labels buttonEmptyLabel = LABEL flagEmptyLabel = FLAG //kOSProcessor TermWindow consoleWidth = 40 consoleHeight = 15 //Text Tint textTint = [#009900ff] textTintUnpowered = [#ffffff3e] } } } }

Sorry for such a late reply, but take a look at what I've done. kOSPropMonitor is certainly not just theoretical. It works quite well, though scale is a thing. I'm here to inquire about when I should make my next release. It seems that every time I get back here, I release the thing right before you guys break it I'm still reviewing my code and kOS, and it looks like everything is pretty much OK from this preliminary stage. I'm assuming now no one really know from what Steve said, so I'll definitely be working off public release for now. I'll likely have to do a little bit once you merge dev in, but it's nothing I can't handle once I remember to come back and work on this again. Cheers.

@Stone Blue You can use your physical keyboard with the BasicMFD. I can do the iva keyboard as well though.

Lol oh god, did you release master? It's perfectly fine, but I wasn't really planning on releasing the color thing - it's kinda built like crap. I'm sorry if this is super complicated to use. I don't even remember how to use it at this point, but I'll make a point of updating this soon. It'll only take me a moment to remember everything and figure out what has changed. kOS is a very fluid mod, though a lot of the bits I now use shouldn't have changed much. Much of what you want is possible with alterations to the template files. I don't have a system for outlining the screen right now, not sure if that's something that happened with RPM while I was away. It's easily doable though. Check out the files that come with the thing. You can see how the screen is templated so you can change the layout quite easily. The background is provided by an image file. Also make sure to check out how configurable everything is in the rpm config file. I'll make more detailed information at a later date if it's not already in the OP. Cheers. More Importantlel Information I'm going to be downloading a copy of clean, latest version of KSP tonight and the newest version of kOS. If anyone has any more suggestions for the mod or gripes, now is definitely the time to bring them up. @Sebra if you'd like the template to change, please make the adjustments you'd like and post the template on here. If I like them, I may include them. You can also do a pull request on git if you'd like your name on the stuffs. Either way if I use your changes, I'll include you in the OP and on the repo. Also please tell me if you guys think the color feature is worth a ridiculous amount of text.replace. It's probably not.

IPC is interprocess communication, but I guess this is interprocessor communication, heh.

Not really sure what's going on here - I need someone to take a look. https://www.youtube.com/watch?v=5SVr5ZLRrRg The GUIDs are being generated by the following code: https://github.com/dsonbill/kOSPropMonitor/blob/master/src/kOSPropMonitor/kPMAPI.cs#L53 (which is called by kPMCore in its update) and https://github.com/dsonbill/kOSPropMonitor/blob/master/src/kOSPropMonitor/kOSMonitor.cs#L116 (which is called by KSP or RPM) Also not sure why two with the same vessel id are already showing up per-vessel. They are added on object creation to the vessel_registry in kPMCore and called from a list on the contained object. Their update function won't be called unless they added to kPMCore's vessel_registry with their shared.Vessel.id. I'm going to restructure how the values are set and accessed soon, but I'll still need to get the vessel track object via shared.vessel.id. EDIT: So I guess the shared objects are passed in as the stuff is called or something, because it just kind of works after restructuring to a saner approach. See https://github.com/dsonbill/kOSPropMonitor/blob/master/src/kOSPropMonitor/kPMAPI.cs for sane approach, and look at last commit for errors. Everything works perfect now. By the way, is IPC possible in stock kOS? Consumer.ks: set flags to addons:kpm:flags. flags:setstate(0, true). flags:setstate(1, true). flags:setstate(7, true). flags:setstate(8, true). flags:setlabel(0, "RUNMODE:"). flags:setlabel(7, "ID:"). flags:setlabel(8, "0"). lock runmode to flags:getlabel(1). set id to "0". until runmode = "00" { if flags:getlabel(5) = id { if runmode = "0" { clearscreen. print("CPU Waiting..."). } if runmode = "1" { clearscreen. print("Doing Something!"). } } }

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.

@hvacengi, was the 3rd party API ever merged or something? I can't seem to find it in your branches any more. I've been working on my own game so KSP hasn't been getting much love, but the new version incoming made me want to take a look at kOS again

Remember how we were all impressed that Bethesda was pushing for console mods? While this indeed came to fruition on Microsoft's console (huge props to MS - but they still appear to be the unpopular console this gen), Sony has officially said no. This probably isn't too big of a shock to anyone that at least understands how modding works, and knows Sony's past with console hacking/modification. Pick your poison of sauce: https://www.engadget.com/2016/09/09/sony-bethesda-ps4-mods/ https://www.destructoid.com/sony-to-bethesda-no-mods-on-playstation-4-385784.phtml http://kotaku.com/bethesda-says-sony-wont-allow-skyrim-or-fallout-4-mods-1786431292 http://www.ign.com/articles/2016/09/09/bethesda-sony-has-blocked-fallout-4-and-skyrim-mods-on-ps4

They most certainly are focused on it - though seem to be insistent on not making official announcements regarding it. The only reason I know anything is because I spent quite a lot of time on IRC, but the information I have is extremely limited, and shouldn't be repeated no matter how minimal - I can only give my own interpretation of that information, in good conscience. But just because they've done a decent buttload of work doesn't mean you'll see a release any time soon, and that may be the reason they refuse to give official statements on the subject.

Your assumption that adding multiplayer will somehow detract from anything is false, because things don't work like that with software development - working on a specific part will never detract from things that aren't going to be worked on to begin with. Multiplayer has been in the works for a while now. More of it has been developed than you've been told. I can only extrapolate from things I've known for quite a while, and that leads me to believe there is a significant portion of the work done already, especially since they haven't rescinded their promise of delivering multiplayer. You may want people not to encourage Squad, but it's far too late for that. Work has been done, and multiplayer is coming regardless if you like it or not.

As I already said, this is the opposite of what would happen. Tons of single player bugs would be fixed as the movement from a monolithic system to an internal server based one happened. In a server that's focused on flight on kerbin and not wanting to warp, I doubt you'd want to go to another planet. You're ignoring that KSP can be many different kinds of game, which was the entire point of my post.

I don't necessarily agree. Sure it may be easier from the ground-up, but translating over is actually not that hard. You basically move what you have over to server code, and make a new way to connect to it. Then you move specific parts off onto the client, and you're pretty much good to go. The client does kind of need an internal simulation for lag compensation and such, but they may not really focus on that. The reason DMP is so strange is because we're client-authoritative, and that's not something the scope of a mod can or should ever attempt to remedy. Being server-authoritative would mean running a majority of the game code on the server, and we're not licensed to do something like that. We could always do *something* like it with Principia or something, but I don't see anyone wanting to do that.

I doubt Squad would be stupid enough to try and create a centralized server system. It would probably work more like Minecraft, where there weren't even official servers offered for most of it's life.

I don't understand - you want to play without people warping and syncing, and that's how you do it - by removing warping and syncing. KSP can be any kind of game you want, and that's why people enjoy it. Translating this to a multiplayer format is not that hard, and you can have servers that focus on any number of play styles.

Then what you want is a server that doesn't allow time warping, which is trivial.