Lisias

Dude, you are barking on the wrong tree. I'm just the messenger. You walk on the streets telling people "I'm a Pharmacist", the worst that can happen to you is someone asking you for a Aspirin. You do the same telling "I'm a Drug Dealer", any cop can arrest all your money under Civil Forfeiture. You talk to these guys about it from now on, ok? "Take 2 Have Declared Modding In General Illegal, Cease & Desist Sent Against OpenIV"Modding In General Illegal, Cease & Desist https://forum.level1techs.com/t/take-2-have-declared-modding-in-general-illegal-ceasedesist-sent-against-openiv/116742 I'm done with this. I don't want to be dragged again to this thread. Please comply.

Not necessary - the galaxy background is just a big texture that are rendered when nothing more is on the way of the camera. There's very little GPU processing here - it's essentially taking a texel from a texture coordinate instead of bluntly painting a RGB color. Clouds, on the other hand, needs a heavy GPU processing because they are painted over an already rendered image, so the GPU must take the image's source, mangle with it, mangle with this neighboors , and drawn them back. And them do the same with the next pixel. And so on. If you interested on the thing, how about trying it out yourself? You can use Blender to toy with the idea:

Eternal and timless.

Things changed! 37573 MB paging file [15935 MB free]. 134217728 MB user address space [134198049 MB free]. Read from location 1d830008 caused an access violation. Whatever has crashed this time, it was a different code than the last time. Previously, your KSP were borking by reading from location "0x80" (it has a lot more of zeros to the right. ), at the very beginning of the addressing space. Now, the thing is capsizing on the location "0x1d830008", where I expect to be C/C++ code (that first half for TEXT, last half for HEAP thingy) - and assuming I remembering it correctly from my C times… It was some time already. It's kinda weird, but it's an improvement. And I think that there is another test to be tried: put a 32 bits X-Input DLL on your "C:\Users\Alex\Desktop\KSP 161\". It's a long, crazy and perhaps stupid shot - but at this time, there's few to loose. Someone above mentioned fixing the problem by doing exactly this stung (and I should had paid more attention to him, as it appears - but, well, this is kinda weird...). I'm sorry I can't help you more on this - I don't have a working Windows machine for KSP, and I'm pretty sure if I could reproduce the problem on my box, I could try a VisualDebugger session and perhaps get some insight from the guts of the problem. This is intriguing, this stirred my curiosity (old dog, old tricks - I started my professional career solving these stunts!) It may. Your problem is similar, but also different from the OP, and we were using 1.4.5 or 1.5.x at that time (don't remember precisely now).

Because you keep calling me again to this thread. I have nothing more to add.

No, it was not. https://imgur.com/gallery/khsNzaO It can mean a lot of things. In California and Japan, you could be in legal trouble -see the links above. Pedantic? Probably. But on the safe side, why look for trouble? People are talking "Homebrew" for years already, exactly to do not be mixed with the other context. The words "Mod" and "Console", when used together, had caused a lot of headaches for a lot of people. It's like I said : you can call yourself a Pharmacist or a Drug Dealer - both are, to the letter, correct if you sell medicines. But people will judge you differently if you use one and not another. But, and once again, your life: your problem. I'm just the messenger. Fell free to do as you please, I don't care - as long nobody calls by my name, I have no reasons to talk about it again.

It's working on 1.5.1 and also on 1.6.1. You need to download a compatible Kerbal Konstructs. In a nutshell, download what follows: https://github.com/GER-Space/Kerbal-Konstructs/releases/tag/1.4.5.59 https://spacedock.info/mod/1347/Kerbin-Side Complete continued/download/1.5.1

As far as I understand, no one has the right to wave your rights but yourself [and a Court of Law, under certain circumstances]. At least on USA, you are free to do whatever you want as long there's no law forbidding it. So you can talk about (almost) whatever you want, as there're (just a few) laws restricting what you can say without reprimand. This means that you can agree to wave such a right, if you want - as there's no law telling you can't. (You can't waive your right to life, however - there is a law forbidding it). It's not the EULA that it's taking your rights. It's you that are waiving them. We can discuss about the ways they manage to get such agreement, but once such agreement is valid, that's it.

Even by smashing reputations and unethically (or plain illegally) undermining the competition? Read that agreement again, and tell me where it's saying that if an employee uses (or just leaks by negligence) your info illegally against you, they waive the Arbitration clausule. Do you remember that huge Credit Card leak from Sony? Under this agreement, you wouldn't be allowed even to talk about. — — — — — Let me try to explain it better. In a nutshell: I'm not talking about what they intend to do (they have some problems that need to be dealt). I'm talking about what they are doing instead (waving their problems to be handled by us).

There's a difference. When you go to Court, the trial is public information and you can pressure them on the Press. Arbitration is private affairs, and so can bind you to silence: For NON-USA customers, your mileage may vary. International customer's rights are subject to the New York Convention, a generalist set of rules that some (most) countries agreed to abide in order to allow their legal systems to work overseas. Even if you live on Europe, you need to check how the New York Convention affects your rights. The countries that are member of the party can be found here, and I urge any European that thinks this doesn't apply to you to check it out. You will see that very few countries are not signatories of the New York Convention.(hint: North Korea, Iraq…). In time, China is a signatory of the Convention. It's exactly the other way around. I urge you people to give some credit to TTI's lawyers - they are not dumb arses. They know their trade. Companies are not a person. It's a opaque collection of people, and when you deal with a Company, you are dealing with all that people at once - one, only one sociopath inside there can use the power of the company against you (directly or indirectly), and once the sheet hits the turbo-fan, the Company will do what every Company is expected to do: to handle the situation minimizing the costs and maximizing the gains. In a nutshell: the Company itself may not condone license violations on their products (i.e, "stealing other people's open source works"), but once someone there tries the stunt, the Company will try to minimize the damages by forcing the copyright owner to a (in)decent agreement with them, including silence about the stunt. The guy that did the stunt? He can be fired, or he can be promoted - who knows? It's a Company, you don't know the people calling the shots there. — — — Example — — — From the newyorkconvention.org site, I found information about how Brazil handles this: Google Translating: "In the adhesion contracts, the arbitration clause will only be effective if the adherent takes the initiative to establish the arbitration or expressly agrees with its institution, provided that in writing in an attached document or in bold, signed or seen especially for that clause." "Adhesion contracts" is how we call "subscription agreements" (it's the best translation I found). EULAs are "adhesion contracts". Here at Brazil, agreements as EULAs are Contracts in fact - but we have a whole legislation about how to handle Contracts, and so such agreements are subject to the local law. Of course, a deep pocket American Company can overcome this - but at least, not in privacy - so we alway can get into the Press for some P/R trouble. In a nutshell: Brazilian's Law saved my cheeks [I love how Forum replace some terms! ] on this, and you, non-American, must do the same research and check yourself about your country rules on the subject. Don't rely on common sense. Most of you, guys, are living under the Rule of the Civil Law, you must find a Law on the subject

Wrong thread!

Good! You are learning! Walk on the safe side and use "Game Modding", if you please. But I still think that for someone that sells medicines, it's better to tell people "I'm a pharmacist" than "I'm a drug dealer". But, hey.. It's just me.

No, it's not dangerous. KSP comes without it, these are things that Steam install itself. Non Steam users doesn't have such files - and since @Friznit published his logs, I could compare them with the others people sent me (all the two of them ), and they all have downloaded KSP from Steam. Long shot, but it makes sense. The worst that can happen is KSP not running, and all you have to do is to copy the files back. A bit of historical background: SysWow64 is "System for Windows 32 over Windows 64", and it's where they put 32 bits DLLs for 32 bits EXEs running on Windows 64. System32 is where they put 64 bits DLLs to for 64 bits EXEs. Don't ask. It's Microsoft - they always were this way. — — — — And yet more historical background — — — — I just remembered something -I should had studied for Paleontology or something like that. A long time ago, in a 16bits addressing space away, 640Kb was enough to anybody. I'm talking 1981 and IBM PC-XT here, 640Kb RAM and 386Kb of available ROM space, 1Mb of addressing space. Of course, for years every device drive ever written (we called them TSR - Terminate and Stay Resident) was made with the 8088/8086 in mind. Sooner, 640Kb was not enough anymore, and someone came with a stunt called GATE A20 - they took one sparing pin from the keyboard controller and used it to simulate a 21th address pin (1MB is addressed with 20 pins, 2^20). With that stunt, they allowed some special cards to shove 64K more memory above the top memory (where usually was the BIOS). They used this place to store some device drivers, and so free up the base memory (that first 640Kb thingy). Nice. So what? Why I'm telling this? Well… Some device-drivers were buggy, and sometimes forgot to change the A20 line before jumping into there - and then that memory wasn't enabled and the system crashed. Sometimes, they forgot to disable the damn thing before returning, and then some code using some old tricks of that era ended up overwriting that memory by accident, and then the system crashed. (at that time, we were used to save every possible byte of RAM on the routines, and so sometimes we relied on some hardware properties to induce the desired behaviour, saving some 3 or 4 bytes by omitting the ASM equivalent of a "IF"). All that 4Gb frenzy I saw here made me remember this stunt - we are talking Microsoft, anyway. When you make a "far call", you push into the CPU's stack the current address so the CPU can RETurn to it later. When you are in 32 bits mode, of course you are using 32 bits memory address. But now consider that when you are in 64 bits mode, the CPU needs to PUSH a 64 bits address pointer, so it can RETurn to ir later. If you PUSH a 32 bits and later RETurn in 64 bits mode, you would ending up POPing two unrelated 32bits values and the CPU would ending up RETuring to God Knows where in the memory addressing space. Likewise, if by accident you made a FAR CALL from 64 bits to a 32 bits routine, if you mess up something, you end up POPing just half the address you really needed, and God knows where in the first half of memory would the CPU ending up RETuring to. Do you remember that JIT thingy? It's a routine that "recompiles" CIL bytecodes (what C# uses for compiling source code into) into native X64 machine instructions. This happens everytime a CIL code is executed by the first time (on demand) or when the DLL is loaded (on loading), it depends hw the VM implementor decided to do. I think that Mono uses on demand, as it appears. By analysing the source code for Hyperspace, I learnt that the Mono's VM has also TWO MODES, a 32bits and a 64 bits, being the 32bits locked down on that 4Gb limitation. And now I think you guys are realizing what I have in mind! Unity is the thing responsible for handling HMI (Human Machine Interface) devices, and Unity needs to cope with 32bits and 64bits environments. So it appears to me that Unity, somehow, is utterly borking on something on Space Center, that in essence, is a scene change from Main Menu to Space Center. The problem described on the OP explained that on 1.5.x (and previous), the crashes were happening while transiting from Flight to Space Center - sometimes, a lot of transitions were needed before the crash. Knowing KSP as I know today, I learnt that on 1.6.x KSP is doing some optimizations preemptively, and using more memory in advance on loading. Essentially, mimicking the problem we had before, but way sooner. At that time, I had postulated that, since it's usual that in each Scene we are transitioning from we close the devices we opened at start, and just reopen the devices we will need on the newly loaded Scene, things were crashing on xinput due a buffer or something that suddenly were relocated to a higher memory position after being reopened- it made sense at that time. But I was also thinking that CIL would be handling that 32/64 bits jump stunt in a somewhat smarter way - or I didn't knew that CIL was so dumb on handling 32/64 bits pointers, what is just another way to say the same thing. THIS log file, however, makes me wonder that perhaps we are handling a 32 bits FAR CALL from Mono to the XInput DLL, and once the memory use grows up enough (exceeding the 32 bits addressing limits), that FAR CALL cannot reach the native code from XInput anymore. Since JIT is involved, it's not impossible that Mono itself is causing the problem - but once I learnt that in C# the CIL program needs to handle itself 32 bits and 64 bits address pointers, it may be also another nasty bug on Unity (it's not a bug from Mono if Mono just doesn't have the feature, right?). t just happens that it's another bug than before, but with the same root causes. Again, it makes sense - a code that doesn't cope with 64 bits memory points will not cope with 64 bit address jumps. Being this the reason we are not being able to fix the damn thing this time by switching DLLs. Anyway, I just typed this Thesis here so I can remember this later, when someone else hits here with another similar issue.

Google is your friend: "Console Modding" "Console Homebrew" I rest my case, Your Honor. — — — POST EDIT — — — — (and avoid traveling to Japan. - yeah, things are going crazy there. I didn't knew about savegames!)

@GrandProtectorDark, I'm not on the mood for spin-doctoring with you. As I said before, you can call yourself the way you want. Just don't expect me (or anybody else) to jump suit with you. And don't be surprised to be mishandled by someone that are used to use that label in a unpleasant way. Just know what you are doing, as you can't always wave the consequences. And never, ever, go to Japan. — — — — — A side note: "Console Modding" is heavily associated to "tampering with the device" since the Sega Saturn days, one of the first VideoGames to be "industrially" modded as far as I know. I'm talking 1994, it's something like 25 years. Every single time, from the past 25 years (or more, Sega Saturn is the first I'm aware to have a Mod Chip), you read about Modding and Console, you are talking about this. When people talks about things that people creates legally themselves for Consoles, we are used to use the word Homebrew, https://en.wikipedia.org/wiki/Homebrew_(video_games)

No. You are.

No. I played dirty. Modding "can" be illegal (as, for example, creating a Mod to circumvent a DMCA lock). But creating User Content will never be, because you are doing just things you are expected to do. My whole argument is that we must take some precautions about the way we label ourselves. If there's a way to call yourself something not associated (at least, yet) to something illegal, why insist on using a term associated to illegal activities on the press? But, and again, it's always your call. I know, you know, @GrandProtectorDark knows that here, on this forum, "Modding" is about writing DLLs to change the games behaviour, but also creating image and data files that KSP interprets as Content. But out there, in the real World, "Modding a Console" is heavily associated to Mod Chips and piracy. I think it's prudent to be aware of that. Squad surely was prudent, by using the term "Add On" here on Forum.

No! You are. I'm just playing your game. As you said before: These guys decided to call some illegal activities to "Modding", and that guy that was arrested is a "Modder". Complain to Ars Technica, not to me! Now, try to find something as "User Content Creator was arrested by illegal User Content Creating", or "Gamer was arrested by creating illegal Add-On". But, and again - your call. You are free to call yourself the way you want. Just don't expect anyone else to call you this way.

Ok. How about California? https://arstechnica.com/gaming/2009/08/modder-arrest-a-reminder-that-most-console-hacks-are-illegal/ As far as I remember, both XBox and Playstation are sold on California, I'm right? Now, I'm playing a bit hard. But life is what life is. You can sell medicines, and call yourself a "drug dealer" - what would be not incorrect, but yet you will not like how people would handle you if you say 'I'm a drug dealer'. As I said before, you can call yourself the way you want. But you don't have how to control how people will handle you based on what you tell about yourself. "Modding" can mean many things, but "Add'On" and "User Content Creator" narrow that to things that are near what you really are doing. But, again, your call - your life, your problem.

I'm not exactly a genius on interpreting logs. What happens is that I'm truly prolific on logging borks (not a surprise, I made most of them), and so get used to where to look for things on that mass of data. It's like a dog smelling something he doesn't like - we don't know what it is, but hell, it smells like trouble. (I once detected a way to inject a RESET 00 - a hard reset routine! - from user space into the Kernel on the Windows XP - of course, on a Lab full of stakeholders. Our Bug Report on Microsoft probably helped to rush the SP1! Honest!) Well, your box managed to get something that bad, as it appears (put on a spoiler to prevent visual polluting) On the exact moment the Space Center Scene Camera 2 fires up (whatever it is), the Mono's JIT borks beautifully trying to access some memory address. I took randomly one of them, 0x00007FF707006AC7, that it's 140698951117511 in decimal . Something on the… 127th Terabyte. What's make sense, one of your logs says 134217728 MB user address space [134198310 MB free]. Giving us exactly 128Tb of addresses to your program (and yeah, you only have 32Gb of physical RAM, a small fraction of that - it's a virtual memory thingy, you can ignore this for now). Knowing how C compiles code, I known that the TEXT segment (where compiled cpu instructions 'lives") is on the beginning of the process' address space - you can see that on the "Mono JIT Code" lines - Mono is written in C/C++ - and the later address us for the HEAP, a place we use to store data on runtime (as text, sounds, images, meshes, etc). Do you know what? Everything is fine here. The problem is somewhere else. I did all of that to make it perfectly clear that this is not Squad's fault - Squad may have borked when things borks inside that memory space above (as it's there where anything they do "lives", as they develop in Mono, not C++ - and Mono byteodes are just data for a C++ program). If you care to check my past posts, you will understand why I found relevant to talk about. Well. Let's try again. So I got back to the stacktrace, and your Stack Dump starts with something really interesing: Crash!!! SymInit: Symbol-SearchPath: '.;C:\Users\Alex\Desktop\KSP 161;C:\Users\Alex\Desktop\KSP 161;C:\WINDOWS;C:\WINDOWS\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;' You see that "Search Path" thingy? If the order in which looks for DLLs. "." is the same directory as the KSP_x64.exe being executed. Now tell me; how many "xinput1_3.dll" are present on your system, and where they are? Just to get this of the way. You may be loading the wrong xinput — your crash logs says you are using "C:\WINDOWS\SYSTEM32\xinput1_3.dll" . I suggest you find a "good" xinput.dll and shove it in the same place KSP_x64.exe is, so it's found first and you don't take risks running it from somewhere else. I'm assuming that you are using the "right" xinput from now on. I found an interesting post on it here from Skyrim forum Yet, another interesting thing. Skyrim uses a 3D Engine called "Creation Engine", proprietary from Bethesda - completely unrelated to Unity. However, this hints that my previous guess about the issue were correct, at least for KSP 1.5.x - there's, indeed, an issue while handling XInput when your process is 64 bits! (Microsoft being Microsoft). Worse, we learnt that XInput is not only a source of the problem, but also the unhappy idiot that accepts the blame when it's not. Otherwise, that guy from that post would not had received the second crash. Right now, I have two propositions to you: Delete GameData\Squad\Plugins\KSPSteamCtrlr.dll from your Plugins directory and see what happens. If this thingy uses xinput too, it would have the same issues! Since we are on the mood, get frenzy and delete also KSP_x64_Data\Plugins\steam_api.dll. One less thingy to care about. Of course, make backups Delete all the xinput1_3.dll from your system (make backups), and see what happens. Something, somewhere, appears to be still tied to that 4Gb stunt. It's too much information mentioning this to be just a coincidence (besides not being impossible). Humm… Just to be sure, run this on your system: https://www.memtest86.com

So, laziness is ethical for you?

Of course not. As much I don't have any evidences that your speculations are true. All I have is my past experience on the field, my present experience on some feelance jobs I took, and my observations from one year of Forum and Game participation. And, of course, some ethics while arguing with the fellow Kerbonauts, as I try to always mention my interlocutor so he have a chance to answer me quickly by being notified by Forum.

No, It's about to know what you are doing. There're legal consequences on modding Consoles (see Japan), but there're no legal consequences on Adding Content to it. You go to Japan and yells "I'm a Console Modder", you are arrested. You go to Japan and yells "I'm a Console Content Creator", you risk being hired. Your life, pal. Your problem. You can do whatever you want - but cannot wave the responsibly from the consequences of such acts.

Again - standard industry procedures. Things change overtime, product owners are replaced, and so on. Building things, testing things, solving puzzles - these are individualistic tasks. The only Add-On I'm aware where multiplayer would make sense is BD-Armory, but this twists KSP into a war game, what's essentially what's KSP is not intended to be. Multiplayer gaming also demands a layer of security that it's essentially incompatible with modding - everybody must share the very same codebase (including glitches and bugs) in order to keep the competition fair - and there's always a competitive element on multiplayer. Thinking on it - perhaps a BBS style of gaming would make more sense for KSP, something like the DARPA calls for proposals. That would make things interesting too. On that, I can agree. P/R is a nightmare, and they needed some serious professional P/R on many subjects. On the teams I had worked with/on , we plain shielded the developers from the stakeholders to the point of imposing fines to any stakeholder that would attempt, and to fire any developer that had allowed. And given the backslash Squad is facing here, now I can see the reasons. Well, mea culpa, mea maxima culpa. That was the phrase the triggered me off last night. Being picky, your argument is a False Cause Fallacy - there're no logical connections between the facts that would allow you to make a logical inference on the thing. My error was not being able to calmly explaining it to you, and sometimes I think this is a diret consequence from my past on some professional circles. Well, sorry for that (even if you didn't had read it). You assumed that Squad hired the guy to incorporated Sounding Rockets, and not by the competence he showed by making Sounding Rockets. The guy could had be hired to to anything completely unrelated to modding at all - companies hire people for what they expect him to do in the future, not due what he had done in the past (this last one is just hints about what can be expected from him). It's a good guess. I think this is at least one of the main components of the problem. Dirty secret of the industry: half of the things I do goes to the trash bin. From the that half, half is trash. I make my money with the remaining - but only half goes to my pockets. Standard business procedures. Real Life is dirty, messy, convoluted and unforgiven. We err more than we do right - and anybody that tells you otherwise is one that earns his living from other's people works, and not from his own work. This industry still lacks some competence on predicting the future. PROTOTYPES. They had the bad idea to show us a prototype of what they were doing. They had the illusion that this community had the willing to see the game thrilling, and decided to shared with us their thoughts. Not being allowed to explain with details the road map made things worse, but was not the root cause of the mess. Bad move, as we can easily conclude by now.