dsonbill

DMP actually changed the way warp sync works. Instead of simply warping to their time in the future, your vessel doesn't get changed at all, and moves to the new time slot. Since there's no real advantage to doing this, it seemed appropriate.

Sorry for the incredibly late response. Most of what you're mentioning here has, in fact, been solved in DMP, and we're still client-authoritative. It even fixes some stock bugs in order to function properly. Having a fully server-authoritative system will solve most - if not all - cheating possibilities, raise the server requirements to ungodly levels, and create an overall better experience, which is what Squad should be attempting. Additionally, the movement to a new system should solve bugs inherently - most things will get a look-over and re-implementation in the move to a server-authoritative system. As for part count, the new version of KSP should help with that, but I haven't really tested it with DMP. Remember though that slowness with DMP won't translate over to a server-authoritative system, because things would work completely differently - not just with the multiplayer code, but with how the client itself works. Ships also probably need some kind of simplification for graphical representation and placement or something. Maybe individual parts are only simulated on the server-end? DMP does work with mods, usually with no changes at all. Some will require server-side plugins, but not many, and there's only a handful of plugins in existence. In the move to a server-authoritative system, mods would need to be made a bit differently to work with multiplayer, and you'd need client mods most likely too, but things would be a lot more controllable on the server side. The new system would need to have objects and game-code added on the server side as well for simulation. Single player mods would also likely need major changes depending on their functionality, as Squad would likely make the single player game work on an internal server. DMP's main issue is that we do the position and rotation stuff really weird. This could actually probably be solved with a combination of a bit of simplification/allowing the client to lie a little bit more, and increasing the update frequency. Honestly, all it would probably take to get DMP working nicely would be for me or Chris to try at that problem for a day or two. We're just burned out.

Hmmm, I haven't tested this in a little while. There might have been some changes to MKS-Lite and/or EL. Let me give it a fresh run later, and some testing - I'm going to update KSP first so I know I'm probably in the same place you are. Thanks for the report!

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.

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

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.

Actually, both vessels do get damaged (on your client), but about 30 seconds later when the next ProtoVesselUpdate comes in, everything will be fixed. On the other player's end, because they're in a different subspace, they will have no idea that any of this happened, except for maybe seeing your vessel shoot past them. On occasion, collisions do work the way they're *supposed* to in a multiplayer game, because both clients agreed on what was happening. In an official multiplayer, the weirdness of collisions should be solved mainly by being server-authoritative. If official multiplayer isn't server-authoritative, well, expect it to be like DMP, but a lot smoother. On another note, we actually could make DMP rather smooth - we just tried our best to save people's bandwidth. At the current time, we all find it quite difficult to muster up the motivation to work on DMP. Edit: So, after digging around a bit and asking @godarklight, I've found that docking ports do indeed still work, and have some funny consequences. This wouldn't be too terribly hard to fix though - just need something to disable the docking ports that have been modified in the future. You could do this either by actually disabling things, which I'm not sure is possible because I didn't check out Asm-C#, or by replacing the docking ports with a dummy part that does nothing but look nice, and at the moment continuity is upheld the docking ports get reactivated. All in all, this is pretty simple. It might sound completely insane, but such is the world of programming and especially modifying games.

In DMP, vessels in the past cannot alter vessels changed in the future. There's a simple check to take care of this. Docking ports may actually unintentionally work, now that I think about it - this could easily be fixed though.

It's amazing how people still claim certain facets of multiplayer won't work with KSP, despite the fact that DMP successfully solved all of these. Maybe it's even more amazing though, that people want to control the way in which others play KSP, a game that is literally up for shaping into any kind of game you want. GROW UP PEOPLE. AND JUST LOCK THIS STUPID THREAD.

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

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: 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.

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!

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.

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?

The thing is broken, sorry. It has nothing to do with the prop being standalone. I just fixed this a second ago - wait for the hotfix. On the topic of main RPM pages, what do you think of the following instead of converting back completely? A list of full-text pages that are settable from inside scripts, and will be accessible from RPM, separate to the main processor window. They may or may not have button pass-through. The windows will fit the standard 40x20 resolution, while the stand-alone will continue to support scritpts in 100x35. Visual keyboard indicator: I'll actually tie this to the last light or something. As for the arrow buttons, that can definitely be arranged. It'd be nice if others could chime in with their opinion on the subject as well. @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. EDIT: Version 1.0.5.1 now live - hotfix for malfunctioning processor list. Everything should be working fine again. EDIT2: @karamazovnew, I might actually know how to change the resolution in individual pages now - I'll try some stuff out. If this works out, we'll probably be switching off a stand-alone device, but people will lose at least one button. I do like the idea of using the arrows as the keyboard arrows - I haven't come up with a solution to make the camera stop moving unfortunately. EDIT 3: Version 1.0.5.2 live on SpaceDock!

Hey Steven! Sorry it's taken me an entire year to actually fix this up - I've switched over to ProcessOneInputChar, but I still find it necessary to get the processor shares for things like the BindingMgr/ As for the buttons, I've added them the same as Action Groups - you just check to see if one has changed to True and you know it's been pressed. The buttons are named buttonT0, buttonT1 etc, and the labels for the buttons are buttonT0Label, etc. I may change this if I can come up with a better naming scheme, but functionality is more important to me right now than nice identifiers. In addition to the buttons, there are lights which work in the same way for people's scripts - if you do 'SET LIGHTT0 TO TRUE.', the top left light will come on. Hopefully that made sense for now - I'll add better documentation soon hopefully! 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. Thanks for working so hard on kOS

New version 1.0.5 is out! I need to change over more props in individual IVAs, but the initial release is ready Let me know if you guys encounter any bugs, how you like the console, and if you have any requests. Known bugs: Input lag (known fix) Screwy cpu selector Button and light stuff not always set properly in all cpus(work-around possible) Probably bad IVA locations for stuff and not enough consoles(known fix) Left out arrow keys and enter/cancel buttons(easy fix) Planned Features: Logging consoles on stock RPM Fancy RPM features like graphs, vector graphics, and textures(possible, not certain) Maintenance console for certain tasks during IVA

EDIT: NVM, you guys are all doing the pods separately. I'll just have to work around you or something...

@pellinor is there any way to set a default scale that isn't actually what the default is? I'd like to make a new object from a stock one and have the default be twice as big as the original.

I'm sorry, I've neglected this mod for *far* too long. Expect an update soon hopefully. EDIT: Somehow, with @agises patch fixing my foolishness, this mod still mostly works when compiled fresh. I'm going to fix it up a bit before releasing it, still.

IMPORTANT NOTE about using patches for other people's mods: This is a non-official patch. While it will get at least one more small update, RoverDude will almost certainly make an MKS-Lite-specific patch for EL, at which point you should *not* use this. Hopefully by this time I will still be paying attention, and will remove this. This thread is probably going to be updated with a few more patches for things that may have MKS patches, but nothing specific for MKS-Lite. If any other patch - official or otherwise - is released after, please seriously consider switching to the other patch. It may actually be required for proper functioning. Always blame 3rd party patches before blaming the mods themselves. This is a simplification patch. MKS-Lite and Extraplanetary Launchpads are created by separate people, and I had no part in making their greatness. Enjoy them, and show their developers your thanks, if you can. If you're a fan of the way MKS-Lite does it's simplified resources and utilization, you'd probably like to have a simple, integrated solution for Extraplanetary Launchpads. This patch changes EL over to MaterialKits instead of RocketParts. Almost all of the items originally included with EL will be disabled, as they are not required with MKS-Lite. Installation: Install MKS-Lite Install Extraplanetary Launchpads Install EL for MKS-Lite License: This is just config files, so I'm releasing it under CC0 into the public domain. Updates: 1.0.1: Added PDUs and logistics modules to launchpads.

Nothing to see here yet. I mean there is, but you don't get to atm... I'll just post this (now better) teaser: (Some implemented and future) Features: New Fonts! Easy 2D UI! Easy World-Space UI! All major UI elements! Animated 3D holo-thing buttons! Hopefully-incredible IVA Stuff! Easy Tabs KerbalKanvas (pictured above)

Did you ever find this out? If not, you might try asking about it in #kspmodders on espernet. Someone is bound to know the answer to this, if everything you need isn't already in RPM.

This. Very much this. They've got a whole movement engine completed! Comparing this to any AAA game is inappropriate. For instance, most games (even really terrible ones) have more to do than just go from point A to point B.

Funny, I can't seem to find the 5% option anywhere?