godarklight

@cfds: Because DMP creates 20 kerbals on start so they are available for players to use, limiting the kerbals kind of implies limiting the players which is silly - We'll have to convince KSP not to do this . @hvacengi: Well I wouldn't say .... but git is nice .Keep in mind git only saves complete files (which is why it works so quickly), so your .git folder is going to grow pretty fast if you keep committing.

@TurielD (landed flag): Added it on my bug tracker so I don't forget, thanks for testing it - we'll add this workaround in after 0.2.0.0 (spectating): KSP does *not* like the active vessel dying, so we actually spawn in a duplicate (but keep it packed so it doesn't collide), wait until it loads, and then we try switching to it. Generally this works, but if you know how to trick it into stop working, then I can add fixes for it. For non-active vessel updates, the old vessel is killed first and then the replacement is put in place which is why you shouldn't see duplicates if you're not spectating. @hvacengi: Thats... and interesting use of git there . This could easily be done in either a seperate DMP plugin, or DMPServer itself, I'll add it on the bug tracker too

@Agent_Smith87: Assuming you had mod control off - yes, it's fixed in dev

@Blazku: Update to latest dev, the first release that supported 0.90 had a bug which prevented non-stock scenario modules from saving. @TurielD: Sqqqquaaaaaadddd!. If you're 100% sure that situation=LANDED landed=false should always be resolved in the landed=true manner, then I'll add this in. We already have our share of stock bug workarounds, so one more isn't going to hurt... @popos1: I actually hadn't thought of difficulty - We'll add this in if we're on career / science mode. Tracking as issue 270 @Staticxtasy: Yes and no - this is going to be tricky to solve. I've known about this one for a long time though, the terrain detail settings absolutely mess up the terrain (and even on the same setting you can still be 0.2-0.5m out). My initial thought was "Hey, lets raycast the ground and send how high the ground is in the position updates!", and while it did help most of the time, the raycast was unreliable. I'd like to work with a player to sort out this issue when I have time (will require IRC and a passing back and forth of builds), it's one of the most critical bugs in DMP and it's always been there. The branch is called raycast-ground.

@Dynd: You can spectate another player, but you currently can't both control the same ship. I intend to add a "Give control" button for the pilot to make this a little easier though. @Berserker66: No need to be mean

@Moshio: Although I have never figured this out for certain as nobody has gotten back to me about it, it should Just Work with hamachi. It's better to port forward as you're not limited to hamachi-only users, but there are some cases where that's not possible (Don't have access to the router, or you're behind an ISP level NAT). @TurielD: Thanks for the report, the more eyes on dev the more people will catch my mistakes . @Everyone: My build server hard drive decided to pull the pin today, I managed to recover everything - so it's now back online.

@Wolfmanwolf: Yes, you'll need to download mono (the MRE) and run DMPServer.exe with mono.

@Jake_tyler: Replied via email, but I'll need to catch you on IRC, your universe worked completely fine for me (and holy moly 300 asteroids...) EDIT: Actually - disabled mod control mode was broken, I've fixed it. That may have been your problem @TurielD: As a result of DMP getting more meta, I assumed that scenarios were always tagged with KSPScenario for the new "Is this module allowed in this game type" filter. That is not the case with most mods, so I've reworked it. Try dev now. @D4n13l: (Via google translate) Puede configurar un DMPModControl.txt por entrar en la ventana del cliente "Options" y pulsar " Generar DMPModControl.txt " . Mueva ese archivo a DMPServer @VITAS: No pagify

Errr... Did everyone miss the post from 2 pages ago? http://forum.kerbalspaceprogram.com/threads/79111-DarkMultiPlayer-0-1-6-2-KSP-0-25-Alpha?p=1603155&viewfull=1#post1603155 We have proper revert support on the clients (you can sync back to a quicksave and have the updates replay out), but I've decided against it for syncing a past subspace on the server - There's just far too much information to store in any type of sane way. I'm not so sure KLF still has a place when we have proper MP support - I could look into porting it to 0.90, but it's likely not all that helpful when we have DMP :-/

@burz21: I'm not terribly familiar with the mods (As a modder I play a surprisingly stock game), but it should probably work. You'll have to be a little more specific than "error" though, Are the parts coming up in the banlist? Is there vessel sync errors? ?.Screenshots or log files can also help if it's a weird problem .@jkenny23: "Known problem" is a bit of an understatement - I don't disable on win x64 like many other modders as I feel like the players should have the choice to try it, but as far as I know, this sums it up pretty nicely.

@TJ888: Yes - all the revert stuff should be back, but in subspace mode only. @TurielD: It doesn't use any extra data (as in bandwidth) at all, it only uses extra memory. A good guesstimate is how much is stored is the incoming traffic you receive - We'll have to figure out how to garbage collect this stuff so we can drop the updates before the last quicksave, but for now reverting is back at the cost of RAM (which can be disabled, as noted in the video). @X.C.M: That's the last feature I really want (It's actually shared scenario modules, which are the generic way to store data), along with vessel permissions. I'll get there

And it only took heaps of asking It's not going to be possible to sync into a previous subspace on the server, there's just *way* too much info to store, but client side this should be ok.

@Everyone, Well, KSP 0.90 dropped. I've done the port to 0.90 in dev, It hasn't had a great deal of testing but it *should* work To get it, try the development build on my build server, or use DMPUpdater-development. If you run into any issues, please come visit us on IRC or report them on the github issue tracker - I'm still hoping for a christmas release here... EDIT (Added this to OP): 0.90 NOTE Release is not yet compatible with 0.90, use the development version instead. BCSpazer has upgraded SpazerStock01 and SpazerStock02 (kerbalspace.spazer.net ports 3416 and 3417) to the development version for those that want to play 0.90. Josh has also switched one of his servers over to dev: ksp.joshgates.net port 6702. @RockyTV/VITAS: Thanks @Jansn: dsonbill hooked up the server admin console to the chat window - So yes he is a contributor. If you have problems with the script you might want to ask him specifically though, I think most people just normally just run DMPServer in a screen manually. @TurielD: Putting players into limbo isn't a bad idea, so long as I make the client try to auto-reconnect (and they never leave back to the main menu screen). There would be a timeout on this however, and it involves a few logic changes, so I'll hold off on this one.

@DuoDex: DMP doesn't insta-sync the protovessel or module states, so that's almost certainly the reason . I'd be surprised if it didn't work for your local client though.

@Jansn: I develop on Linux, the fact that it runs on windows is a handy co-incidence (So there's no shame there). I know about the TarsierSpaceTech bug, someone reported problems logging into their server and that was what caused it, the development version of the server has an explicit fix for this. But the vessels shouldn't be getting all reported as damaged, perhaps I've messed something up :-/

@TurielD: What your asking for is a little overcomplicated - Allowing people to sync into any time (correctly) would require the server persisting old states, which isn't a path I want to go down - You'd need to make 5 trips to the database per player per second and have an ever expanding database for such a small feature :-/. It would also make the initial sync worse (you'd need to sync the *entire* history). @panzer1b: Dockings have been pretty hit and miss for a while, it's just not completely clear what causes them to glitch out. I've got some ideas to try though Compression will likely help with the lag, other than that, there's not much I can do about speed of light delays. You obviously mean this - and it's not really possible so long as DMP remains an open source thing (and while I'm working on it, it always will be - I'm no long in a position to change the licence again anyway, MIT is perfect). For example, asking for random offsets / lengths and calculating the SHA sum of the files is easy to defeat and would require the whole GameData directory be available to DMPServer - Just point the client at an unused "safe" GameData directory. There's certainly things we can do to make it *harder*, but it's again not a path I want to walk down, dev clients now ignore damaged protovessels (or protovessels with banned or missing parts). They also PM the server about them.

@Andy024: The easiest way is to just auto generate a DMPModControl file by starting the client, clicking on Generate blacklist dmpmodcontrol and moving it from the ksp folder to the server folder. @Jansn: I ran into this on josh's server, it's caused by strange things happening with the vessel files (it might be a mod doing it maybe)?. The development version will warn you which files cause problems when somebody connects, just copy the universe folder to a dev server and remove the bad entries

@StrahmDude: On what server? - I believe josh had an error on his and decided to restart it, the development version has a bugfix related to this. I'd need more information though to give you a more correct answer, such as the server log. @longbyte1: (auto-)dekessler *only* deletes debris, and nukeksc is disabled by default. @TurielD: This is related to how subspaces work on DMP - DMP sends you to the latest 'time' as it only saves the latest state. If a player warped 100 days and left, you'd be 100 days in the future .

Hello everyone! - My DMP alert was set off. I've definitely got a little way to go before I can work on supporting other mods, but BDA is a fairly common request as it makes sense for battle servers. Currently DMP does not let a player update other players active crafts, so when you shoot parts off someone they never see it. As for nukes?, well that's a PvP problem and I'm generally a co-op guy EDIT: Parts must be explicitly allowed already, nukes (as a part) would not be a problem.

@Nemrav: The ability to de-sync is what makes the whole concept of multiplayer possible, without it you either have to force everyone to warp all at once (which is a little meh), or disable timewarp completely. Sync is there for a reason, you'll learn to love it one day (Or you can change to MCW_VOTE in DMPServerSettings.txt). @Jansn: I probably should get around to adding in support for that, although I play a mostly stock game so I'm unsure what everyone uses. Do people want stock-only support, blizzy-only support, or stock fallback if blizzy isn't installed? @VITAS: Thanks for running the server list - I'll have to double check to make sure the reporter is stable, but other than that, looking good!. @longbyte1: It's more official than this, and I run this thing @ATJ63: I do that myself while testing DMP, it works most of the time, but sometimes you can get a loading hickup and all your parts will be missing.

@Jansn: You're welcome, I'm glad people are enjoying DMP 3a) Yes, the initial folder gets copied to the playername folder the very first time they connect to the server, if you want new players to join in with the same seed (deposit locations), this is the only way for now. The amount of deposits will all be different for different players however, 2 players can scan at the same time but they'll each have their own scan map. 3b) The plugins folder is the DMPServer equivalent of KSP's GameData/ folder, it's for DMPServer mods/plugins. Currently the only plugins available are the DarkChat IRC connector, and the public server list reporter (and development reporter) The plugins folder is not for KSP mods. For mods, use the options -> generate whitelist/blacklist DMPModControl.txt and move it to the server folder

@beabop: The autogenerator should have put it in the right spot . Part adding mods should always be added to the required section otherwise you'll throw errors when you try to join the server. Non part adding mods go in optional so someone playing stock, and maybe someone with kerbal alarm clock can join in the server (KAC doesn't affect the other play in any way whatsoever). EDIT: @mirodasc: Welcome to the forums! I'm doing my best to release on christmas

@Space Cowboy: I run 2 instances from the same folder all the time - most of the times it works, but you run the chance of the part files being locked on load, sometimes (maybe 1 in 10), some, or all, of the parts go missing. Running from seperate KSP folders should always work. @beabop: Hrmm, That's certainly an odd one, are you sure you're definitely editing DMPModControl.txt on the server?. I also just tested the autogeneration, it works for me. Btw, the path is relative to gamedata and uses forward slashes. 'engineer/engineer.dll' is correct here. If you're sure you're editing the DMPModControl.txt file on the server, drop by on IRC, something has gone wrong . @Sampa: It depends on the settings, on blacklist mode you're allowed to have any mods apart from the ones specified, but the parts are still under a whitelist. By default it just doesn't let you sync that vessel to the server, but you can still launch with it. The public servers usually have whitelist mode where you can only join with a very specific set of mods. Also remember that DMPServer doesn't actually use the mods, to it vessels are just text files that it passes along

@FinnishGameBox/TheGatesofLogic: What Ippo means is that these aren't normal windows EXE's, they are .NET framework ones. If you're on mac, you'll want to download mono from http://www.mono-project.com/download (The MRE), if you're on linux, you'll want to install it from your package manager (apt-get install mono-complete on debian and ubuntu). Then you open the exe with mono

My nyancat alert was set off - Hello everyone! @Senshi: There's a program here that uses Mono.Cecil to change all sizeof IntPtr calls to '4', which will likely prevent all 64 bit checks working, the mod will think it always runs on 32bit (unless the mod has written a dynamic assembly in IL, which does not sound likely). https://github.com/cerebrate/x64-unfixer. I'm unsure if you want to go down that path, but it should certainly work and help you keep up to date with mod releases. @Furious1964: And some modders do care about 64 bit support (me), so long as the player accepts that Win64 *will* crash more often. If you have a lot of mods the current recommended way is to run 32bit with --force-opengl, it massively cuts KSP's ram usage.