Lisias

Moved to another thread. @R-T-B, I'm sorry for derailing your thread.

Hey! This is interesting!! Can you publish that exceptions on the TweakScale thread? on a side note, the only thing borking is the UI, still trying to figure it out. But I agree, don't risk your "production" savegames yet. But I will gladly accept KSP.logs with interesting Exceptions so I can diagnose what's happening. I also be grateful for some beta testing.

I completely agree. Maintaining our own code is already hard enough. On the other hand, if people are trying alternative forks instead of the original, perhaps this is a hint that something needs to change? @R-T-B, what follows is what I do, not what you should do (there're no central authority on the matter around here, so we kinda need to figure out rules of co-existance): You need to mark on the github page that it`s a personal fork, and not endorsed by the upstream. Keep the copyright and authorship claims (you can add your own on things you change yourself). This is really the only legal requirement (assuming, of course, the license allows the fork at first place) I like to announce the Add'On status on the log too, to help sort out the chain of responsibility: I'm slowly adding a Startup.cs file on all my projects, like this: using UnityEngine; namespace YOUR_ADDON_NAMESPACE { [KSPAddon(KSPAddon.Startup.Instantly, true)] internal class Startup : MonoBehaviour { private void Start() { Debug.Log("[YourAddonNam] Version x.y.z.b PERSONAL_FORK"); // Change PERSONAL_FORK with your name or something that people will link to you } } } This is an excerpt from my log files to see what I mean: [LOG 07:48:21.352] MainCanvas MASK: 3458764513820540928 [LOG 07:48:21.420] PhysicsGlobals: Loading database [LOG 07:48:21.442] [KSPe] Version 2.1.0.17 /L [LOG 07:48:21.488] [ModuleManager] Version 4.1.0.1 /L Experimental [LOG 07:48:21.489] [KSPe for TweakScale] Version 2.1.0.17 /L [LOG 07:48:21.622] [TweakScale] Log is set to level TRACE. [LOG 07:48:21.623] [TweakScale] Version 2.5.0.7 /L BETA DEBUG [LOG 07:48:21.913] Opt-out preferences successfully retrieved, applied and saved: Don't do SpaceDock or CKAN unless you are really committed into maintaining the thing, and had secured the rights for the name of the Add'On you decided to keep. Really, avoid at all costs impersonating (intently or by mistake) the original author Change all links and text to pinpoint you, your repository and your pages

The "official" clipe, with cuts from the Movie. Technically, there were scenes that would infringe some forum rules. Search on YouTube for "tim capello i still believe", it's the first video on my last search.

Because the license allows, people are in need of the update, the original author can be busy due real life. And when the originals author is able to come back and update the Add'On, he/she will have some heavy lifting already done, and will need to spend less time on it Welcome to the Open Source way. We are here to serve the Users. #tronFeelings

That's what I got to now: I still don't now what's the problem, but I know what's not. I switched .NET framework versions (from the 3.5 to every 4.x the VS allowed me). No dice. I poked around the API, and added every possible option on KSPField to see if it would be something left uninitialised on the constructor.. - [KSPField(isPersistant = false, guiActiveEditor = true, guiName = "Scale")] + [KSPField(isPersistant = false, guiActiveEditor = true, guiName = "Scale", advancedTweakable = false, category = "TS", groupDisplayName = "TS", groupName = "TS", groupStartCollapsed = false, guiActiveUnfocused = false, unfocusedRange = 1)] Nope. The new options works, of course, but the widget is still kaput. But the button works (the "Debug" thing). Fooling around with the problem, I confirm the report from @AccidentalDisassembly: You know what? This stunt appears to be an initialization error. Something is missing when the PartModule is being instantiated, or perhaps is being done before or after ir should. The thing appears to being drawn before the code that configure the Look&Fell gets the chance to do its work, or perhaps the code is borking because it needs something to be happening, and this thing is not. Well, there`s no easy way out of this. I need to do my housekeeping for once. But for today, that's it - I`m awake for too much time already, I need to rest in order to do some productive, something that I'm not able for some hours already! At least, all of this is grunt work, one don't need to exercise his intellect (or the lack of) in order to do it, so it's not a waste of time. I will not waste good productive hours tomorrow with grunt work, this was already done. TL;DR : it appears to be something on TweakScale, indeed. And this can explain some weird issues I got to known with some Add'Ons, including on my gaming. Well… Good night. This is not the "So what song is stuck in your head today?" thread, but...

That's the catch! Someone buys me a beer, it's ok. Someone sends me money so I buy the beer myself, configures revenue around here. And being struck by a copyright infringement (with or without merit) while getting revenue is near suicidal here, because it's exactly what configures a criminal offense, instead of a civil misdemeanor (I'm not sure if I used correctly the words - there're so many different offenses around here, not all of them having a direct relation to USA's laws). A lawyer for civil matters costs me something as 100USD for starters, and I can make a deal with the guy to share the damages on the aftermath. In fact, the last stand-up guy I had to sue cost me nothing, but I gave 40% of the earnings to the lawyer - half for her, half for the judicial costs. had I loose, both parts would end with empty hands and some processual costs. A lawyer for criminal matters starts on 1000USD. And paid in advance, the guy will charge me everything in advance - unless I manage to get someone willing to do pro bono on me. Too much at stake for a beer.

Serenity is the last Expansion to be loaded before the Main Menu Scene. So what happend is that something got stuck and prevented the Main Menu to start up . Check the logs and the output_log.txt for any exceptions.

I choose to move the convesation from the TweakScale to avoid derailing it with not exactly unrelated , but with huge potential to trigger a off-topic fest. From this post from TweakScale's Thread: Welcome. And thanks, dude. However, I still have some Legal Mambo Jambo work to do. Copyright laws here are somewhat different from USA's - and things can go down through the tubes pretty fast when money is involved. Our laws here have some resemblance with UK's on some aspects, i.e., the claimer can use the State to file a criminal complain on some situations and this makes things hairy for me. I don't want to scare anyone, besides ending up doing that - but I need to secure things to avoid risking what happened to "Octav1us Kitten" on YouTube. Accepting money for this can open this door around here - but granted, I don't know the legislation enough to be absolutely sure. Loopholes does exist. But yet, I choose to play safe on this. Again, thanks, dude. You are appreciated.

This is a patching problem. And once one of these is triggered, there's no way to know what should be dissbled or not. The simple cases are handled by TweakScale already - you will note a TweakScaleRogueDuplicate when loading crafts and savegames 'infected' that were created on a sick installment. But there are a huge amount of different ways to bork an installment, and it's a fool's errand to try to detect each one of them in order to code a workaround. The simple ones are already coded. However, there's only a very few ways to do things right. So it's way easier (not to mention feasible) to just scream when something weird is detected. It's what TweakScale does now. Damn. Perhaps a new glitch on different environments? I'm running on MacOS and did that stunt to use Windows libraries to compile against, as this is what works on Unity 5 and 2017. Thanks for the heads-up!

TweakScale is also borking on KSP 1.8. But I'm unsure if it's KSP or Unity's fault - the only thing going kaput is the KSPField thingy, all the rest appears to work - you can even import a scaled craft from previous KSP and it works. S.a.v.e. is also working fine on the spot, not even a recompile is needed. I'm still researching the matter, I'll update you guys as soon as I realize what's really happening.

This incredibly useful Add'On is working fine on KSP 1.8. The basic functionalities (backup everything, restore a savegame), at least, are flawless at the moment.

That's the thing: I ran out of time before figuring out what's preventing TweakScale's UI to work. I managed to add the References to the new DLLs (as a lot of things changed on Unity 2019) and managed to build a binary - but no dice, the problem persists. It's interesting to note that the TweakScale's DLL was being loaded and executed (it executed the Sanity Checks, right?). Frankly, it is not that what is borking TweakScale's on the UI. there's something else. Perhaps an error on TweakScale itself (I was hinted about a mistake on the PartModule's event handling, but RL and some support ended up preventing me from tacking it up - and that thing was not bitting too much.. until now). The aftermath is that I choose to lock the current TweakScale from running on Unity 2019 for now. The weekend is coming, a lot of people is going to install KSP 1.8 and I don't want be the one breaking their games. I will try to negotiate with RL (aka, boss) some spare time to pursue this problem today, but work comes first - so I can't promise I will have a solution in time for the weekend party time. — EDIT : S.A.V.E. appears to work fine on KSP 1.8! Tested the basic functions, and no apparent flaw. Well…. ANNOUNCE. 2.4.3.8 (Lisias) for 1.4.1 <= KSP < 1.8 Lisias released this 26 minutes ago · 0 commits to master since this release This Release locks TweakScale to run only on KSP versions greater or equal 1.4.1 and less than 1.8 . Updated KSPe Light for TweakScale: Checking against incompatible Unity Versions And this thing worked fine on Unity 2019.2 ! Closing or reworking the following issues: #79 Prevent TweakScale from running on Incompatible Unity versions Warning This release breaks the TweakScale's long tradition of being compatible with multiple KSP versions. This release will work only for KSP releases before 1.8. This is not critical or mandatory if you are not planning to migrate your savegames to KSP 1.8, but newer installations should download this version and I need to prevent TweakScale from running on Unity 2019 for now. KSP 1.8 compatibility is already Work In Progress - but it will give me a bit more work than I though. This appears to be a bug on TweakScale, not a breakage on KSP or Unity. Yeah, I'm bitting my tongue. KSP 1.8 compatibility is already Work In Progress - but it will give me a bit more work than I though. It was confirmed that it's a bug on KSP on a very base feature used on UI, and some Add'Ons (TweakScale included) was relying on it. It's uncertain at this point if the best line of action if to wait for KSP 1.8.1 or just rework the UI. (I made a mistake by thinking I had made a mistake!! )

Welll… "This is Halloween, this is halloween!" I just coded yet another Scaring Message for TweakScale today. This thing is still in beta, the code that pick the correct KSP versions for the Add'On is still work in progress, but it carry on the task as is. I'm releasing a BETA version of TweakScale for KSP 1.8 in the next hours. [Nope, run outa time. Sorry] (and yeah, typos. They will be fixed on the PRE-RELEASE. )

IT WORKS! Thanks, @SQUAD - this is one (vanity, I admit) feature I really enjoyed!

I think it will be same as the animated propellers on Firespitter: you register more than one mesh, and then switch them on runtime.

That's something I'm trying to work on.

There's a place where older versions of the API can be found? Unfortunately I lost more than some crafts on the beginning of the year on a stupid and tragic "delete the wrong backup" stunt.

You had asked for a 1.3.1 working version of the thing. Well, it came in time to be overshadowed by a new release working on KSP 1.8, what I have to cook on the weekend! =D

To tell you the true, it's more os less the same impact. 1.3 to 1.4 switched Unity5 with Unity 2017, and Unity changed very used things on the API - as Texture Loading. KSPe managed to solve that by abstracting that API changes and dynamically calling the correct one by reflection. If you are on Unit5, "invoke this way", if you are on 2017 (and now 2019), "invoke this other way". It's simple at the end, the hard part is realizing the problem at first place. This new change must had some API changes as well, but perhaps a bit less dramatic. The ones I use most apparently didn't changed, so the code "survived". The current breakage is due a DLL reorganization on Unity's internals - what appears to be something similar to what they did on Mac OS version of the DLLs (see above). A DLL is just a indexed list of code structures on a file (at the very beginning, all we had was the index of the call - nowadays, the DLL has also metadata with the call's name and formal parameters - before that, we had to provide a HEADER file with that information too, so now we can link by name, what can allow some stunts by manipulating the DLLs on the deployment!), and the linking is done on loading time (not compile time) so you don't really need to recompile everything just because a new DLL came - unless they had changed the formal parameters of some of the used calls, or they had moved them out of the damn DLL. See the stunt about Mac's DLLs. They probably have something else that is not there on Windows and Linux, and once you compile against them, your code doesn't cope with the latter's DLLs due that missing thing. But once you compile on the latter, you can link them against the former's DLL because your code would not be trying to link that extra calls (inside the DLL, God Knows what happens!). Well… I will issue TweakScale 2.4.3.8 until the end of the day, with a dedicated compile to 1.8 so you guys can play. But I'm aiming to try to make again an "Universal" binary as fast as I can. By smartly manipulating the DLL search path, perhaps it would be possible to "fake" an Unity 2017 interface for old Add'Ons so they can run on 2019 without even a recompile? That would be epic!

One very interesting thing that had bitten me hard in the SAS when I first published something I did was exactly these libraries stunt. Believe or not, if I compile my DLLs using the Mac's Unity libraries, the damn thing only works on Mac. Windows and Linux bork. If I compile the DLLs against the Windows libraries, everybody runs happy. Go figure it out. Well, I was victim of my own naiveness. I focused on the API changes and plain forgot this DLL stunt. Oh well - KSPe was Unity 2019 ready after all. If you plan to publish different binaries to each KSP version, yep. This is probably the wiser move as you will have access to the new CIL opcodes, better compiler optimisations et all. But, if you are willing to compromise by reusing the same binaries on less demanding Add'Ons (and TweakScale is very undemanding, it's essentially basic math running on a trigger using some very clever data structures!), sticking on 3.5 will make your deploying easier - if you manage to overcome that DLL linking problem. (What must be possible, see the Mac vs the World DLL stunt!)

Unfortunately, somewhat accurate too. The Good News is that apparently I managed to keep KSPe (a bag of tricks I intend to use as a KSP abstraction layer and service provider for my Add'Ons) working on Unity 2019 - what's not exactly a surprise, as I could inspect the Unity's and .NET APIs in advance to see any problems. So, yeah. TweakScale is still whinny. And yes, this is TweakScale 2.4.3.7 , released on the last weekend. The interesting news is that Crafts you made on previous KSP versions appears to be scaling correctly when loading on KSP 1.8. Mass, fuel, etc, are still scaled after loading them on KSP 1.8. And the damn thing is working: And KSP 1.8 is apparently performing way better on my Mac Potato (and this thing is terrible!). So, yeah. I kinda of happy - besides what follows: The bad news is that the UI is kaput. You just can't edit any tweakscaled part on KSP 1.8, you must do the work on the KSP 1.7.3 and import the craft. I will tell you something: the UI breakage got me with my pants down. I was fearing some change on KSP guts due Unity 2019 changes, but that apparently is working fine. But I didn't expected borking on something simple as a UI widget. I will try to find time to check this before the weekend, but, frankly, don't hold your breath. We are on a very frantic rhythm on my work (black Friday is coming!), so I can't promise I will spend some time on it on the workdays. — — POST EDIT — — Apparently is something simple to fix, just add a dependency to the project and recompile. Or, perhaps I can cook some stunt that will make thins easier… Note to myself (it's way past the sleeping time here) <Reference Include="UnityEngine.CoreModule"> <HintPath>..\..\..\Managed\UnityEngine.CoreModule.dll</HintPath> </Reference>

No, I didn't had any inside information - I just "knew" KSP 1.8 would be launched this week - call it a premonition or plain lucky shot, but I just knew it was imminent. Not by coincidence, I managed today to grab a better machine for me to complement my development needs, and of course, this will make things easier for KSP development too. The new machine will handle KSP somewhat better too - but I'm keeping the older machine around (I think I will end needing both), so I will test things on it too, and be able to respond on issues on highly restrained environments - that are still a lot of people out there. In a way or another, the download just finished. I'm firing up tests now, anything weird I will report here ASAP.

I had some problems with javascript based apps in the past - Atom included. I'm a "heavy user" due my profession, my easiness on handling logs around here came directly by the fact that I'm doing that for years, from critical mission applications to servers that must be running 24/7 and any fix should be done with them "alive". Not for the faint of heart. I munch 100 or 200 megabytes sized reports on the break-fast - and when something goes wrong, more than once I had to load the entire freaking report on a decent editor for visual inspection ("why in hell my REGEX failed on that log entry?'"). Well, I kinda locked using Eclipse most of the time due that - big, enormous log files are something that this beast still handles fine. Remarlkable is a Python application, what's ends being a plus for me, as a large portion of my infra and high level applications rely on Python. - Old dog, new tricks. You got it.

I was absolutely sure the @Exaxis entry would be selected 5 seconds after seeing it. I could not foresee any other one, because most of them were all absolutely fantastics - and I'm pretty happy I'm not the one that had to rule them out. But that one from the Exaxis, that one I just knew it would be one of them! Congrats, dude!