godarklight

@PringleMan: I have no idea to be honest - DMP only loads the science once and I've never actually tested another load after the game has started. It could work, or it might not. It definitely should be possible though... You might also be interested in shared science, I'll integrate that from JoshBlake's custom branch after groups / vessel permissions are in dev - He had it working in 0.23.5 (shared kethane and everything too!). @KerbinUser: If the server is running in blacklist mode (the default), all mods are allowed. If this is your own server, you can simply hit options -> generate blacklist DMPModControl.txt and copy if from your KSP folder to your server folder. @Talavar: DMP can get a little confusing in some areas, so I'll gladly point you in the right direction. Also, I do some pretty strange things which might need explaining After typing (although visual basic did have this, I remember dim blah as type was optional) and semicolons become second nature, it shouldn't be too hard to work out most areas do . The biggest problem is the lack of a debugger, I generally resort to (the equivalent) of sprinkling UnityEngine.Debug.Log absolutely everywhere.

@Lamper: It *should* be possible, if it's not then I have positioning bugs to work out . The twitching is caused by the position updates coming in, but it looks like DMP (most likely) or KSP (not as likely, but possible) is having trouble placing things accurately enough. The mods shouldn't affect positioning. DMP generally tries to act how you would expect for a multiplayer mod, and anything you can't do in multiplayer that you can do in stock singleplayer is a bug. The one exception is the handling of subspaces/updates, where things from the past affect the future instantly, but things from the future are held until your time passes the update. @Preliator/agises: +1 for screen: #Start screen -dmS DMPServerDevelopment mono DMPServer.exe #Attach to the screen screen -rS DMPServerDevelopment #Detach from inside screen (ctrl+a, d) #Stop from inside screen /quit reason -or- ctrl+c #Stop from outside screen screen -S DMPServerDevelopment -p 0 -X stuff "/quit Stopping server\n"

@Talavar: I could show you around DMP, but it's easier to come visit me on IRC . As for programming itself, I wouldn't dare try to learn C or C++, those languages seem painful to get anything done . I'm actually completely self taught (which probably reflects in my code), and actually come from a bash/php background (with a bit of visual basic many years ago). C# is very similar to java (although I have never used java), but C# is syntax isn't too difficult if you've had experience with basically any language. If programming was my job, I probably wouldn't like it as much as I do The biggest way anyone can help though is bug reports with reproduction steps, "I tried docking to a player that was in the future and my vessel disappeared when I synced" (Yes, this does happen, and I'll get there, time paradoxes can be fun). As far as 0.1.5 is concerned, my biggest targets are "players explode while they are near each other", and "docking to another player causes an explosion", which is something that I don't believe happened in 0.23.5 (at least not as badly).

@ChrisGuy: That webpage is your router config, you'll need to find something called "Port forwarding" or "Virtual Servers" depending on your router brand @Talavar: I'd expect that binding to 0.0.0.0 (the default) should bind on all adapters regardless of any type of routing order, including hamachi's. It should Just Work .

@Talavar: I'll see if I can poke the docking bug today, Nothing changed in the way of docking as far as I can see, but it may be possible that 2 craft manage to dock at the same time due to the position fix (perhaps). I'll have to pick one as the new pilot and only let one docking happen at a time, instead of both in both update weirdness that can happen now @ChrisGuy: As far as I know it should just work, DMPServer by default listens on all addresses, which *should* include hamachi. If it doesn't, you could try setting the 'address' setting in DMPServerSettings.txt, although that will stop all other addresses apart from the one entered from working (Eg, you won't be able to connect to 127.0.0.1, which shuts out all non-hamachi users). I would recommend port forwarding, but some people aren't in the position to port forward. @Lamper: There is one case where hamachi would be required, although I'm not sure how well hamachi could sort out this mess. If you don't have a public IPv4 address, you cannot portforward. Or if you don't have access to the router management page. The solution to that mess above is /dmp/"]IPv6, but don't hold your breath on that one, nearly nobody is doing it @Alshain: DMP certainly does have its fair share of bugs, and 0.24 did hurt DMP. There is defensive code preventing science from wiping if it fails to load, so it's interesting that it managed to get wiped in the first place . If I manage to understand KSP's weirdness, things will be better in future versions

This sounds like it's getting a tad out of control - but I'll weigh in By default, mods should run on all platforms and processors, But that likely depends on not having external dependancies. I've developed DarkMultiPlayer on Linux-64 exclusively, because that's the only machine I have, and I don't see the point of using the 32bit one when the 64bit one runs perfectly. I don't own windows, so I cannot test for windows-specific bugs, although RockyTV/JoshBlake have poked a few little bugs in that area. Prior to KSP 0.24, All builds were 32bit builds as that was my monodevelops default setting and I never bothered to change it. Afterwards, I switched to "AnyCPU" which compiles for both in the 1 assembly (kinda). KSP64 can load 32bit assemblies just fine, so we're unlikely to see mods that require a specific platform / CPU unless you're doing something outside of KSP, like the work-in-progress principa mod which is written in a mix of C#/C++. Compiling to 64bit only or providing different 32/64bit assemblies sounds quite unlikely to me when AnyCPU is just a click away.

@PhoenixTheSage: The reason why full crashes aren't helpful probably isn't immediately obvious, but I'll show you the difference: This is all KSP stuff, along with heaps of missing information. This trace is useless: (0x00000000118DD195) (Mono JIT code): (filename not available): ProtoVessel:Load (FlightState) + 0xe35 (00000000118DC360 00000000118DD208) [0000000002254D48 - Unity Root Domain] + 0x0 (0x00000000118DC2EC) (Mono JIT code): (filename not available): FlightState:Load () + 0x6c (00000000118DC280 00000000118DC32E) [0000000002254D48 - Unity Root Domain] + 0x0 (0x00000000118DC20B) (Mono JIT code): (filename not available): Game:Load () + 0x9b (00000000118DC170 00000000118DC24D) [0000000002254D48 - Unity Root Domain] + 0x0 (0x00000000118D6EFF) (Mono JIT code): (filename not available): SpaceCenterMain/:MoveNext () + 0x16f (00000000118D6D90 00000000118D7413) [0000000002254D48 - Unity Root Domain] + 0x0 (0x0000000003F2D0CB) (Mono JIT code): (filename not available): (wrapper runtime-invoke) <Module>:runtime_invoke_bool__this__ (object,intptr,intptr,intptr) + 0x6b (0000000003F2D060 0000000003F2D15C) [0000000002254D48 - Unity Root Domain] + 0x0 (0x000007FED91236CA) (mono): (filename not available): mono_set_defaults + 0x2b8e (0x0000000029C69A68) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x00000000FFFFFFFF) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000002254D48) ((module-name not available)): (filename not available): (function-name not available) + 0x0Use(0x0000000103A60000) ((module-name not available)): (filename not available): (function-name not available) + 0x0 These ones are helpful, they aren't full crashes. Throws give me a trace of where things have messed up, and although this is actually a bug inside of KSP, DMP is quite capable of working around it: at Contracts.Templates.RescueKerbal.OnSave (.ConfigNode node) [0x00000] in :0 at Contracts.Contract.Save (.ConfigNode node) [0x00000] in :0 at Contracts.ContractSystem.OnSave (.ConfigNode gameNode) [0x00000] in :0 at ScenarioModule.Save (.ConfigNode node) [0x00000] in :0 at DarkMultiPlayer.ScenarioWorker.SendScenarioModules () [0x00000] in :0 at DarkMultiPlayer.ScenarioWorker.Update () [0x00000] in :0 at DarkMultiPlayer.Client.Update () [0x00000] in :0DarkMultiPlayer: Threw in UpdateEvent, exception: System.NullReferenceException: Object reference not set to an instance of an object I can't speak for squad or unity with respect to 64-bit issues, but DMP is now compiled on the AnyCPU setting, so it shouldn't matter whether you use 32 or 64 bit (It didn't really matter anyway, it worked fine as a 32bit assembly). I've developed DMP exclusively on linux 64, although RockyTV/JoshBlake have taken care of a few windows specific things . @Alshain: 1) should definitely not be happening - DMP doesn't really do anything in the VAB/SPH window, Can you try removing all mods except DMP to see if you can reproduce it. It definitely works on my computer... 2) Usually caused by NullReferenceExceptions in the GUI drawing thing - Can you upload output_log.txt and either PM or link it in the thread so I can hunt it down? - I haven't come across this one yet. Window positions) To be honest, this annoys me enough that I'll probably do this today Integration into the new toolbar) Not a bad idea, but there's a few things I'd like to take care of before this one happens. @Mattdogking: 0.1.4.2 did not support 0.24 and brought up that error during sync as they changed the kerbal roster and the way the game start works. I released 0.1.5 as it made sense to have a mostly working version for 0.24, rather than telling people to use dev. @Talavar: Firewalls should have nothing to do with unhandled error during sync - "Unhandled error while syncing" generally means DMP failed to do something it really needed to do, like load a kerbal or vessel into the game, which 0.24 caused by the CrewRoster -> KerbalRoster change. Firewall problems usually are along the lines of "Failed to connect - no reply", "Connection error: The connection was aborted by software in your host machine", or "Connection error: The connection was terminated because the remote machine actively refused it" (From memory).

@popos1: Options -> Generate DMPModControl.txt should be what you're looking for @Squamble: Unfortunately crash logs aren't too helpful for me - These generally suggest bugs in KSP itself (Nothing in DMP should crash KSP, but it gets a bit sensitive in some areas). Also - I did update DMPUpdater to recognise the 64bit file, But it's very interesting that they just didn't ship both version in 1 like they do with linux :-/. Just redownload DMPUpdater and it should be good @inigma: I'll rewrite the server scraper today, It's long overdue, the current one doesn't scale to over 100 servers very well @NedStar: I definitely added those parts, but you may have to regenerate DMPModControl.txt (delete it if you're running stock) for the new parts to show up. Or just add those 2 lines I guess @Everyone: I've decided to bite the bullet and release 0.1.5.0, There might (probably will) still be weirdness around, but it's much better having a version that mostly works as release, compared to one that doesn't work at all for 0.24. There likely will be a few point releases for this series...

@Everyone: I found some more sillyness in the development version which should now be fixed. I messed up the contracts filter (RescueKerbal causes a great deal of problems for DMP, so I remove them), which caused all contracts to be lost. This bug should now be fixed. Missing kerbals from ProgressTracking.txt caused a NullReferenceException inside KSP. This bug now should be fixed - A randomly generated (renamed) kerbal now takes the missing kerbals place. Everyone using dev should definitely update to 621baf5 (DMPUpdater does come in handy ) - This version could potentially become 0.1.5 if no weirdness comes up. If something does comes up, make some noise in this thread or try to catch me on IRC.

@YellowDart: That would be the reason 0.1.5 hasn't been released yet: Bug #172 @pospos1/Squamble: Dev works with 0.24.x, but 172 is the major blocker atm - I run into it enough that it's very annoying If DMP didn't work on 64bit, I'm sure I would have had many bug reports by now - I've been running it on linux 64bit ever since I typed "namespace DarkMultiPlayer" (the beginning), and I've heard many reports of it working fine on windows 64. There was a little hickup with MessageWriter being 32bit while DMP being 64 once, but that issue was resolved.

@NFUN: If you aren't sure about something, please don't provide incorrect answers. @Everyone: Unhandled error while syncing means one of 2 things. The first, Release wont work with KSP 0.24.x. Use dev. You can double check which version you are on by checking GameData/DarkMultiPlayer/git-version.txt. Release builds are v0.x.y.z, dev builds are sha256 sums. By default, the updater updates to release, unless you have renamed the updater to DMPUpdater-development.exe. If you're on dev and get an unhandled error, come visit in IRC - Theres something that DMP failed to sync on that universe.

@Everyone: My bad, I've rebuilt MessageWriter for AnyCPU - Obviously linux handles things a little bit differently . Monodevelop has a pesky default of 32bit only, even though x64 came out 10 years ago... Dev also has a serious problem of trying to sync from the persistent.sfs file, which is something that has changed with KSP 0.24. I'll figure it out today and get a proper port for 0.24 up. EDIT: Done with the help of JoshBlake. @NFUN: Vessel permissions is coming, it depends on a proper group system however, which is one of the few things left to complete. It's also been proven that shared science is possible, I'll work with JoshBlake on that one for 0.1.6.

@SilverlightPony: I've implemented the syncing to where you where thing in a custom branch, giving it a little test before I see if everything is ok @TranquilTempest: Syncing to the past won't be possible - It's a combination of the way DMP works with subspaces and historic updates. @NFUN: It definitely appears the normal sync has been broken, even in dev. It appears to be loading persistent.sfs for some unknown reason (I don't explicitly load the data). I've still yet to work out the final kinks in the 0.24 update. @Everyone with "Connection ended: Unhandled error while syncing!" - Use dev for 0.24 and release 0.23.5. Dev isn't compatible with 0.23.5 and release isn't compatible with 0.24. @PhoenixTheSage: There are other things that can cause that error, If you have a dev server that throws the error, sending affected files to me might help @Meteo: Related to KSP loading the game data on start now. It's pretty annoying @PringleMan: Flag syncing is in dev (I think it might be in the 0.1.4 series too) but it hasn't had a lot of testing. It only syncs things in the DarkMultiPlayer/Flags/ directory. Also, the plugins folder is for DMPServer plugins, it works very similar to the way KSP's GameData works, but do not put client mods in the server folder, they are different. Currently there is an IRC connector by RockyTV, and I've got a few debugging plugins for code that doesn't belong in the DMPServer repo. I'm working on the 0.24 oddness still, but I haven't been working on it every day. I'm close to pushing a dev version when I can figure out KSP's weirdness .

@Nemrav: There might be other issues with DMP, but you definitely don't need to send it out to the internet and back (I'm not even sure if this is possible). Connect to your network address instead (Usually 192.168.0.something). @forfeit: I know there's definitely some 0.24 issues, I believe KSP has slightly changed the way games are started, so I need to dig into that, and the forceQuit method too (Forcing KSP back to the main menu causes a blurry version of the tracking station to load, so I've disabled it). @NFUN: Or you could just say use the dev version with 0.24 @SilverlightPony: 1) The server definitely "ticks" even if nobody is connected, or even if the server isn't even running. The planetarium clock is locked to the server clock for very good reasons. However, it would be fairly easy to add an option to make the server universe go back in time upon connecting 2) Bad news, And this is directly related to the subspace system. DMPServers job is to hold just enough data to send the player into the latest subspace, It does not hold onto historic updates. So unfortunately, this isn't possible, and it will always send you to the latest time. The only exception to this is to allow players to sync to the subspace they were in, but it will already have all of the future updates applied (but they would just wind back along their saved rails). This will only work if the server doesn't get shut down. @Ghostexx7: All the servers on the server list that have "37f3698 (protocol 24)" in the version field.

@Darkstar616: It would still be nice to figure out, it shouldn't hang at all. If you put it on your desktop it should complain about not being in the KSP or DMPServer folder though... @Preliator: The only reason DMP exists is because *I* want to play multiplayer with others, but generally the more bugs I fix the more people will hopefully want to play it. @DuoDex: (This video was never released because it honestly sucks), but seriously, DMPServer runs completely fine under mono, it's actually developed and compiled under mono as well, being on linux myself. @perds provides proof

@NFUN: The servers fault will also be DMP's problem @Darkstar616: Protocol mismatch means the server version and client version is incompatible. I should probably rename that error to 'Version mismatch', although different versions can be compatible (and the 0.1.4.x series were all compatible with each other). And huh? - No, the updater definitely isn't a virus (the source is available on github for anyone interested), nor should it hang in any spectacular way. There *is* one exception to this, It's a rare bug, but even simple .NET programs can flake out on windows 8. You'll probably want to visit on IRC so we can sort this issue out (There's a chat thing on my build server page in my sig)

37f3698 is the first dev build that supports 0.24 - Although I might have still missed something. I'll double check things when I'm home

@aftokinito/Everyone: DMP definitely broke with the 0.24 update, but I've fixed what I could see and pushed initial support for 0.24 now, So it's available on my DMP build page and DMPUpdater-development. I'll leave it settle for a few days so we can get any bugs that pop up before it gets pushed as 0.1.5 EDIT: I've created a DMUpdater-0.23.5 branch - it's the last version for 0.23.5. DMPUpdater-development will only work on 0.24. The DMP universe should automatically upgrade (The kerbals will get renamed from "0.txt" to "Jebediah Kerman.txt" due to internal changes with KSP), although if you have thousands of kerbals, feel free to delete them. @arbiter787: That's an odd one, It might help if I check the log file. The only thing I can suggest is make sure you're not using a port number lower than 1024, otherwise you need admin rights :-/

@Zaithe: Fixed - There was an issue with the server scraper @SoldierHair: You'll always connect to 127.0.0.1 for your own server. I can't test hamachi as I have linux, but it has been reported to work (I'm not not sure how to set it up, DMPServer listens on everything by default so it should just work). Port forwarding is a nicer solution if possible though. @Monkthespy: I've never had issues while sitting on the runway, but as soon as you take off DMP can't update vessels in the atmosphere (mostly fixed in dev, atmospawning is back - you'll have to be within 2.5km of them though). If you know how to break it, then I'll fix it . Make sure you're in the same subspace while attempting to fly though, you can see things from the past but not the future. @Phantomewzick: I think I got you on IRC - It's online now, but the server info is scraped from DMPServerSettings.txt - The actual name on your personal list is just for you. @choninja21: Yes you can, although with a few problems. You can't spawn vessels in atmosphere in 0.1.4.2, and in orbit there will be a (stable) position error. Also, you'll both try to spawn in debris, which will cause problems. I've mostly worked out those kinks in dev. @KvickFlygarn87: Unless you're playing multiplayer asteroid bowling Everyone: I'm targetting friday 18th for a release date for 0.1.5 for KSP 0.23.5. If 0.24 comes out before then, this is likely, then 0.1.5 may target 0.24.Possible situations: KSP 0.24 comes out after friday: DMP 0.1.6 released a few days later. KSP 0.24 comes out before friday: DMP 0.1.5 may target 0.24 if the porting work isn't all that great. All I know is that the kerbal crew roster will be broken. I suspect that science/contracts will use scenario nodes, so I likely won't have to do anything to support it other than blacklisting those nodes from the sandbox game mode.

@Trailers: Definitely not, the safety bubble on the runway only extends to the first white markers in front of you. 100m isn't very far in KSP.

@Alshain: It took me a good 5 minutes to find it the first time after they changed the space center screen. It was easy to spot before that... @Phantomewzick: I'm going to assume you typed in port 6702 instead of 8081. You need to enter in the HTTP port. @Trailers: You need to roll out of the safety bubble first and be in the same subspace. After that, you'll have to stay within 2.5km in order to see each other.

@SniperTriple9: Visit me on IRC @Probus: It should work, but only against non-player controlled vessels (Which I guess defeats the whole purpose of a PvP server). Players don't send part or position updates for other craft. @comatosed: I'm actually a linux user (debian/unstable) myself, and DMP gets developed on linux with monodevelop . mono-complete should be in the debian and ubuntu official repos, I think the package is just called mono on archlinux. @Alshain: Press on that tiny flag pole in the space center screen. It's in front of the astronaut complex.

@Tetronamyl: The http server is disabled by default in dev now - Windows requires admin in order to use the HttpListener class. To fix the problem, you can either run the server as admin (not really recommended as it shouldn't need it), or you can go into DMPServerSettings.txt and change httpport,8081 to httpport,0

@jyoumon: This sounds like the ultra rare bug that RBreaker had. I think it can only affect windows 8. Can you visit me on IRC, I think even the most basic of .NET programs failed for him, so that's something we can test. There's a web chat client on my build server.

@Gristle, The only thing dekessler removes is things marked as debris in the vessel file: 'type = Debris' (It's very close to the top of the vessel files) @Vladthemad: DMP has saved the selected flag for quite a while, ever since 0.1.4.0 was released. If DMP isn't saving the selected flag, I should probably check out the output_log.txt file :-/ @kofeyh: Caused by having thousands of kerbals on the server, which is caused by DMP reassigning taken kerbals to new vessels incorrectly. (EDIT: should be fixed in dev, EDIT2: I've made a plugin to reassign the kerbals and delete the extras)