Northstar1989

Alright, so it appears that a PNG is actually smaller than a JPG for all the texture files except texture 001, so I converted that one and left the rest as PNG's (I will be updating the OP with the new version shortly). Not that the format matters too much anyways except for download size/speed- as I understand it KSP internally converts all textures to .DDS format now, which is what made the DDS converter trend and related mod largely obsolete? Regards, Northstar

@Veeltch well you're clearly a cynic about... basically everything. I don't get your obsession with SQUAD stopping development of KSP and making another game, but it's off-toff-topic here, and disrespectful to everyone here to prate on about it instead of the topic- how SQUAD could implement multiplayer *in KSP*- not in another game... This hit on the issue without realizing it. The main problem with DMP is simply amateur coding and that it lacks quality-of-life improvements. Things that SQUAD could *easily* fix if they did their own version of multiplayer from scratch, but with a roughly similar system in mind... @Veeltch the issues you and your friend had with DMP also had literally NOTHING to do with the basic concept of multiplayer, or how they went about implementing it. If the basic coding basis for DMP had been sound, and it included the right quality-of-life improvements, then docking would have been trivial in DMP- and the exact same as in single player... You would have simply synced time-warp, established a phasing orbit, time-warped together (in sync) until the two craft were close to in position for rendezvous, set a maneuver node and performed the intercept-burn, matched velocity at closest approach, performed a series of micro-maneuvers to get closer, matched velocity again and then inititiated final approach to bring the docking-ports together... This is literally the EXACT SAME procedure as for docking in single player, with the exception of the addes bit that you need to sync time-warp before phasing the orbits. Which leaves me asking- are you *ABSOLUTELY SURE* you actually know how to perform rendezvous and docking correctly? If ANY of my terms or steps sounded unfamiliar to you, then TBH, you probably don't know how to perform docking correctly. You wouldn't be alone either- 90% of the time I hear a player whining on the forums about literally anything to do with docking, it's because he/she doesn't know how to do it correctly (even some experienced KSP veterans I've watched on Steam or on Twitch don't know or follow the correct procedure- and even fewer know enough to be able to improvise if there is something slightly unusual or difficult about the situation or craft...) So I'm actually more inclined to believe you and your friend didn't know enough about rendezvous and docking to do it correctly with another player (if you're like many KSP players you probably each had your own hackneyed methods, which meant you were each trying to do a slightly different, slightly wrong thing) than that it was a problem with Dark Multiplayer. There's an old saying in computer programming (my mother was once an engineer who did a lot of programming for the defense industry, so even though I'm quite bad at it I learned a lot of programming lore/culture at a young age- though this one I actually got from the internet) "Garbage In, Garbage Out". No matter how good your program is, if you give it the wrong inputs, it will give you the wrong outputs. Similarly it wouldn't matter if you were working with a FLAWLESS multiplayer system- if you and your friend didn't have a solid understanding of, and an agreed-upon approach for, rendezvous and docking, it was going to be impossible no matter if multiplayer was essentially functionally identical to singleplayer except with 2 different people needing to agree on how to achieve things... Regards, Northstar P.S. My credentials when it comes to rendezvous and docking are impeccable. I've performed maneuvers less knowledgeable players think are impossible- like intercepting and docking with a craft performing a Munar gravity-assist out of the Kerbin system with another craft originally in orbit of the Mun, or performing rendezvous and docking in highly-elliptical orbits (or even on escape trajectories). So believe me when I rell you, most KSP players don't have a clue about the proper way to rendezvous/dock or the underlying theory- most just stumbled across a method that sort if works for them at some point, and stick with it assuming it's the right way to do it... (I myself used to be like this until I started reading countless player-guides and realizing that no two agreed- and so instead started reading up about how NASA does it, and learning the underlying theory...)

CertifiedSilly1.2.2? What's with the file name?

OK, so I decided the SLS (estimated development cost $30 Billion, vs. $19 Billion in total costs for the StramTram track, which seems a bit conservative) was a more appropriate vehicle to compare prices to. As such, I tried to balance costs vs. the SLS style parts, assuming a big chunk of the costs are in the R&D, rather than the actual materials (which are relatively cheap electrified aluminum coils...) Don't forget that one would need 10,000 of these parts, stacked end-to-end, to get a 20 km long track! (Which would actually be possible, from a raw physics-sense, in KSP now that load-distances can exceed 27 km. Good luck with that part-count though!) Costs: Mass Driver "Master" Coil (necessary for any stack to work) - Part Unlock Cost: 42,000 Funds - Part Purchase Cost: 1200 Funds MassDriver Network Coil (requires Master to function) - Part Unlock Cost: 16,000 Funds - Part Purchase Cost: 150 Funds So, a stack of 5 coils costs 1800 Funds (3x a Mk1 pod), a stack of 11 coils costs 2700 Funds, etc. This is intentionally designed to make longer tracks of coils more cost-effective, which is realistic. Don't forget that 11 coils weigh 264 tons and will be extremely expensive to lift to orbit, though, and it's 58,000 Funds just to unlock the parts! Let me know if these costs seem reasonable cor balance purposes. For now I'll be releasing an updated version shortly.

Thanks! Unfortunately though, I'm about to release are-balanced version. Some new, more accurate calculations accounting for the length of the vehicle that would pass through StarTram shows that each each section should only produce a max of 1471 kN of force instead of 15,200. However part mass will also be reduced from 25 tons to 24, and I'm looking at some reductions to part cost as well as calculations using StarTram figures of $19 Billion for a 20 km long track shows that each 2 meter long section should only cost $292,307.69 when averaging the entire construction, R&D, energy storage costs, etc. over the number of 2-meter sections... (I'm trying to balance this vs. the $61.2 Million list-price of a Falcon 9, but it's hard to do any direct comparison between real life dollars and KSP "Funds"... I'm assuming players can do a Falcon 9 analog for about 32,000 Funds- does that sound reasonable?)

Apparently. Nice video though. The Mass Driver seemed a little OP'd though- even for such a tiny capsule... (it provides a constant force, so it can accelerate smaller rockets more quickly) Then, double-checking my sources, I noticed something I missed before. The StarTram design on which it is based is supposed to be able to accelerate a *13 meter long* 40 ton payload at 30 g's. That means that the rocket is being acted on by about six and a half 2-meter long Mass Driver sections at any given time (each section from this mod is 2 meters long) or with the mod's fudge-factor (mass drivers act a little beyond their edges), about 8 on average... Additionally, the Mass Driver was only supposed to produce a max force of about 11767.98 kN previously- I had it set to 15200 kN! So, I will be turning down the force and energy-consumption of the mass drivers 8-fold from the *intended point* in the next update, or about 10.3-fold overall. Sorry this will make shooting Kerbin from the Mun a little harder- but it will ensure that performance remains realistic... (I guess you'll need to learn the Master/slave system for the parts and launch an 10-part stack to the Mun next time- which will look even more awesome!) I will also be turning down the part mass 4% , from 25 to 24 tons to compensate- and as the previous mass was a tad unrealistically high... You used the "base color"? What does that mean? Anyhow, I didn't notice, but 002 through 005 were already PNG- but ought to be JPEG. I will run them through a JPEG converter program- it might lose a bit of resolution, but they're basically just solid colors so it shouldn't matter...

The version you uploaded is missing the texture file "Model004". Did you leave it out intentionally? (and if so, why did you include the Model 000, 001, 002, 003, and 005 files? Did you alter the textures at all?)

Why not?

Not yet... Tbh I'm not even completely sure what the definition of a "repo" is- I have very little actual coding experience, and I'm kind of untaught as to how I do this whole maintaining a mod thing. My only real assets as a mod maintainer are, sadly, the ability to do good real-world research (the Mass Driver performance is designed to be *exactly* the same as the StarTram Gen 1 design in terms of force output, for instance- even if that happens to be a little OP'd in the Kerbal universe unless you play with Real Solar System...) and the fact that I never stay away from KSP for too long- I always return to it after "life" happens. Other than that, I'm sadly lacking in skills or knowledge. So please educate me as to what a repo is, and how to use one! Regards, Northstar

Awesome. So just replace the corresponding file from the mod golder with this to get it to work? Will test, then update OP if works.

What works? Your fix for the colliders? Anyways, sure.

You should see two types of mass driver parts in the VAB. The "Master" part activates all slaved parts in the line of direction of fire, to produce greater total acceleration. Note, however, that this might not work right if the part is placed *above* the rings. The mod was originally designed for payloads to be placed *below* the rings and accelerate the craft as it passed through each ring in succession. The only reason it works at all on payloads placed above the ring (so it's accelerating a craft without it ever passing through the rings like it should) is that each ring has a certain "fudge-factor" where it recognizes and acts on craft a bit above and below the ring. With multiple rings stacked, the ones further down in the stack might not act on the craft at all, as it never passes through their recognition-zone. This is of course not an issue when payloads are fired *through* the ring as intended... I'll be testing the mod shortly to make sure I can reproduce the issues with payloads being unable to pass through the center of the ring when fired myself (note that I'm pretty sure the center of the ring was always technically solid- the only way payloads could pass through it was when *fired* by the ring from below...) If it is indeed an issue, I'm hoping @rspeed or @FreeThinker have the insights and expertise to fix it... Regards, Northstar

How are you trying to pass through the center? Are you using the Mass Driver's context menu to activate it and accelerate a *seperated* craft through? Colliders don't normally change between updates, so I would be surprised if they were really the issue... Will test myself to try and determine the source of the problem... Regards, Northstar

Did my videos help?

If you never attempt anything great, you will never achieve it. The reality is, KSP is already slowly fading away from the public consciousness, DESPITE its console ports rather than because of them. The only way they are going to get the game more attention, and more sales, is by doing something fundamentally transformative like implementing multiplayer. Localization and console ports expand their *potential* market, but they will never acctually sell to that potential until they get more media attention. That being said, if they set up localization and console-ports first and THEN add multiplayer, they're likely to bring in more media attention and sales in the long run- as the media blitz adding multiplayer will generate is kind of likely to only be a one-time thing... Exactly.

That's not an interaction- not in the physics or timeflow sense anyways. It's trchnically a restriction on a player's behavior outside of physics, just like time-warping does not actually affect the laws of nature, only speeds them up. So it's not a paradox, just possibly annoying. Think of it as the other player havong filed a property purchase on that offworld territory years ahead of actually arriving there if you will. Yes, you can't leave a vessel clipping througj another player's base and then sync time-warps, but this is a restriction that is consistent with time-flow and creates no paradoxes. That's not a paradox- just a game restriction, no different than anti-griefing rulesin Minecraft or property clsim flags on ECO or 7 Days to Die, really, to cite some common examples. Only instead of being necessary to stop somebody from destroying your house, it's necessary to prevent a physics paradox of diverging timelines that would make multiplayer impossible. Would be treated the same as asteroids. They could not be interacted with, perhaps would not even appear in the game, until a player had "claimed" them. With a contract this is particularly easy- the vessel would just be auto-assigned to whoever accepted the Rescue Contract. Actually, this is already how Dark Multiplayer ALREADY handles Rescue contracts- one of the German players I watched the other night actually carried one out, and it spawned the vessel in as "his" vessel. Pardon me, but you clearly don't understand what constitutes a paradox here. A paradox is any course of action that would break physics- that would lead to a pair of diverging timelines where a vessel is no longer in place for a player to interact with after he has already interacted with it at some future point, for instance. It is NOT some annoying game restriction, like being unable to interact with a vessel until you have synced tome-bubbles with the owner, or only being able to sync by mutual player agreement... As such, no paradoxes are possible under a scheme where all interactibe objects belong to a player, and no onject can be interacted with except when synced to the sametime-bubble as the owning player. I don't CARE if you like the game restrictions this implies, that is not, and was never, the point. The point is it's possible to have a physically and chronologically-consistent multiplayer in which players can time-warp at will. It doesn't matter a bit whether you *LIKE* the game rules that make this possible, just like a board game doesn't care if you like its rules- you simply have to accept them. Your notion of "should" is based on reality, rather than what makes for an enjoyable game. Just like in real life, there's no law of physics that stops you from burning a person's house down- but in Minecraft, anti-griefing protections will simply stop you from lighting a fire on another player's property... None of these game rules are paradoxes. They are simply restrictions on behavior that allow for an enjoyable multiplayer experience, the same as anti-griefing protections in Minecraft. Frankly, it doesn't matter whether you like these rules, they are the only way to create a functioning multiplayer mode free of paradoxes. I am also left to ask- have you ever PLAYED a serious board game? (Something more involved than Monopoly) ALL games have rules you cannot break in order to allow for an enjoyable multiplayer experience, or to make the game possible in the first place- even if reality does not always have these rules. It is simply part of the limitations of the medium of a game- if you don't like it then don't play the game. They are NOT PARADOXES. You already accept many such rules when you play KSP whether you know it or not... Razark, your entire concept of a "synchronized multiplayer" already exists as a simple variant of the system me and Enceos outlined above. Ifa al players in a server were to sync their time-bubbles into one, and then by mutual agreement (or a server setting preventing it) none of them were to BREAK that time-sync for any reason, but instead advance the time-bubble together at all times, then you have a synchronized multiplayer right there. The only difference between the system you propose, and the one myself and Enceos outlined, is that players are not FORCED to share a single time-bubble in most cases. This allows players to either play more independently, ot to branch off of a single mission and perform different components if it at different rates. So, for instance, if one player is landing a lander on Laythe and exploring it while the other performs a series of gravity-assists around Jool's moons to prepare for the return-voyage back to Kerbin, the players don't have to perform these actions in the same time-bubble. They can just perform them in different time-bubbles, but sync them back up at some pre-determined departure date to make a return to Kerbin... Synchronized multiplayer would already exist as a subset of the independent time-bubble concept. In fact it would probably just be a matter of ticking a checkbox when setting up a server- so that instead of each player starting at Day 1 and having the ability to sync up their time-warp with the other players as they so wish, ALL player start in the same time-bubble (new players might join starting at Day 45, for instance) and are not allowed to leave the shared time-bubble at any time. Your option rigidly restricts player's actions, mine gives them freedom and flexibility. But within the subset of cases where all players on a server have synced up to a single time-bubble, functionally they are the same. Your statement is nonsensical. "If there is a way point"- what is that supposed to mean? There is no way to mess up the system described by myself and Enceos, plain and simple. Players sharing a time-bubble would time-warp together, along with all of their vessels. Players in different time-bubbles would be unable to interact until they had sync'd time-bubbles with the player(s) they wished to interact with. In no cases are there physics-breaking paradoxes due to the system of vessel ownership and restrictions preventing interactions with any vessel in another time-bubble. Dark Multiplayer already exists as a more-or-less functional multiplayer. The main problems with it are low-quality data-syncing for players sharing a time-warp, on a level that would be completely unacceptable, say, for an FPS, even though once you remove all difficulties associated with time-warp (because the players are already synced) the data-management challenges are basically the same... Thus it's likely, knowing SQUAD, that they took the "There's already a mod for that!" altitude, even though multiplayer really is a basic functionality that should have been integrated into the game ages ago- the same way that some KER/MechJeb functionalities like the ability to display the available Delta-V for a craft really should have been integrated into the base game ages ago- and the devs hinted at doing so, then just abandoned the idea... The truth is, SQUAD is often a rather unfocused game-development company that doesn't really seem to know what they are doing well enough most of the time- which is unsurprising, considering they were originally an advertising firm with no experience in game-development.

Great! Thanks FreeThinker!

No problem- it just so happens I made an abortive attempt at running a YouTube channel some time ago, and uploaded a number of videos where I used FMRS... More videos using FMRS can ve found on my channel. I installed it somewhere partway through my RSS 64K series in 0.24.2, and used it through pretty much my entire "Collaborative Career Campaign" (where I solicited mussion suggestions on the forums and attempted to execute some of them) series, which was in 0.90 I think... Regards, Northstar

What you described is basically how Dark Multiplayer works, if I understand how it works correctly- with a few minor tweaks/fixes. Speaking of DMP, I was actually just watching some Germans play it on YouTube, in Career Mode (which I had no idea worked in DMP- though they dodn't seem to share a Space Center or budget, sadly...), and they seemed to be having no issues with it (of course, I only speak a bit of German, so I could have mussed something) except with a Mun satellite conteact failing to complete for some reason... (the bug seemed to be unrelated to DMP anyways) Generally my only objection DMP is that it's a little-used mod few have heard of, programmed by amateurs- and since it is a mod it may stop being updated at any time. I think SQUAD desperately needs to move on multiplayer- though I fear they've silently backed away from it, just like Gas Planet 2... What I want to do with multiplayer works perfectly with the model you outlined. I would like to split up missions into different parts with ownership transfers of vessels between... For example carrying out a Stratolaunch style mission where one player takes the control of the rocket at stage separation while the other flies the rocket to orbit- and then another still takes control of the payload once it reaches orbit and docks it with another vessel they own, while the first player flies the upper stage back to the KSC for a propulsive landing. I.e. cooperative play for speed and efficiency, so say a 3 hour mission can be achieved by 4 players each playing for 45 minutes, handing off vehicle ownership in between... I have no use for "together alone" gameplay, I believe the true function of multiplayer is cooperation.

So you know where those vessels will be if you sync to them. And in the case of surface bases, or any landed vessel, to create an active-denial zone so that you won't place another vessel in the same spot (any attempt to sync time-warp when you have vessels overlapping with a shadow copy would refuse to allow you to sync time-warps, and provide an error message telling you to move your vessels first). You have failed to show any paradox. You can *see* a vessel without syncing time-warps, where it currently is for the player who owns it. But you CANNOT interact with it, *UNLESS* you sync time-warps, and even then only so long as both your time-warps are synced. You can never sync with offline players. No. Player One cannot "dock with and interact with" any craft except his own, and those of a player he is actively time-synced with. I've already stated this repeatedly. What Player Two does on no way affects Player One, *unless* the two agree to sync/merge their time-warp bubbles. That's a clearly nonsensical statement. There is no way for a craft to not have an owner, as there is no way for a vessel to ever exist in KSP (even in single-player) without being launched by a player. The player who launches a vessel owns it right up until the moment he/she should choose to transfer that ownership to another player. It's a solution- just not one that you want to accept. That doesn't matter, it's a workable solution, regardless of whether the prospect of (shadow-copies of) craft suddenly "appearing" when a player logs in sounds appealing to you or not. (If it really bothers you that much, you could disable the ability to see other player's shadow-craft until you wish to- or just not play multiplayer.) It works fine for me- many MMO's already do this with player characters appearing or disappearing as players log in or out. Or "warping in" when moving between "sectors" (which are really entirely independent instances, much like the time-bubbles I discussed- with the exception players don't control who enters them) in space-MMO's, such as BGO or STO. It's also occurring all the time on the quantum level in the real world- with "virtual" particles spontaneously popping in and out of existence in any vacuum, particularly near black holes and such... Yes they do. You've failed to find *any* exceptions or paradoxes they lead to- only "I don't like these rules, so I'm going to change them to ones I like that *do* allow paradoxes, and then say the original rules allowed paradoxes." The rules, as I stated them, allow no paradoxes as they allow no interaction of vessels owned by different players except when two players who are online *agree* to sync time-bubbles. If you can't interact with another vessel in another player's past or future, you can't create any paradoxes. Anything you do to another player *necessarily* has to occur in his present moment, which he has to decide to let you enter in the first place...

On Day 5 you would see a shadow copy of the station where it currently is on Day 100, obviously. You would not see where it was on Day 5 at all. I don't get why people can't wrap their head around this- it's really not that difficult to prevent any paradoxes by only making vessels interactable in the time-frame occupied by their owner- never one before or after it. To dock two craft, both users would have to exist in the same time-frame, and then one user would have to "transfer" ownership of their craft to the other player, or else the two users would be locked into a shared tome-warp until their craft undocked (if one user logged off or lost connection during this shared warp, ownership of any docked craft would automatically transfer to the other player). Obviously great trust would have to be involved in anything to do with docking, as it should be. Asteroids would need to be "claimed" by a user in order to interact with them, obviously. Any offline user's craft would probably need to become non-interactable and disappear, or continue on as a shadow-copy at some pre-determined rate of time warp (meaning the craft would actualize at a new time and location when the user returned). These rules may seem a little draconian and limiting, but would prevent any time-paradoxes. Basically, there would be no way for two craft to interact in any way except when their owners were in the same time-frame, and asteroids would need to be "claimed" before a user could interact with them. Regards, Northstar No, no you can't. Stop trying to unnecessarily complicate things. If you're in a different time-warp than another vessel, it's non-interactive. Period. You have to sync to interact. No, they can't. If an object isn't synced to your time-bubble, it can't affect you in any way. The rules for vessels are obvious- they would belong to the player who launched them unless ownership were transferred. Docked vessels would permanently lock two players into a shared time-warp (which would he required to dock the vessels in the furst pkace) until one player took ownership of both craft or logged off (which would automatically transfer ownership to the other player). Offline players' vessels would disappear from the map, except surface bases. Surface bases could leave a shadow copy when the player logged off, preventing anyone from landing another vessel in that exact spot (placing a vessel in the same spot would disable a player's time-warp, and delete their vessel if they logged off). Asteroids would be non-interactive until "claimed" by a player (they would probably only spawn in once claimed- before that they would just appear on a list alongside size and orbital characteristics in the Tracking Station). Draconian rules are the answer. And in any ambiguous cases the game would just auto-delete offending vessels it could not figure out what to do with, and provide affected players with an error/warning message informing them of this. Regards, Northstar

FreeThinker released a recompile for 1.1.3 for me, but we need one for 1.2.x https://spacedock.info/mod/890/Netherdyne Mass Driver Mod If you go prod him for me (I asked him about it a while ago, and never heard back from him) he might be convinced to do a 1.2.x recompile. Sadly I don't have the skills to do a recompile myself- the limits of my skills are doing research on real world science and things like part config editing to try and match it... Alternatively, if you have the skills, you're free to take the version from that link and recompile for 1.2.x Regards, Northstar

Attempting to access inaccessible memory? Would that maybe be the real problem here? Razer Cortex is a memory-management program. It closes down unnecessary processes and optimizes certain processor usage, but takes up RAM itself. I find it saves me a net of about 20 MB if RAM and yields about a 2-5% increase in franerate for most games when I run it (including KSP). It's not much, but every little bit helps when you're running games on as marginal a machine as mine (really not my fault- I'm broke despite doing all the "right" things, studying hard and getting a graduate degree in the sciences, and even working part-time in grad school in addition to my 40+ hours/wk of research work and classes- but failing to get any good professional employment after graduation...) As for your questions: - The toolbar button used to minimize/hide and expand the FMRS window showing available stages to switch to, etc. - In my experience FMRS was *very* stable in previous versions of KSP (I'll have to check what version #'s those were I used it with), except for the very early versions of FMRS after it first got started. FMRS did have a few bugs resulting from how it did what it was designed to do rather than any actual malfunction, though- for instance contracts could not be completed with dropped stages until they were landed and integrated into the main save, and Kerbal tourists could be both dead and alive at the same time in contracts in a kind of Schroedinger's Cat reminiscent paradox as they would make it to orbit alive in the original mission but then counted as dead when you switched back to a launch stage to pilot it back to the ground and the payload fell back into the atmosphere and disappeared in that version of the save... This led to the main mission having the Ketbal tourist in orbit, alive, but failing the tourist contract due to the tourist "dying"... (this was due to giving FMRS tracking for Kerbal deaths- a huge mistake IMHO that was later set as a toggleable setting in later versions... I actually experienced it in the latest crash though, as I forgot to turn off Kerbal tracking under settings...) - The old version problems were basically the kinds of things I outlined above. Occasionally it could also have memory issues leading to CTD's if you used it after way too many reverts (so this issue isn't entirely unknown), but those were very rare and generally only occurred after hours of continuous playtime... (so it's more that these memory-management and efficiency issues seem to have gotten much worse in 1.2.x than that they are entirely new- much like the base game itself had memory issues that only popped up after version 1.0x, and got somewhat better for many people in 1.2) A final note- FMRS was known to experience some pretty bad issues in past versions of 64-bit KSP. I never really dealt with them much because so many other mods also had issues I played in 32-bit. Now that 64-bit is stable for most mods, I'm playing with it instead. Maybe part of these memory-issues have to do with 64-bit specifically. I could try running the 32-bit exe and see if FMRS works better for me in it... Regards, Northstar

Saying a system ran out of memory is the usual easy-out to avoid finding fault with the program. FMRA should only have to conduct *one* revert each time I switch controlled stages- which, as I've said, is something my computer can easily handle. I'm not running a real mod-heavy install, and that 11% of unused memory easily represents more RAM than the sum total of what all my mods use combined... If FMRS manages to eat up over 200 MB of space just integrating two saves together (keeping in mind that the sace files are a *tiny fraction* of that size, and indeed an entire lvl 2 debug crash log is under 60 MB) then there's something seriously wrong with the way the mod conducts its memory-management. But I'm not the only one experiencing crashes, so even that seems unlikely... Anyhow, I can try using the new FMRS beta build and see if that fixes things. I also might try turning off Razer Cortex- which manages RAM usage through its "Game Boost" mode. It's perfectly possible *that* is actually what's causing the problem- it could even be artificially restricting memory usage- as I didn't have Razer Cortex the last time I had Flight Manager installed and working correctly... Regards, Northstar

My laptop routinely runs KSP at 89% memory usage without crashes unless I perform something like a dozen reverts in close succession (like when testing a new rocket). So that in itself doesn't mean anything- unless FMRS is seriously inefficient with its memory usage. Plus, I never experienced such crashes running FMRS on previous versions of KSP... As for the DLL, I used the one you posted before fixing the window issue. I actually went in and *deleted* the prior DLL, then inserted the one you posted. So unless you accidentally posted the wrong DLL under that link, you must be mistaken. It's just the DLL you need me to replace right? So why would I delete the rest of the folder? Maybe you could post a link to an entire FMRS folder, complete with the DLL and other files you want me to use? Just to avoid any potential for confusion. Regards, Northstar