• Content Count

  • Joined

  • Last visited

Community Reputation

3,955 Excellent

About Lisias

  • Rank
    Boldly crashing what no Kerbal has crashed before!

Contact Methods

  • Website URL Array

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Microsoft now owns Github and Bethesda. Right now it's Sony who's getting their balls kicked, but... Tomorrow? How this will affect the Open Source Add'Ons scene?
  2. Hi! Got it. [LOG 01:05:42.286] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container1 (SC-62 Portable Container). [LOG 01:05:42.286] [TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Portable Container) has a fatal problem due having duplicated properties - see issue [#34]( ). at error:0 [LOG 01:05:42.286] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container2 (ILC-18k Container). [LOG 01:05:42.286] [TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Container) has a fatal problem due having duplicated properties - see issue [#34]( ). at error:0 [LOG 01:05:42.287] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container3 (ISC-6K Container). [LOG 01:05:42.287] [TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Container) has a fatal problem due having duplicated properties - see issue [#34]( ). at error:0 Yep, known issue. What's happening is that you forgot to completely clean up the older TweakScale folder before installing the new version - and since some things are changing on TweakScale, by doing that you ended up with some oldies left polluting the instalment: [LOG 01:01:52.195] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] [LOG 01:01:52.789] Applying update TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] Completely delete the TweakScale folder and reinstall it from scratch and you will be fine! Cheers!
  3. I was (re)reading the Unity documentation, and I just realised that I misunderstood the vsync. When you activate the vsync, the FPS is ignored - and, frankly, I don't know how in hell I could had missed this detail. Just for the piece peace of mind, turn off the V-Sync option ("Don't Sync") and keep cranked up the Frame Limit. If this doesn't trigger the TLA on you, then definitively the Particles are not he culprit for this. And, by the way, magnificent screenshot!
  4. You have Bluedog installed twice on your rig... [LOG 15:30:24.206] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] [LOG 15:30:24.210] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Gamedata/Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] <yada yada yada> [LOG 15:30:29.962] Applying update Gamedata/Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] [LOG 15:30:29.966] Applying update Gamedata/Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Gamedata/Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] You unzipped Bluedog on <KSP_ROOT>, but also on <KSP_ROOT>/GameData , and so everything is duplicated. Remove the Bluedog from the KSP_ROOT (the folder where your .EXE is), and everything should be ok. Cheers!
  5. I don't know, but you may had found something new. Perhaps the thing is related to something on DirectX, not OpenGL. And since MacOS runs under OpenGL, it may be the reason I never managed to get something like this here. New test - configure your KSP like the last time you got that TLA. Try to get the TLA, and once you manage to get one, change to OpenGL and try again. The hard part is getting a TLA intentionally, apparently...
  6. I think that we need to find a "sweet" spot where the GPU is rendering faster than the CPU can feed it - it's what I am thinking is happening with the TLAs, pretty damn good GPUs running over not up to the task CPUs. Try it again lowering the textures to the minimum bearable, as well lowering the rendering quality (so the 3D engine use less vertices on the mesh). But keep everything else up. The intention is to overload the CPU while speeding up the GPU, to see if this really is the problem on the TLA - particles is a good educated guess, but at this moment it's still only a guess. We manage to artificially and deterministically reproduce the TLA, the Squad guys will have something solid to start debugging on to fix it on the next versions, and we have a starting point to find a (or confirm an already existing) workaround to be used on the current and previous ones.
  7. So, what do you think of a TweakScale Companion for USI? Doing this way, both of us would get rid of a headache - you, by not maintaining an artefact you don't want to know about and don't use, and me by removing an unrelated artefact from TweakScale. Any heat is taken by the Companion itself, and it's the Companion's maintainer problem (being this guy that other me, not me). From your side, just tell people to talk to this guy on anything related to TweakScale and you are set. The Companions are designed to cope with legacy.
  8. Ei, @yeyehboi, I think you will like this one!
  9. Could not decided if I post this here or not, so I flipped a coin. Kraken damned coin, I say - this is its fault. Open the spoiler at your own risk.
  10. KSP specifics, if any on this case, will be handled by KSP-Recall. Every single Add'On I lay my dirty claws on is aimed to work on every KSP version still in use. Sometimes I win, some times I loose - but I really try hard.
  11. In the 80s, the read/write heads were way.bigger than nowadays. And so more prone to the inertia. At that time, we were still using MFM and RLL technologies, not too diferent from what was used on floppies by the way. With the software having direct access to the step motors and solenoids, yes, it's feasible to abuse the mechanism by stepping the motors faster than the design allowed, stressing the heads' mounting and leading them to crash into the platter. Nowadays every HD has its own CPU for doing this - hard disks are essentially specialized computers atached to a host using some kind of network. But at that time, the hardware was fully exposed to the userland. The even older MSX computers had a design flaw that allowed the PPI (a peripheral control chip) to be programed in a way that it could short-circuit itself and burn, rendering the machine without access to joysticks and the keyboard. And yes, they wrote virus for it. And yes, that PPI chip was expensive.
  12. Yes, it was. Not a problem on asking for it. I ask myself for them too! The problem is lack of time for proper testing. The Robotics introduces a lot of new Modules that I do not fully understand yet, and need time toying them to see what happens. I have a video made from the times I was toying with the wheels, so you can see how deep the rabbit's hole goes: And even when I manage to make the damn thing to work, surprises are always well hidden somewhere, waiting to bite you in the SAS. These things are not exactly 'show stoppers', are just problems to be solved. But this demands time, and if you are following TweakScale development, time is a very scarce commodity lately due an avalanche of not directly related problems I need to solve in order to do my job. I have a road map for TweakScale here. Serenity is planned to be tackled down on ( is what I'm working now, and it will be focused on Variants)
  13. What is a serious maintenance nightmare. Why TweakScale should need to be aware of USI, when the patches [and the converters] are on USI itself?
  14. Nope. Theoretically this is on USI's shoulders. USI MKS and LS has embedded patches for TweakScale, the support is added there, not on TweakScale - so changes on USI that affect the patches, ideally, should be applied to the USI Patches itself, not on TweakScale that doesn't even have them at first place.
  15. Soon™ . I'm currently tackling down Variants on TweakScale (including Attachment Points), but the thing is fighting back fiercely (and KSP 1.9 is not making my life easier). But once I manage to make TweakScale understand Variants, doing the same on the Welding Tool will be trivial. I have a working work around for this however, and it should work on both forks (mine and the oficial one). Add <ModuleAttribute AttributeName="ModulePartVariants"/> on the <ModulesToIgnore> section of moduleAttributeList file. Any variant applied will be ignored, of course. But at least you will avoid the Variant Welding Mess for while. I understand this is far from ideal. But I'm kinda of overwhelmed as there're really few people really maintaining things lately - what renders me insanely task switching to cover up holes everywhere and this is delaying everything I'm doing.