Jump to content

Lisias

Members
  • Posts

    6,457
  • Joined

  • Last visited

Everything posted by Lisias

  1. Looks like some 3rd party borking on you. Please send me your KSP.log after reproducing the problem (and quitting KSP to prevent it from truncating the log) and I will try to figure out what's happening.
  2. Send me your KSP.log. I have a hunch about what it can be, but I want to be sure analyzing your log first. Additionally, what are these parts? I recognized the Mk1-3 and the Hitchhiker Storage , but I don't know the two between them.
  3. The interesting thing on this video is that while designing my own crafts, I got exactly the same problems and ended up exactly with the same results. For example, when using flaps, I usually trim the elevators slightly down to compensate the tendency to have the nose up. Watching these videos can help you to make better planes on KSP! (and vice versa!) Besides that, this is an incredibly detailed tutorial on how to turn up these old beats of the past!!
  4. What I do is to have a copy of the "managed" subdirectory inside KSP somewhere (in Windows, you will find them on KSP_Data - check this for more information: https://wiki.kerbalspaceprogram.com/wiki/Root_directory ) into a fixed directory called "LIB" on my KSP development workspace: lisias@macmini62 ~/Workspaces/KSP/LIB/managed > ls -l total 0 dr-xr-xr-x 14 lisias staff 448 Jul 25 2018 0.07.3 dr-xr-xr-x 14 lisias staff 448 Jul 25 2018 0.08.5 dr-xr-xr-x 14 lisias staff 448 Jul 25 2018 0.09 dr-xr-xr-x 16 lisias staff 512 Jul 25 2018 0.10.1 dr-xr-xr-x 16 lisias staff 512 Jul 25 2018 0.11.1 dr-xr-xr-x 24 lisias staff 768 Jul 25 2018 0.12 dr-xr-xr-x 14 lisias staff 448 Jul 25 2018 0.13.3 dr-xr-xr-x 20 lisias staff 640 Jul 24 2018 0.22 dr-xr-xr-x 20 lisias staff 640 Jul 24 2018 0.23 dr-xr-xr-x 20 lisias staff 640 Jul 24 2018 0.23.5 dr-xr-xr-x 20 lisias staff 640 Jul 24 2018 0.24 dr-xr-xr-x 20 lisias staff 640 Jul 24 2018 0.24.1 dr-xr-xr-x 20 lisias staff 640 Jul 24 2018 0.24.2 dr-xr-xr-x 22 lisias staff 704 Jul 24 2018 0.25 dr-xr-xr-x 22 lisias staff 704 Jul 24 2018 0.90 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.0.0 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.0.1 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.0.2 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.0.3 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.0.4 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.0.5 dr-xr-xr-x 29 lisias staff 928 Jul 24 2018 1.1.0 dr-xr-xr-x 29 lisias staff 928 Jul 24 2018 1.1.1 dr-xr-xr-x 29 lisias staff 928 Jul 24 2018 1.1.2 dr-xr-xr-x 29 lisias staff 928 Jun 9 2019 1.1.3 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.10.0 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.10.1 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.11.0 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.11.1 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.11.2 dr-xr-xr-x 92 lisias staff 2944 Aug 16 2021 1.12.0 dr-xr-xr-x 92 lisias staff 2944 Aug 16 2021 1.12.1 dr-xr-xr-x 92 lisias staff 2944 Aug 4 2021 1.12.2 dr-xr-xr-x 92 lisias staff 2944 Dec 14 2021 1.12.3 dr-xr-xr-x 92 lisias staff 2944 Nov 3 2022 1.12.4 drwxr-xr-x 91 lisias staff 2912 Jan 12 2023 1.12.5 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.2.0 dr-xr-xr-x 24 lisias staff 768 Jul 24 2018 1.2.1 dr-xr-xr-x 24 lisias staff 768 Jun 9 2019 1.2.2 dr-xr-xr-x 22 lisias staff 704 Jul 24 2018 1.3.0 dr-xr-xr-x 22 lisias staff 704 Jun 9 2019 1.3.1 dr-xr-xr-x 31 lisias staff 992 Jul 24 2018 1.4.0 dr-xr-xr-x 31 lisias staff 992 Jun 9 2019 1.4.1 dr-xr-xr-x 31 lisias staff 992 Jul 24 2018 1.4.2 dr-xr-xr-x 31 lisias staff 992 Jun 9 2019 1.4.3 dr-xr-xr-x 30 lisias staff 960 Jul 24 2018 1.4.4 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.4.5 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.5.0 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.5.1 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.6.0 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.6.1 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.7.0 dr-xr-xr-x 30 lisias staff 960 Jun 9 2019 1.7.1 dr-xr-xr-x 30 lisias staff 960 Jun 13 2019 1.7.2 dr-xr-xr-x 30 lisias staff 960 Jul 14 2019 1.7.3 dr-xr-xr-x 152 lisias staff 4864 Oct 17 2019 1.8.0 dr-xr-xr-x 152 lisias staff 4864 Oct 29 2019 1.8.1 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.9.0 dr-xr-xr-x 152 lisias staff 4864 Aug 16 2021 1.9.1 Yes, I have a "collection" of "managed" from every published KSP ever. Always use the Windows KSP's DLLs, even if developing on MacOS or Linux. By some reason I never bored to understand, compiling using the MacOS DLLs will lock your binaries to be run only on MacOS. Compiling using the Windows DLLs will allow your DLL to run anywhere (including Linux). Never bored to check the Linux DLLs. In time, a DLL for C# is nothing more than glorified ZIP files The name of the DLL doesn't necessarily matches the Assembly inside it - you can have even more than on Assembly inside a DLL, exactly as you can have more than one file inside a ZIP. Then I just configure the project file to pinpoint the want I want to use. Please note that Unity 2019 radically changed how the Assemblies is distributed on. Projects intending to be run only from Unity 2019 should use the new ways, but - and this is a really dirty trick - if you use the Unity 2017 schema, it will work on 2019 too! Honest! Anyway, this is how my Unity5/Unity 2017 looks like on the Project's XML file (this file has a ".csproj" file extension - never edit your vsproj directly, unless you know what you are doing and have it under GIT so you can rollback): <ItemGroup> <Reference Include="System" /> <Reference Include="UnityEngine"> <HintPath>..\..\..\..\..\..\LIB\managed\1.4.4\UnityEngine.dll</HintPath> <Private>False</Private> </Reference> <Reference Include="Assembly-CSharp"> <HintPath>..\..\..\..\..\..\LIB\managed\1.4.4\Assembly-CSharp.dll</HintPath> <Private>False</Private> </Reference> </ItemGroup> And this is the equivalent project intended to be used only on Unity 2019: <ItemGroup> <Reference Include="System" /> <Reference Include="Assembly-CSharp"> <HintPath>..\..\..\..\..\..\LIB\managed\1.8.0\Assembly-CSharp.dll</HintPath> <Private>False</Private> </Reference> <Reference Include="UnityEngine"> <HintPath>..\..\..\..\..\..\LIB\managed\1.8.0\UnityEngine.dll</HintPath> <Private>False</Private> </Reference> <Reference Include="UnityEngine.CoreModule"> <HintPath>..\..\..\..\..\..\LIB\managed\1.8.0\UnityEngine.CoreModule.dll</HintPath> <Private>False</Private> </Reference> </ItemGroup> You will need to add more References depending from what you are willing to use (IMGUI, Audio, ImageConversion, etc). Obviously, things will be slightly different in your rig. For learn more: https://learn.microsoft.com/en-us/visualstudio/ide/how-to-add-or-remove-references-by-using-the-reference-manager?view=vs-2022 Now, you need to be aware of the C# Runtime version you need: for Unity 2019, it's 4.6 . Anything older needs C# 3.5 . Compiling things using 3.5 and Unity 2017 will make things work fine on anything from KSP 1.4 to KSP 1.12 (with very few exceptions). You will not be able to run safely something compiled for a new KSP into an older one, but most of the time you can use something compiled against an older KSP into a new (except when you try to use something only available on the newer KSP, or you are relying on a bug or idiosyncrasy from an specific KSP). Some could argue that you should compile your DLLs against KSP 1.12.5 only - and this dude would not be wrong. However, I know lots of people using KSP 1.10 or even 1.9 due the insurmountable amount of new bugs on the newer versions (my long missions are still on KSP 1.7.3!), so in the long run you will need to check your audience. For starters, use the KSP you are playing the most, as you will be your first beta tester anyway. From an Old School dude that did a lot of support including for fellow Add'On authors, stick with Visual Studio 2019 and Unity 2019 for while. KSP, in its now large lifespan, used the following Unity Versions: Unity 3.4, Mono 3.0 - from the beginning of times until KSP 0.18.2 (AFAIK) Unity 4, Mono 3.0 - from KSP 0.18.3 to 1.0.5 Unity 5, Mono 3.0 - from KSP 1.1 to 1.3.1 Unit 5.4.0p4 from KSP 1.2.0 Unit 2017, Mono 3.5 - from KSP 1.4 to 1.7.3 2017.1.3p1 on all of them Unity 2019, Mono 4.6 - from KSP 1.8.0 to the 1.12.5 (current latest) 2019.2.2f1 until 1.11.2 2019.4.18f1 from 1.12.0 You should not use a newer Unity/Mono on any KSP than use older ones - besides being able to walk away by trying an older one on a newer KSP (in about 80% of the time since 1.3.1). So, TL;DR: forget about anything newer then Unity 2019.4.18f1 and Mono 4.6 (for KSP 1.12.0 and newer). You are looking for trouble by doing that (see disclaimer below for an exception). If you are targeting KSP 1.12, you MUST use Unity 2019.4.18f1 . Anything newer and you are prone to have weird misbehaviours on the wild that are pretty cumbersome to cope. The worst part of the ordeal is that things will appear to work sometimes - but now and then something will misbehave weirdly in a way that it's very, very difficult to diagnose. The rule of thumb is that Microsoft (neither anyone else) test newer things on older code, only new code over older things - so no one ever did a quality assurance test on something compiled on Mono 4.6 running on a 3.5 runtime - we did tests on things compiled on Mono 3.5 on a new 4.6 runtime, however - because this is what we would get in the wild. A fellow author I know updated the Visual Studio to 2022 some time ago, and suddenly a lot of their projects ceased to generate the DLLs correctly - since I don't use 2022, I can't say what happened, but reverting back to 2019 solved the problem for them. Your mileage may vary, but the rule of thumb is to use whatever Unity says to use when compiling things on Unity 2019.4 unless you are savvy enough to build and maintain you own development environment as I do (I can generate DLLs to any KSP from 1.1 to 1.12.5, but I had custom built my environment - it's not hard, but you need to know your tools intimately). If you are willing to use the latest tools, it's best to target KSP2 instead - otherwise you are going to waste precious time figuring out esoteric error messages by trying to use new tools into old environments. --- -- - Handling Mono versions is a PAIN IN THE SAS. It's the reason I recomending sticking with Visual Studio 2019 for while. Some time ago, when I replaced my rig, I was getting trouble on finding the Mono 4.6.57 (the exact one used by Unity 2019). Looking around, I settled with 4.7.2 after carefully comparing the change logs and being sure that the main components used by Unity didn't changed inside the framework in a breaking way (compiler mainly , as everything else comes from Unity). On my projects you will see me targeting Mono v4.7.2 because of that. Now? Not even 4.7.2 is available anymore - and I need to hunt for a replacement again. https://download.mono-project.com/archive/ So, since you are still a begginer, really - forget Visual Studio 2022. Get Unity 2019.4.18f1 and use exactly what Unity says to use with this version at the time it was published. On the KSP 1.4 times, I was using MonoDevelop and that damned thing used to work just fine. But then Microsoft took ver it, used it as Visual Studio for Mac and the original project was literally ditched. So I had to scramble to keep my Unit 5/2017 projects alive (and it's the reason I have such knowledge). Now Microsoft is ditching Visual Studio for Mac at all, and hanging me to dry. This is the Microsoft Way. Don't fall for it. For KSP development, the less friction path is sticking with Visual Studio 2019 and whatever Unity says to use on U2019. We are developing for a deprecated enviroment, trying to teach new tricks to this old dog will not going to happen swiflty.
  5. AFAIK, FlightRadar shows when a Flight squawks the transponder, including the emergency ones. You can filter by Squawk (so you can see if there's any 7500 in the World), but only on the paid plan. Something that may worth it eventually - some relatives fly to the West Asia now and then and, boy... Things there kept me awaken all the night for 2 years already they they travel. I didn't. FlightRadar redirected me to this flight when I searched for Flight QR899!
  6. That's the problem - we need trolls, believe or not. People need to be exposed to these claims and learn how to tell good from bad as soon as possible - otherwise we would have yet more gullible people. And all these people do vote. These are the real problem. Because to raise about these ones, people need not only to learn how not to be gullible, but also how not to be stupid. Stupid people have this worship to titles and authority, and this makes them a marvelous target for ill intended people with ill learnt pseudo-knowledge. --- -- - Now, from a personal perspective - -- --- There's a 3rd kind - the professional liars. These guys pretend to be trolls or elitists in order to convince people enough to do or believe whatever will benefit them, disregarding any consequences that don't affect them. These ones are the ones trying to look reasonable when compared with trolls and elitists at the same time doing exactly the same - while falsely accusing anyone that disagrees with them from being trolls and elitists themselves. One could think that by eliminating trolls and elitists we would had a better World - what's a mistake. Without trolls and elitists, we would not be exposed to the tactics employed by these sociopaths, making them harder to detect.
  7. I think you need to update your project's references. Unity 2019 changed how things are deployed - before that, lots of things were being packaged on a single Assembly. From 2019 they had granularized the packages a lot. Make sure you are referencing at least UnityEngine.CoreModule but also UnityEngine.ImageConversionModule. It's a bit weird, but the CoreModule "kinda knows" about where everything are, including the things it doesn't have itself. I think that Visual Studio hints you about the need to reference needed Modules somewhere in the log system. Try this link - but I can't help on SelectImage, I didn't knew about this one until you mentioned it. Google tells me it may be something related to Unity's AR? Are you using the IMGUI? This thing is kinda weird - you need to "draw" your widgets inside a callback called OnGUI . This thing is called on every frame so, yeah, you need to be careful about what you put on that callback. It's better to precompute everything you will need on OnGUI outside it, perhaps on OnStart or some other callback, and then use such precomputed info on OnGUI to save CPU cycles - not to mention avoiding screwing up with the Garbage Collector (that it's already screwed up by itself, it doesn't need help on that!)
  8. At this time, I don't think this is still relevant but in the future you can FlightRadar! https://www.flightradar24.com/QTR51L/34519ac7
  9. Nah, it's easy once you get the grasp. The hard part is exactly getting the grasp on it by the first time (and not committing embarrassing mistakes as time goes by, believe-me on this one!! ) In time, there's this classic thread, somewhat in disuse nowadays but there're good info there: (and it usually pays to have a single point to ask random questions, because I'm following this thread and will get notified if anyone posts on it - instead of relying on random luck as it happened now!) Cheers!
  10. Follow two hints to try to find the assemblies: Go to https://www.kerbalspaceprogram.com/ksp/api/index.html and do a search\ Ditto for https://docs.unity3d.com/ScriptReference/ Go to and do a search for "ksp" and the thingy you are looking for. like this https://github.com/search?q=ksp EncodeToPNG&type=repositories Try KSP API first and github by last, as the later will return a ton of noise, and it's less convenient to sort them out. Unfortunately, we are out of luck as KSP API doesn't have anything named "ExportToPNG". But we got extremely lucky, as the very first responses from github pinpoints solves our question. I choose to check TextureReplacer just because... well, it handles images! https://github.com/ducakar/TextureReplacer/blob/6497420a254dfd967cd3ea1be922dceaa28c7dc4/TextureReplacer/Util.cs#L173 We found that EncodeToPNG is a method from a thingy called targetTex: byte[] data = targetTex.EncodeToPNG(); And that targetTex is an object from the class Texture2D : var targetTex = new Texture2D(texture.width, texture.height, TextureFormat.RGBA32, false); Well, we know that Texture2D is an Unity's class, from UnityEngine . So why it doesn't shows on the Unity's doc search? Well, let's dig a bit. Let's check the issues : https://github.com/search?q=ksp+EncodeToPNG&type=issues aaand... It's an old, deprecated call from before KSP 1.4 times, i.e., it's something from Unity 5 time. Unity's site allows us to look for previous versions on a widget on the top left of the page, and from there we found this: https://docs.unity3d.com/560/Documentation/ScriptReference/Texture2D.html (and EncodeToPNG is there!!). Oukey, we are screwed then, right? Not exactly. We can reach google with the new information we have now: https://www.google.com/search?q=unity+EncodeToPNG+is+not+found&newwindow=1&sca_esv=1895c9f6073d5159&sca_upv=1&sxsrf=ACQVn095SnMyMWlUCtrEzjUEM_VTe8AUog%3A1710084211954&ei=c9DtZZzbOZna1sQP24-WgA4&ved=0ahUKEwjc4PSPgOqEAxUZrZUCHduHBeAQ4dUDCBA&uact=5&oq=unity+EncodeToPNG+is+not+found&gs_lp=Egxnd3Mtd2l6LXNlcnAiHnVuaXR5IEVuY29kZVRvUE5HIGlzIG5vdCBmb3VuZDIFECEYoAEyBRAhGKABSMoSUMsGWJkNcAJ4AZABAJgBjgKgAfgUqgEEMi0xMrgBA8gBAPgBAZgCDqACshXCAgoQABhHGNYEGLADwgIHECEYChigAZgDAIgGAZAGBJIHBjIuMC4xMqAHtSY&sclient=gws-wiz-serp And I found this: https://docs.unity3d.com/ScriptReference/ImageConversion.EncodeToPNG.html EncodeToPNG is on the helper ImageConversion nowadays. Why it didn't show up the first time I tried on Unity's site? Don't have a clue... Anyway, replace byte[] x = texVariable.EncodeToPNG() with byte[] x = ImageConversion.EncodeToPNG(texVariable) and this should do the trick. I expect the other methods to be similar. --- -- - POST EDIT - -- --- Usually doing a search on Forum's help, but not always. At least for ExportToPNG now we have a result on this search! https://forum.kerbalspaceprogram.com/search/?q=ExportToPNG&quick=1 --- -- - POST² EDIT - -- --- Telling you there's two hints and giving you three is a pun - mistakes happens all the time, sometimes on purpose!!
  11. I just nuked a working KSP 1.12.5 by accident while wiping out a damaged beyound salvage KSP 1.9.1 test bed. (sigh) Not exactly an auspicious way to start your day.
  12. At least you don't have to program the damned slides. Sometimes, dude, I have this urge to quit this software business and try to make a living selling sandwiches on the beach or something.
  13. I couldn't agree more. The best thing I ever bought for PC gaming was the Deck - I have a full Thrustmaster TCA Officer Pack Airbus (with additional thrust quadrant - 4 engines) gathering dust in my desk since I had bought the Deck, as I can play that thing anywhere (including on places I will never confess!! ) And I'm playing mainly indie games and 10+ years old games. Carl Barks. The best storyman and cartoonist Disney ever had. --- -- - On a side note, I had am absolutely hellish week. Can't disclose much, but this one I can: I had wrote a small distributed monitoring tool to, well, monitor our machines and send consolidated data and events to our APM (our whole pool of computers works as one single application after all). Well, that damned thing insisted on barking on faults on client's that were configured to be monitored only 5x8 (only a couple clients are monitored 7x24 - most of our clients operate on working hours only). Man, that's annoying: awaking at early hours of a Saturday due a rogue alarm. Damn (more appropriate expletives not allowed on Forum). So, by the second time this year, I got liquided and tried to fix the damned tool. Reviewed the event code, reviewed the fault detecting code, rewrote part of that code, tested it by hand, wrote unit tests for it, did integration tests, simulated faults on an working regime where the current hour would suppress the alarm, did another simulation where the alarm would be triggered. Great. This time I must had tackled it down, right? Deployed the damned thing. And another client's alarm goes off besides out of the intended working regime. I can't express my displeasure about the event (really, I can't - I would violate half the Forum rules, and some Laws too). I reviewed everything. AGAIN. And, again, everything appears to work fine on my machine. So I reviewed the code that read the configuration files. They were good. Then I finally got it - configuration files, by Turing's Sake!! I checked the server's configuration files and on it the Saturday was configured as a Working Day... (sigh) For more than an year, the problem was a mistake on the freaking (you know what I really want to write here) configuration files. And this was the smallest of my issues this week!
  14. Not forever. I think I have a way to make the whole process more resilient - but I want to work on it with time to spare to prevent regressions on the field. Everything that involves KSP-Recall is terribly critical, I can ruin a savegame if I don't be careful enough!
  15. Yes, known bug. Created by a 3rd party. Work In Progress (RealLife™ and DayJob© stroke again). https://github.com/net-lisias-ksp/KSP-Recall/issues/73 The problem is that, somehow, the "original" part is not getting its data refreshed by KSP-Recall on the right time and ends up "stuck" with old data - the current work around for the issue is to take a new part from the Menu instead (as new parts don't have old values to linger). OR... Deactivate BetterEditorUndoRedo on KSPCF, that somehow is involved with the problem.
  16. Sometimes I think that some people just have too much free time in their hands... source: https://9gag.com/gag/aVxXYDP
  17. The Reversor is algo pretty interesting:
  18. It helps on it, but the real reason is a thingy called Powered Lift. See the NASA QSRA for reference. The gains are good enough to some military jets used (some still do) it, as the F-104 on landings (acting like flaps). But not that good to be used by most commercial and/or civilian jets.
  19. You know, I really like Russian designs. I concede that not all of them are practical, but I enjoy the attempt nevertheless. You guys need to see what these guys did with computers in the 80s and 90s. Disclaimer:
  20. We have different roles. You are not going to support users of your patches.
  21. Check Tarsier! Cheers! — — POST EDIT — — Humm… I think the Sensor is from Cacteye...
  22. I don't know. It's the reason I want to see the logs, so I can try to reproduce your instalment on my rig and see what's happening.
  23. Makes no sense. Really. Please send me the KSP.log - there's something else there, and I want to see what's happening.
  24. Opposite of perfectionist? More likely an unexperienced and/or too much optimistic instead. People borks. Everywhere. Some do a typo on a part config (even Squad used to do it sometimes), and things start to get (yet more) screwed when scaled - and, so, TweakScale takes the blame. I need to support everything right, not only 80% of the most used parts (while letting the users get screwed with the other 20%). I need to check the bulkhead profile, I need to check the attachment nodes, I need to check for custom PartModules (and I need to check if the there's anything missing on currently supported ones, as scaling some uninitialised attributes can lead to CTDs - and, again, TweakScale takes the blame). And so it goes… So everything I publish is double checked - not only the patches, but the parts I'm patching too. Remember GIGO: Garbage In, Garbage Out. What else did you updated? The only changes on the latest release were some patches for Aircraft parts! I didn't touched anything else. The latest TweakScale was also just a minor bug fix, that were affecting only a small number of users from KSPIE. Additionally, there's no official support (yet) for Fairings on TweakScale (neither stock ones, what I have is still Experimental), so… Are you sure you are barking on the right tree?
×
×
  • Create New...