Lisias

Members
  • Content Count

    1,428
  • Joined

  • Last visited

Community Reputation

1,179 Excellent

4 Followers

About Lisias

  • Rank
    Boldly crashing what no Kerbal has crashed before!

Contact Methods

  • Website URL http://lisias.net

Profile Information

  • Location Universe ! Virgo ! Milkway ! OrionArm ! SolarSystem ! Earth ! America ! SouthAmerica ! Brazil ! SãoPaulo ! Capital ! Home ! LivingRoom ! MyChair
  • Interests KSP, what else? :)

Recent Profile Visitors

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

  1. Lisias

    Thread to complain bout stuff

    Banned for staying away from her… Oh, wait… Wrong thread.
  2. I think the button is working on this fork. https://github.com/net-lisias-ksp/UbioWeldContinuum/releases It's many KSP Versions since I touched this, I don't have the slightest clue how this thing will behave on the new parts and with MH installed. The only thing I know is working by now it's the button. Dependencies: ClickThroughBlocker, ToolbarControl and KSPe. You need to use Module Mananer 3.x, as the 4.x series has internal changes that break mods trying to use its functionalities the way UbioWeld does. Known Issues: The last time I used this, I was using 1.4.1 without Making History. Any new part from 1.4.2 and forward (and MH) can or cannot works - anything using ModulePartVariant is expected to bork and inject some nasty NaNs on the gameengine. You need to be using a Module Manager from the 3.x series. UbioWeld will not work on the 4.x series for while I detected the problem with the MM4, but I didn't tried to understand it in order to fix it. The easy way out would be undo the MM4 change on that specific spot on my personal fork, but that would break expected behaviour - that guys are the reference for MM. So the logical move is to update UbioWeld to cope with the new MM at the same time keeping legacy compatibility to MM3. I will tackle down this sooner or later - probably later.
  3. Lisias

    Thread to complain bout stuff

    This 23 hours and 56 minutes (and 4.1 seconds) per day stunt of nowadays are a pain in the sas - it's just too long, I get sleepy too soon for my taste. I miss the good old days with 22 to 23 hours per day. That was perfect.
  4. Lisias

    [WIP] Infernal Robotics - Next

    Yep. It's confusing to tell you the true. I got "late" to this thing - on the last quarter of 2018 more or less, I had the need to use KJR, but I was on the 1.4 series already, and Ferram wasn't interested on migrating KJR to it. So I cloned his repo and started to study the thing to adapt it to 1.4. Later I realized that KJR were working fine from all versions of KSP since 1.2.2 (with a binary that I compiled for 1.5.1), what hinted me that in reality, KJR is a mod for Unity. Anyway, i found a branch merging Rudolf's code that was been unmerged or something like that, reapplied the code because it looked pretty good and I even added some bells and whistles until someone found it and tried it and then ask me for some help on it. It was just by then that I had realized that Rudolf opted to withdraw his repository. There're other forks from KJR available, but apparently mine is the only one with Rudolf's code merged and "maintained" ("kind of" because I intended to use that fork only for my own crazy ideas, since that dependencies). It's not impossible that Rudolf's code can cause some collateral effects on some mods (I'm not aware of any case - it's a theoretical hypothesis), as there must be a reason to the unrmerge (perhaps Ferram had another idea to solve the performance tax, who knows?). But now, at this moment, this code is the best KJR available for my needs. For a mile. In time, I updated my previous post with the test run without any kind of joint reinforcements. Now we have a base line for comparing performances.
  5. Lisias

    [WIP] Infernal Robotics - Next

    MacMini mid 2011. i5 Mobile 2.3GHz, Intel Graphics 3000. The IG3000 is not the problem, Elilte Dangerous works fine on it. The real culprit is the i5 Mobile *and* that nasty memory compression adopted by Apple and made not only the default option, but the only one since El Captain (I miss Mavericks). However, there's the thing: by making tests on the worst machine I have, I can easily measure differences on code performance. Any single bit of improvement are noticeable, and that's the reason I develop on that MacMini. (that is fast enough on every other task, except running KSP… That thing has 16Gb of memory). And thats the reason I can say for sure that Rudolf's code does not taxes the CPU, while the original does. (recording the screen does not impacts at all the FPS. The i5 is good enough. The problem is on software) — — — — — — I redid the very same test, using the very same KSP Installment, with the very same mods (including the ones that I mangled and are throwing Exceptions), but using "Stock" KJR recompiled without the KSP version restrictions, the one I mentioned above. The differences are noticeable, the performance tax affects even the Toolbar scrolling. The IR/Next parts not working can be easily fixed by adding IR parts to the Exceptions List, where you define what parts should be ignored (If I remember correctly, they came pre-installed on KJR/L). My verdict? I can't see a single reason to avoid Rudolf's code. It may be some glitches yet, but his code is way faster than "Stock's". — — — — — — And, finally, the same KSP with the same vehicle but without any kind of joint reinforcements (not even auto-struts):
  6. Lisias

    [WIP] Infernal Robotics - Next

    Well.. I was planning to publish this thing on the weekend, with a video showing it on work. But I will spoil the "Premiere" (hehe) here, to show you guys the excellence of the work done by Rudolf until the moment. It worths it. This is a 142 parts vehicle, with Rails, Hydraulics and Hinges working in tandem. There're some glitches, and perhaps some of that glitches are on the IR/Next code (as a Rail that I just can't adjust correctly the speed/acceleration, and a Hinge that doesn't mirror correctly), but yet, the thing is working where it really matters. I managed to build this thing without the need of KJR, but fired up my MacPotato with KSP 1.6.1 and KJR/L to see what I get. This vehicle was already pushing my potato to its limits, so it's a perfect test case for KJR/L (that is, in essence, KJR/RM with some fancy whistles). I guarantee you, guys, that my MacPotato behave in the very same performance with KJR/L than without it using this vehicle. The same bad performance, to tell you the true. This video wasn't edited in any way. It's the raw footage of the Performance Test. The KSP.log of that session is on a link on the video, and also here. The Infernal Robotics Next download is on this Thread OP. The KJR/L is available from this post (link to this forum). That video proves that yes. It works with IR/Next on 1.6.1 . KJR/L was tested on every KSP version from 1.2.2 to 1.6.1 (seriously!! I swear!). I think I installed IR/Next on a 1.4.x KSP, but don't remember using it. But it worths a try, go for it.
  7. Lisias

    [WIP] Infernal Robotics - Next

    (shhh… don't talk that loud!) Let's try this first. I heard of a guy that took the original ferram4's code and deactivated the KSP version check: https://forum.kerbalspaceprogram.com/index.php?/topic/50911-13-kerbal-joint-reinforcement-v333-72417/&do=findComment&comment=3507600 I didn't bothered to check for myself, however. You are on uncharted waters (at least, on my router). Try it and see what happens. Perhaps it would fits for you. I have a hunch that your problem is KJR/RM recalculating the joint lists, once your aircraft "misses" some parts. If I'm right, you should experiment "worse" performance on the overall, but a bit less "cranky" decoupling. Well, you can't have the cake and eat it too. Let us know what you find on it. Perhaps, there're still some optimization waiting to be applied - and it's time to give Rudolf something back for what he had done - and he did a lot.
  8. Lisias

    [WIP] Infernal Robotics - Next

    For reasons way off-topic, the maintainer choose to drop his repository for his fork of KJR. Currently, the only available fork using his (very good) code is this one (please read the fine print - there're some unusual dependencies). This fork's maintainer is doing his very best to keep things up, but he's not MeiruMeiru - give him some slack.
  9. Well… It's after work by now. Let's properly answer things. What doesn't means you wont suffer from it. TweakScale is somewhat loud while being a Screaming Victim because TS mangles with a critical datum on the game: mass. Almost everything need the mass somehow, and since we are not talking about Quantum Physics simulation, everything needs to have mass. This misbehaviour, by inducing TS to apply zero on the part mass, make the thing critical. But this doesn't means you are immune by not using TweakScale. Even by uninstalling it, you are still prone to the problem in the event it hits another module. And if such module also mangles the mass of the part, we have another source of trouble lingering to show its ugly face. I just managed to get TweakScale out of that nasty chain of events. But I can't prevent any other link to close, so more chains of events are still possible. I'm not satisfied with this, but at the moment, it's all what's possible to be done. And this is why things are going kaput around here. It's not about "ego", it's about maintainability: this fork of TweakScale is the reference for… TweakScaling. Its perfectly ok to disagree with the Defaults and mangle with it, but not in a way that breaks TweakScale and KSP. Personally, I have no love for the patches included on TweakScale, I would gladly give up on most of them to third-parties (the main focus of the TweakScale3 - The New Breed, by the way) - they are a huge surface of attack for bugs the way they are right now. And you stated that clearly (and rightfully). Again, it's perfectly OK to an Add'On Maintainer to have his personal ideas about how his/her parts should TweakScale - and they are more than welcomed to apply pull requests to this repository, or even request being the official Maintainer of such patches (what makes every sense in the World), situation in which I would delete such patches from the main distribution (and then, they would be distributed on an "Extras" directory, for people willing to go old ways). On the bottom line, TweakScale needs your help in order to proper help you. Otherwise, nasty things will happen - as we can, easily, observe on this last two releases. As I said before, that would accomplish almost nothing. Besides the fact that TweakScale should be the reference for scaling (as it is, well… needed for scaling the parts! It's like buying an car, switching the fuel system, and then complain to the manufacturer about a bad engine performance!), this would not prevent any other Add'On to induce the problem by itself. Two rogue patches named before TweakScale (ascii ordered), or a single one named after TweakScale, and we have the problem again. There's no way TweakScale could cope with this alone, everybody need to follow the rules - or KSP will ending up crashing sooner or later. Point. Your suggestion about the "FOR:", on the other hand, is valid. I'll check it myself as, if anything goes wrong, I am the one that need to understand and fix things. But other than that, I'm pretty sure I will jump suit with you on this - by not doing that, I would be the one preventing others to follow better rules, and so, I would be part of the problem. (I'm managing to get myself understood on this? Sometimes I don't know when I'm being too much verbose - I just need to prevent misunderstandings - I'm not complaining about people disagreeing with the TweakScale defaults. My problem is what's happening due such disagreement happening without I'm being aware of it) Known issue, to be tacked down on TweakScale3 - The New Breed. Related issues: https://github.com/net-lisias-ksp/TweakScale/issues/2 https://github.com/net-lisias-ksp/TweakScale/issues/7 https://github.com/net-lisias-ksp/TweakScale/issues/11 https://github.com/net-lisias-ksp/TweakScale/issues/12 https://github.com/net-lisias-ksp/TweakScale/issues/13 This is smelling as a unhappy merge done late light. GIT was built with C code in mind. This will be fixed. https://github.com/net-lisias-ksp/TweakScale/issues/23 Ha! That's funny. So the Tallinu's report was indeed about a second occurrence of the problem! I had run out of time for modding, and left this alone to be dealt later, once any really nasty consequences were handled. This is now just an annoyance, not a problem. Bur once you nailed it for me, https://github.com/net-lisias-ksp/TweakScale/issues/24 Right! However, this is far from being… convenient. An automated tool is needed. Talking with the Kerbal-X as I brainstormed above is not the best approach, now that I thought on it twice. There're the Steam Workshop guys too to care about. But the solutions are not mutually exclusive, once I manage to fix what's pending for a 2.4.1.1 release, I will see what they think about. Exactly again. I'm happy to see I managed to pass the message through, besides my English skills being somewhat compromised by the tiredness. Detecting , reproducing and cooking something for it was a somewhat heavy task. Right again. However, at that time, I was too worried and ended up choosing to be safe than sorry. Resaving everything is safer than asking a user to open a file "God knowns where in the filesystem" and visually inspect each part. A considerable amount of users are not tech savvy. Obviously, I could made a second post with most accurate details, but… Dude, I was wasted. I slept until Sunday's noon next day. And had a lot of house keeping to carry on! (still have, but I didn't said that) "%" would work only if everybody is used to agree with some rules. But if that would be the case, we won't had this marvelous mess to cope with at first place, so… Problem is - TweakScale make heavy use of presets. And a preset is exactly as it says, a preset. I thrust that presets, and it's with that presets in mind that deliver the "product". At this present time, I have no idea how presets will behave with the "%" - and, frankly, I have no time to spare to check 444 use cases of them. (check for yourself, the command is "find . -name "*.cfg" -exec grep -H "#" {} \; | wc -l"). The use of the :FOR, on the other hand, is pretty straightforward, well documented (with some glitches ) and broaded used. Way easier to cope. So I'm going for the :FOR . It's a somewhat more proper solution, by the way, as it self documents what :NEEDS to be done. (ugh… I think it's time for some rest). Of course, I still :NEEDS that everybody correctly follow MM rules, so in the very end this is so good as to try the "%" stunt. Or even doing absolutely nothing - the net result is, currently, exactly the same for all options. But the :FOR allows me to be part of the solution, not of the problem, and it's "cheaper". What, frankly, it would be way better - Add-On's authors/maintainers following the rules, and them blaming me for not doing the same. I just imagine how many of the crashes I had on the past year would not be related to this. (I'm positive that not all of them, I identified some other add-ons crashing KSP too. I didn't forked all that net-lisias-kspu hierarchy just because I don't have anything better to do! ). DAMN! Just now you tell me that? Jokes apart, I'm the current responsible for TweakScale, so in a very specific and non-personal way, yes, I am the one to "blame" every time TweakScale misbehave. I'm not saying I'm the one to fix every possible glitch (as this one), but once TweakScale is involved, I should respond (the real meaning of responsible) about. To cry for help sometimes, but yet, it's a response. Otherwise, we will destroy the very thing we intend to enhance, KSP itself. We, modders, don't have a duty on keeping KSP error-free, of course. This is not a job, we are not getting paid. But we are committed to a task: enhance KSP. In my humble opinion, once you publicly commit yourself to a task, you must do your "better" to carry it on. (but, again, giving the better of you is not the same as doing the "best" - this is not a job). About Module Manager and TweakScalem they are "old". The very first TweakScale version on CurseForge dates May 16, 2014. This thing was intended to run on KSP 0.23.5 ! I didn't found Module Manager on CurseForge, but from the Maintainer's repository, I learnt the the very first commit for the project dates May 6, 2013. Barely a year of difference. A LOT of water crossed under the bridge on these 4 to 5 years. A lot of things changed. And some of them got stuck in the past or just forgotten. I expect some more glitches ahead - it's the main reason I taking some pain to implement safeties now. I think it's related to how things were architectured on KSP and Module Manager in the past, and how things changed, and how MM had to change too without breaking legacy behaviour. Given the current status quo, I think that :FOR should not exist. It should be the bare default on every patch. But even by me being right on this assumption, Reality talks louder. By doing the "best thing", sometimes you cause such a breakage that the net result is negative. Sometimes, you just can't win a battle - all what remains to be done is to lose it the less costly way possible and live to fight another day. — — — — — — Hey! I found a Forum bug! If you forget an empty code block (or apparently, an empty box of any kind), everything below "collapses" to a quote box!
  10. Fair enough. This will be work in progress on my first free time window (probably some night on the next few days). You can keep an eye on this here: https://github.com/net-lisias-ksp/TweakScale/issues/21 Because it's working. MM 4 introduced some changes that *can* (I'm not telling it is, but since I didn't checked it enough to be convinced about…) be playing some role on the problems above. So, by keeping it on this long time tested version for the minimalist users, I expect to reduce a bit my "surface of attack" for bugs. Of course, most users had updated to MM 4 already. Well, so is the life. MM is known to cope well with older copies of the MM, deactivating automatically the older copies, so this is not a problem for bleeding edge users. Documentation "Sheet" happens. MM's documentation is better than most "corporate grade" software I had worked on my times on the big guys. If you are talking about the WIki from the GitHub's official repository, I bet my SAS the maintainer will welcome any fixes you both (Tonka and Tallimu) would apply. Bills and taxes eats the best part of our available awaken time. Something have to gave in on the process, and usually, it's the documentation. And yeah… I'm guilty too… So, https://github.com/net-lisias-ksp/TweakScale/issues/22
  11. That's the reason MM has the "AFTER[<MODULENAME>]" thingy. Mods that adds support to TweakScale must be sure themselves to run things after TweakScale, or things will break for sure. Otherwise, the only sane option left is to drop TweakScale support for everything else, and then every modder should be responsible for applying TweakScale patches themselves. About the remaining, I will read again by night. It's working hours by now.
  12. Install Toolbar Control and see if this fixes the problem. My guess is yes, but I will be sure only by night.
  13. Lisias

    [1.6.1] LightsOut Relit

    [ Hi! ] You forgot to setup the dependency for Toolbar control on the AssemblyInfo file. Anyone having problems to run this , try installing ToobarControl to see if it fixes it.
  14. MISREAD THE PROBLEM. <DELETED> About the "Seems like Lights Out now breaks Lisias' version of KJR." comment, I will investigate. Just to be sure: you are talking about this one? https://github.com/linuxgurugamer/LightsOut Just checked, saw nothing that could do that by code - probably a falty DLL or unsatisfied dependency - situations that triggers an bug on the C# runtime that kills KSPe, that then kills KJR/L. Doens't appears to be a unsatisfied dependency, as anything in the code is tied to any other DLL other than KSP's ones. But the thing was compiled to 1.6.1, so, perhaps, we have one of that situations where something changed on the newer KSP that borks older ones (as that thing on the textures loading). I will check this by night, but until the moment, there's nothing perceptible on Lights Out that could cause this problem. FOUND IT! Lights Out needs Toolbar Control (it's being linked against it on the csproj file), but this dependency is not being stated on the AssemblyInfo.cs using [assembly: KSPAssemblyDependency("ToolbarController", 1, 0)] as the ToolbarControl OP says to do. Ask the maintainer to fix that.
  15. Craft files too. Any "tainted" (i.e., a craft saved by a tainted KSP) will have (potentially) that zero mass problem, including the ones you download from Steam Workshop and Kerbal-X. Until the moment, I don't have evidences that the mere presence of the tainted part is enough to cause "zero mass induced troubles". You have to scale that part on the editor to kick the update routines that would lead to zero mass. Parts already scaled will be reset to default on sane KSP installments, however, what will induce the user to try to scale it back - and then that nasty chain of events is complete. Assuming I know how to read code (hehehe), as long as you don't scale anything, you should not have problems. But once you export your crafts to Kerbal-X, anyone downloading your craft (unless it have a tainted KSP as yours) will be prone to the problem. This thing spreads. While you don't rescale things already spawn on the savegame, it's theoretically possible to do that - but you main concerning on savegames is that once the misbehaviour is fixed (what can happens at anytime the MM cache is rebuilt), all your crafts on the savegame that have scaled parts will have them reset to normal size, ruining your game. But, at least, this is perceivable. (KSP is so complex as an 90' Operating System - I'm telling this for almost an year already! Soon, we will have "MKAffee AntiVirus for KSP" ) Yes. Better yet, with the latest TweakScale, you are not prone to spreading the zero mass and the reset scaled parts mess by uploading an craft to Kerbal-X or Steam Store. What's make this misbehaviour nasty (and not only to TweakScale users) is that it affects everybody (and not only you) that use that file. So, if your tainted KSP exports a craft to Kerbal-X, everybody with a sane KSP that download that file are prone to the problem (unless their KSP is tainted and the misbehaviour is active on the same parts as yours!). There's a problem lingering however - the latest TweakScale prevents you to save new files prone to the problem - mas don't do anything when loading tainted crafts into a sane KSP. I prevented the infection to keep spreading, but I did nothing to prevent being infected. The nature of the craft loading subsystem of KSP makes my life extremely easy - it calls every part giving the respective node. But I don't have easy access to other loading part's nodes (or if I have, I didn't learnt it yet). That "MKAffee Antivirus for KSP" idea appears to have some merit, after all. So, in a nutshell: merely installing the newest TweakScale is not enough. It will only be able to act once you start saving your things. It can't do anything if your MM cache is rebuilt and the misbehaviour vanishes before you load/save your crafts and savegames.