Jump to content

Lisias

Members
 View Profile  See their activity

  • Posts

    7,370

  • Joined

  • Last visited

 Content Type 

Everything posted by Lisias

  1. Lisias
    This is not wise due reasons explained here: In a nutshell, it will wash the detectable symptom away, but the nasty bugs will by still there ruining savegames - and I will have to cook yet another sanity check to reach the same goal. What would made the whole effort useless.
  2. Lisias
    Advise your users before updating. This will break the savegames of every user your Add'On that have scaled parts.
  3. Lisias
    Essentially, we lost the control of the order and incidence of the parts being patched. We have some double patching happening on the wild, and this are triggering some unhappy events on the user's savegames. The problem is described on this post and its being handled by this issue.
  4. Lisias
    I think that, probably, we should think about that idea of deleting all default patches from TweakScale in order to make things a bit more "friendly" to users, what do you think? Alternatively, someone on TweakScale thread hinted another possible way to cope with that, by deleting previous patches before applying yours (didn't teste it myself yet): @PART[<part_name>]:NEEDS[TweakScale] { -MODULE[TweakScale],* MODULE[TweakScale] { type = stack defaultScale = 1.875 } } source:
  5. Lisias
    Yes, this is the main problem I need to solve since the beginning : the lack of ":FOR" on TweakScale Patches that would help to solve the ordering of the patches. It's what triggered all this checks, by way, as I realized early that this would cause some issues and started to implement the safety-checks. What caught me with my pants down is how widely these problems were already happening on the wild. I can't thank @Jammer-TD enough for the incredibly worthy help he did on the issue #42, by the way. I could had theorized the possible problems, but I was not aware of how much of them were indeed current until he hinted me about with his tests.
  6. Lisias
    That is TweakScale's default patching borking. Will be fixed for the weekend. If you are absolutely sure you are not scaling MK4 parts, you can delete GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg . This will make the Alert go away by bluntly removing all Mk4 patches (the good and the bad ones). on a side note: I have a savegame with Mark IV parts scaled. I confess to you that I'm finding courage to check that savegame!
  7. Lisias
    Fixed. Thanks for the heads up. I don't understand what is happening. By using https on the link, we get that weird red page. So I put http instead - that so redirects to a https URL equal to the link that was there before. go figure it out. Krakens.
  8. Lisias
    Well, I don't know from where is that patch, but you found the problem yourself. There're two patches for smallwingConnectortip on this file. And for tbmProp too. The good news is that the patch being applied twice have the same content, so this is that single situation in which this issue is not a problem - so your savegames are not at risk for this. But I recommend fix the file (search for every duplicate, and delete it). Ideally you should apply the fixes to the upstream, but I didn't recognized the file content (it's way different from the TMasterson's one), and there're no identification on it. Well… But this part of your problem is diagnosed. That's what matters now. About the fatals on the MK4 parts, these are TweakScale's fault - and, yeah, these ones are the serious ones. Sorry. I will fix this on the next minor release, that will be issue in this weekend. I will do my best to have this being published Friday night so you people don't lose another weekend due this. Until there, don't use any MK4 with scaling on your game or we will have some trouble on your savegames.
  9. Lisias
    Thanks. From your log, one of the problematic parts is smallwingConnectortip from AirplanePlus. However, there're no standard support for it (i,e., not from me neither from AirplanePlus maintainer), so I think that you are using TMasteron5's patches. However, your patches doesn't appears on the TMasterson5's original place, as we can see here: [LOG 09:19:19.017] Config(@PART[smallwingConnectortip]) AirplanePlus/TweakScale/@PART[smallwingConnectortip] Originally, it is expected to be on GameData/TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch.cfg . So I'm afraid I can't help no this for now. Can you confirm the source of the patch you are using? The following issues, however, are on me. I found that the MK4 patches from TweakScale are using wildcards, and are a potential source of problems. This will be fixed in the next minor release, that will be issued as soon as possible. Interesting. Appears to be something on one of the event handlers of the part. Yep, you are right - there's a good chance it's a bug on TweakScale's code. Opened a bug for it: https://github.com/net-lisias-ksp/TweakScale/issues/52 I will work on it for sure, but not for while. Please be patient. Thank you.
  10. Lisias
    How in hell we get rid of the stink of burnt popcorn? I was making some popcorns to make a bit easier some midnight oil burning, but suddenly I had that urgent call of nature and forgot to turn off the stove. Now I have a ruined pan and the entire house is smelling burnt popcorn. Terrible!
  11. Lisias
    Me too. Had Airplane Plus fixed that terribly overpowered engines (the small props has more power than an F18 engine!)? It's a long time since I used A+ engines, as I found KAX more reliable on this!
  12. Lisias
    I didn't gave enough thinking on the feature, granted. This will be implemented on the next minor release. Yes. Thank you for nailing this for me. :) It will be fixed for sure in the next minor release! The IR/Next guys found a problem on the "Classic" IR code that leaded to something like what you described. Could you reach them first and check if this is the same reason? If yes, and this is happening to Serenity too, then definitively I need to act. For reference, and assuming is the same thing, there's an issue about: https://github.com/net-lisias-ksp/TweakScale/issues/39
  13. Lisias
    I need your whole KSP.log, and probably the MemoryManager.ConfigCACHE too. Put these things on GoogleDrive, Dropbox or something and post the links. This will help me to identify the details of your installment so I can look for the trouble maker.
  14. Lisias
    Give me your whole kSP.log - from that, I will find the faulty patch and then I can fix that for your, while applying a pull request to the maintainer. I need the whole thing as it lists everything that is happening on your installment, including every Add'On. From this, I can locate the rogue patch (assuming it was not one of mine… ). — — POST EDIT — — @Kiro, I really need your KSP.log and I ModuleManager.ConfigCACHE too. M2X_EndCap is a part from Mark2 Extensions, and I just confirmed that the M2X's TweakScale patches are working fine on a minimal installment (M2X, Dependencies and TweakScale). So there's something else on your installment stomping some toes. I want to tell that the M2X patches are very well written (using :NEEDS and :FINAL - besides using "%" on value names, what would make diagnosing harder if the problem was it) so it's surely something else borking up things.
  15. Lisias
    Hi @RoverDude. I'm trying some changes as proposed here on the Principia thread. Some guys are getting trouble using Firespitter on Principia due it still using Rigibody.Part.AddForceAtPosition, instead of the Part one (something about allowing modules to inspect the forces being applied). I applied the @eggrobin suggested fixes and I'm using it for some hours without problems - but I didn't tried Principia yet, so I can't say for sure if this is enough. However, with newer modules using Part.AddForceAtPosition nowadays, I think that this hardly would be a bad move. https://github.com/snjo/Firespitter/pull/211 — POST EDIT — The pull requests were reissued against the branch DEVELOPMENT as requested.
  16. Lisias
    It's not a solution for this problem. But there're valid use cases for this operator! (but it would be safer not to use it together wildcards, I think) Yep, I will revisit that pull request. It may be related to some issues I had with SXT, but didn't found the time to properly address them: https://github.com/net-lisias-ksp/TweakScale/issues/14 (this is is about the FSBuoyancy) https://github.com/net-lisias-ksp/TweakScale/issues/17 They are on my backlog, I just could not find the time to address them yet. Yeah, I'm working on it already. I have as habit to, once I detect a problem, to check the whole history of the file to locate when the change happened. This gets me insights about the reason the change was made, and sometimes it prevents me to resurrect an old problem while fixing a new one. (public repositories are simply the very best thing that even happened on my life - except by some non-forum-compliant activities with partners of the opposite gender) I'm checking every stock patch AGAIN (using Shadowzone's voice) about the use of wildcards, and then for double patching (that will be hugely easier to detect without then). I have a nasty rogue patch on the Mark IV too, and I bet my SAS I will find some more. On a side note: This is going to be a bit painful on the short run, but it will make everybody's gaming better on the long run. Once we reach a good compromise on the status-quo, any mishap will be promptly detected while testing on the dev's machine before going gold. It will worth it.
  17. Lisias
    About the "%type" thingy, I want to explain again why this is terribly important. Consider the following scenario: Things are fine and good. Your vessels scale well. But then a new patch is applied on the GameData folder - an new Add'On, or perhaos an Add'On being updated. By some bad luck (and it happens - you, humans, are prone to err!! ), a patch is applied twice . Usually due using a wildcard on the name or the PART, but obviously, sometimes we just forget to check if we already patched it - or just don't check if the patch was already patched by a third party! So, in the next KSP boot, you get this: And, now, EVERY SINGLE CRAFT on your savegames that uses this part, be it flying or not, will get something as this: As we can see, it's pretty straight forward to detect the problem. In TweakScale there can be only one. So any duplication is necessarily the result of a Toe Stomping Fest between patches. If patches start to blindly use %type (or any other name) for values, we will have what follows: MODULE { name = TweakScale type = free defaultScale = 1.25 } And now it's not easily detected anymore, but till leads to the same results - corrupted crafts and savegames. So, and again: this stunt renders my Sanity Check useless, BUT STILL CAUSES THE PROBLEM. I want to make perfectly clear to everyone: I'm not patching symptoms, I'm fixing problems. Any symptom patch (as using "%") will just make the problem harder to detect, but will still corrupt the savegames and crafts.
  18. Lisias
    I will visit this issue soon. https://github.com/net-lisias-ksp/TweakScale/issues/50
  19. Lisias
    Add'On name, part name and more info, please. — — — — In the mean time, I want to stress it again: By using the "%" i in the type, you will get this: MODULE { name = TweakScale type = free defaultScale = 1.25 } What will render my Sanity Check useless, BUT STILL CAUSES THE PROBLEM. I want to make perfectly clear to everyone: I'm not patching symptoms, I'm fixing problems. Any symptom patch (as using "%") will just make the problem harder to detect, but will still corrupt the savegames and crafts. full text.
  20. Lisias
    I advise against the use of %type, unless you are absolutely sure it's what you want to do. Consider the following scenario: MODULE { name = TweakScale type = surface defaultScale = 1.25 type = free } This means that someone had patched the part as surface. THEN someone else had patched it to free. In the mean time, EVERY craft you created on every savegame you have will have something like this: Or this: Now try to realize what it will do with your vessels in space on in flight. By using the "%" i in the type, you will get this: MODULE { name = TweakScale type = free defaultScale = 1.25 } What will render my Sanity Check useless, BUT STILL CAUSES THE PROBLEM. I want to make perfectly clear to everyone: I'm not patching symptoms, I'm fixing problems. Any symptom patch (as using "%") will just make the problem harder to detect, but will still corrupt the savegames and crafts.
  21. Lisias

    If you are interested, that fork I mentioned is

    http://GitHub.com/net-lisias-ksp/Kerbal-Joint-Reinforcement

    Read the install.md as you need to install a dependency in order to make it work.

    The Next is on

    Http://GitHub.com/meirumeiru

    I don't remember the exact URL, but this one will present you with list. It's one on the options. This one has no dependencies.

    Try both and report any discrepancies to Rudolph. This will help him to help you.

     

    edit: ugh… I managed to mistype the name of my own fork. #facepalm - I was typing from mobile

  22. Lisias
    Well, my only contact with Unity is through KSP, so I don't have a clear understanding about the frontier between both . But mangling with KJR, I think I remember that it deals directly with Unity's data structures. Well, it's some time since I did. The rigid makes things less flexible but way more brittle. It's surprisingly near how things works on RealLife. Think on glass and lead - glass is harder, and it's exactly by this reason it breaks a lot. KJR 'classic' is essentially a Autostrut to grand parent with steroids - applied by brute force. it works, but taxes the CPU heavily. Continued is the classic recompile with some fixes. I got some good results using KJR/Next, but last time I tried it was for simple regression tests, before Serenity. So I can't say anything for now (keep in touch, I'll do a benchmark with all of them as soon as I find time) Before Next was born, I was informally maintaining a personal fork that somehow got some attention. It is based on an ancient code tree that evolved to what's Next nowadays. What do you think on giving it a try? If it works for you, contact the Nest's maintainer and tell about it. He wrote both codes, so he will be able to diagnose this! Yep, there're the physics less parts, but as I understand, they are just polígons being drawn orderly on the screen. Not sure how KSP would handle this. But it's a good insight, I didn't knew about it!
  23. Lisias
    How about post editions? My terrible grammars mistakes are eternized in diff entries on the forum database for the Moderation amusement for eternity?
  24. Lisias
    It's a trimmed down small subset of KSPe (my personal library for KSP with some tools and extensions to make my life easier) that is safe for broad usage. Essentially, every "official" mod of mine that needs KSPe service will have its own KSPe.Light embedded. I'm pretty tired of maintaining two forks, one without and another with KSPe and since I don't have time for now to overcome the bugs of that freaking pestilence called Mono's runtime (yeah, I'm pretty " liquided " with that thing), I came to this stunt. It's far from being what I want, but it will do for now. I would not use them if you are an Add'On Author. It will change on every release (it's tailored for TweakScale), and I hope to throw it away as soon as I deal with the problems I mentioned. Yup. On the hurry to publish the thing I forgot to properly name the file, it should be KSPe.Light.TweakScale.dll - it will be fixed on the next minor release.
  25. Lisias
    Moving from another thread: This is Kerbal Space Program. Physics work slightly different here. . Virtual Machines as Mono and Java makes things work differently. I would suggest moving this discussion to another thread, where I will gladly explain how exactly things work under the bonnet, but in a nutshell: GPU is marginally significant as long you have a minimally decent one and you are not using any visual Add'Ons MOAR VRAM is good, but it's only significant if your installment has a lot of new textures. If you blow up the VRAM's capacity, main RAM is used for texturing and the PCIe bottlenecks everything Less cores with higher MHz is better than more cores with lower MHz Concurrency on KSP is still incipient, each craft uses it's own thread so the bigger craft bottlenecks the whole frame, rendering the remaining cores idle for the rest of it. The lowest framerate the gaming is comfortable to you is the best one This is Mono's and Unity's fault. Each frame generates a awful amount of garbage that piles up until the Garbage Collector needs to act. The faster the framerate, more frequently the GC has to act. Welcome to stuttering. My son runs games on a Geforce 9600 or something with 512MB of VRAM on a old Xeon 3070 (a PE 850 I hacked to be a game rig), and that damn thing IS FAST - easily the best machine in the house for gaming, KSP included (as long you don't blow up the VRAM)
×
×
  • Create New...