-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
Using RealPlume by chance? Any exceptions in the log either during start-up, when grabbing the part in the editor, or when launching a craft using the part? (really, no clue what could be causing this one, just gathering some info).
-
Interesting -- must be something new that they've added in stock code; can't say as I've seen that kind of issue in the past. Thanks for opening the issue ticket -- will investigate for the next release. Currently there is no external mod support (at least not that has been kept up-to-date). Yes, I would like to add in patches for the most common LS and QOL/utility mods. So possible -- yes. Available currently, or in the immediate future, no. I think that SSTU has reached a 'stable' state as far as features goes though, so likely will start working on proper mod integration patches and example craft in the near future.
-
@Gordon Dry Yea, the configs and texture setup for this pack was definitely sub-optimal from my opinion. I assumed @vossiewulf had made the layout intentionally the way it was. Thought that I saw duplicated textures in there when I was working through it, but really didn't (and don't) have the time to personally re-work every config/texture pack that uses TU. In your efforts to 'clean up' the configs -- keep in mind that TU really doesn't care where things are stored, or what specific file structure you use, or how things were set up with PartTools. As long as your configs are setup properly with the proper model path and texture path, it will all resolve correctly at runtime. You can reference the same file multiple times. Will be no issues in TU.
-
Indeed, 'playing a modded game' is a bit different when you write your own mods. 95% of the 'issues' with 'using mods' disappear when you create them yourself; you can decide your own balance, and if something is broken, you know exactly who to contact to get it fixed. I use mods. Lots of mods. But I also write mods and am also capable of fixing any issues that pop up in those mods, so the points the OP express mostly don't apply. At the end of the day, its KSP -- play it however you enjoy it
-
Unfortunately, I really couldn't say one way or another. I never stayed up-to-date with the TU-patch sets, so not really sure where they ended up functionality wise. IIRC -- the problem you were encountering was just on a single part (a parachute)? Likely much easier ways to solve that then by switching to a different patch set. If your original set was mostly working but you wanted, probably much easier to fix the specific issues you were encountering (in this case, might just be a single line needing to be changed.... might require a bit more complex solution though).
-
No, it wouldn't slow the consumption at all, it would only increase it. In order to get electricity out of a rotating system, you have to apply drag (in the form of magnetic fields); this drag generates electricity, sure, but it also slows down your spinning. Notably, you'll require more energy to spin-up back to desired RPM than you would get out of the deceleration (edit: due to thermal losses/inefficiency in motors, bearings, and electrical transmission). There is no such thing as free lunch in physics...
-
Understood, and fully appreciated. Its one large bit about TU that I've never been fond of; but also never found any good solutions. There are partial solutions available with the use of the new 'normalized' recoloring setup, so that for some basic recoloring setups all that would need to be provided would be the recoloring mask textures, but even that system has its issues with specific inputs. There might be a system to allow for arbitrary recoloring of any textures, but I certainly haven't found it, seen it, or heard of it anywhere. ----- For a long time now I've really wanted to do a complete TU pack for stock parts. But its so much work, and the source textures aren't that great to begin with. My next hope was to create a pack for Restock (as I love the detail and unified looks), but its assets were released as ARR and so are off limits (and would still be a ton of work, but at least with a good source).
-
TU only works with KSPTextureSwitch. The issue is that in order to support recoloring the textures have to be authored for recoloring from the start. Those parts were not created for recoloring, and thus to get it working, you would have to redo the textures. No other way around it. ^^^ is why there is not a functional (and properly implemented) TU patch/recoloring mod for stock -- nobody wants to redo all those terrible stock textures.
-
Attempted to create a basic fixed-pitch quadcopter, using the fundamental forces for maneuvering as does a real quad (e.g. increase rotor speed for specific rotors to effect specific maneuvers). Now, the issue encountered -- how to have multiple input axis effect the state of a single rotor ? E.G. 'Pitch' control needs to increase front motor torque (1+2), and decrease rear motor torque(3+4) simultaneously 'Roll' control needs to increase left motor torque (1+3) and decrease right motor torque (2+4) additionally 'Yaw' control needs to increase alternating motors to effect yaw (increase motors 1+4, decrease motors 2+3) Individually I can make any one of those controls function properly. If I specify all three of them -- only the last one in the action group list is functional (the last action groups settings take precedence over previous action groups). The question: How can I mix inputs from those three axis channels onto a single motor? All three channels need to be combined in order to determine the output state of the motor.
- 1 reply
-
- 1
-
.... Waiting for someone to make a full collective pitch helo using the new robotic parts. Could someone sequence/construct a swashplate using the servo axis controls? https://en.wikipedia.org/wiki/Swashplate_(aeronautics) Likely that there is a simpler method though for CCPM, considering all of the functions available in KSP with reaction wheels/etc.
-
No worries, fully understand. I've opened an issue ticket myself on the subject so that it doesn't get forgotten about (really, that is why I use GitHub issues -- only way to keep it all sorted) -- https://github.com/shadowmage45/KerbalFoundries2/issues/44 Before I would feel comfortable with publishing those patches -- they would first have to be supported. I bashed those configs together as a personal 'test' mostly to make sure the plugin would work for stock parts. They have received no balance updates or any sort of maintenance since they were initially put together. Which is why I've left them just hanging out in the repo, with no official releases or packages, and the only way to get them is by manual download. I may take you up on the offer in the future though -- there have been multiple requests for fixes for the stock wheels, and I feel kind of bad for having that fix just laying around but going unused. Would need some time to sit down and thoroughly review the configs though, make sure the balance is all where it needs to be and that it all actually works.
-
Are you using the latest version of the mod (the one with TU bundled and new PBR textures)? (doesn't look like it from your screenshots) Likely the issue is already fixed, as I know that I cleaned up the animation issue that you mention in the updated models. I personally don't use the bulkead profiles or in-game search features (likely because I predate both of them; they didn't exist when I learned to play, so I learned how to play without them), so have little motivation to make any changes. However, for the sake of completeness, I have no issue if they were to be added to the parts. Feel free to open up either an issue ticket or PR on the subject (whichever is more appropriate to your Git understanding), and I will certainly investigate for the next update (which will likely be this weekend, or at least in the next week or 2).
-
'Pressure' would be an RO/RSS (RealFuels) game mechanic, and not part of SSTU -- thus I cannot offer any support.
-
Are we still pretending the wheels/legs aren't broken?
Shadowmage replied to Geonovast's topic in KSP1 Discussion
Every time one of these threads pops up I always wonder... Why doesn't someone just patch the stock wheels to use the KSPWheel modules, and never have to deal with these stock wheel-shenanigans again? Then I realize.. oh wait.. someone did. Might even have been me https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches/Stock I know that mods aren't a solution for everything, or for everyone, and aren't even available on consoles. But for this specific case I would not be waiting for SQUAD to fix it (they aren't going to, its a Unity engine problem). -
Indeed -- that situation would make sense to see the error (as I'm not explicitly clearing anything prior to loading; so it would re-use existing populated collections during reload, and likely throw the same exception as seen above). And.... issue opened on that, as it really is something that should be fixed (and not too difficult to fix at that). https://github.com/shadowmage45/TexturesUnlimited/issues/66 Should be able to get that one fixed for the upcoming KSP 1.8 release.
-
I do that from time to time as well (ARK, or others; currently doing a run through a RimWorld colony). Can't be all KSP all the time. To answer your question -- there were pretty much zero substantial changes between 1.6 and 1.7 for SSTU (nor am I planning any for 1.8). Craft files should continue to work for those versions, and into the future as far as planned. Would be much appreciated, if you have the time. Just some basic integration would be good for now, though long-term I do want to develop fully fleshed out model/variant/fuel switching w/endcaps etc. I'll be working some over the next few weeks in prep for the upcoming KSP 1.8 / new DLC, and this would be a perfect opportunity to add either updated patches or some 'official' craft files.
-
That would do it. If TU errors out during loading.... I wouldn't expect anything to work correctly. The cause of that specific error is caused by an incorrect config/patch, which is specifying some duplicate values be added to a collection that does not accept duplicates. Specifically it is happening on this patch definition: [LOG 13:03:05.468] Loading shader icon replacement data for: SSTU/PBR/Masked :: SSTU/MaskedIcon Further reading through your log points towards TU trying to load the following shader pack twice -- Loading Shader Pack: SSTUShaders :: S:/Games/KSP RSS 1.6.1/KSP_x64_Data/../GameData/000_TexturesUnlimited/Shaders/sstushaders-universal.ssf Which means you have some duplicate configs somewhere specifying that shader pack to be loaded a second time (which is the error that will need to be tracked down and corrected). Specifically, you have an extra folder inside the 000_TexturesUnlimited/Shaders folder that needs to be removed: '[LOG 13:03:03.205] Config(KSP_SHADER_BUNDLE) GameData/000_TexturesUnlimited/Shaders/SSTUShaders/' Remove that folder, and if there are no other issues, TU should be able to load. Not sure how/why/where that folder came from? (its not in the distribution?)
-
Almost certainly a mod related issue; something is throwing an exception during part/model loading. You could try posting/uploading/linking to a copy of your KSP.log file. Without knowing which exceptions were being caused, and from what code, all anyone can do is guess at what the actual problem is (all of that is listed in the log file).
-
[1.7] Advanced orbital info tab
Shadowmage replied to Shmauck's topic in KSP1 Gameplay Questions and Tutorials
https://en.wikipedia.org/wiki/Longitude_of_the_ascending_node The origin is defined (for Earth) to be " the First Point of Aries as the origin of longitude " On Kerbin... IDK; probably defined as a line from the sun to Kerbin on a specific in-game date. IIRC the KSP wiki may have more precise information. Really though -- LAN is not a number that a player need normally concern themselves with. Only really needed if you are trying to replicate a set of orbits from orbital parameters. -
Technically yes, but then any surface that is intended to be reflective will instead simply be black, which is not at all the intended look for those surfaces. The only 'correct' way to do reflections with DX9 is to not do them at all (which unfortunately would require completely separate art assets and shaders; which is exactly what older versions of SSTU did, but was far too much overhead for me to maintain long-term).
-
No. DX9 has terrible rendering issues that I cannot solve (no seam fixup on cubemaps, randomly swapped cubemap faces). You -can- use it however (DX9). I haven't blocked the mod from running on DX9. You'll just have the 'incompatible API' warning when you start the game (which you can actually disable in one of the config files...), and of course, anything with reflections will look terrible because of the DX9 issues. Only if they have issues with their hardware/software. If OpenGL isn't working.... you've got other problems that need to be solved (OpenGL has been supported by every major graphics card for the last ~15 years, even the terrible integrated Intel ones). Certainly it is supported on your 1050ti (guaranteed, as that is the card I'm using on my work computer right now, and it runs KSP just fine in OpenGL mode). Again, this would be either a software/driver or hardware issue, and is not support that I can provide. Your OpenGL crashing issue isn't with the mod, its with your computer.
-
Interesting -- that points towards the problem likely being either a memory issue (running out of ram, or writing to a bad block), a storage issue (log file size, error on drive during write operation), or thermal issues and overheating. Normally thermal issues will manifest faster than 5 hours of continuous use, but still a possibility. (of course, computers are insanely complex, and it could be something else entirely... but those are the points I would start on if I had those problems on my personal machine) Thanks for the confirmation. I'll take a look at my settings and see if I can spot what needs to be changed; IIRC it was something regarding fullscreen/bordered/windowed modes, though I don't remember it causing that specific access violation (more it was an error regarding unsupported resolution or something). Apparently this is also part of a 'known issue' with Unity regarding some non-standard graphics adapter settings / multiple adapters. Not sure if that is exactly what is happening in this case, but seems like it is similar in its effect... https://forum.unity.com/threads/unity-2018-2-7f1-windows-standalone-crash-on-first-run-unityplayer-dll-caused-an-access-violation.556585/ Apparently it is also a reported bug on the SQUAD tracker, though I've not much hope of them fixing it for Windows, as OpenGL is only officially supported on Mac and Linux -- https://bugs.kerbalspaceprogram.com/issues/20055 And one really strange solution that I found was modifying the startup command to use double-dashes (from: , such as: C:\Kerbal Space Program\KSP.exe" --force-glcore
-
Understood, and no offense taken. I know how frustrating it can be trying to get some of these odd mod combinations working. I can't count how many hours I've lost restarting KSP, tweaking some settings, restarting again, etc. Hundreds of hours at least. Please let me know if the driver update doesn't resolve the OpenGL issues for you. This will likely be the most compatible graphics API for other mods, as OpenGL is a requirement for Mac and Linux support, and is one of the more stable and reliable APIs from my experience. If the driver update doesn't help change the situation there may be some tweaks that could be done to fix it. (Notably, I do remember there being an issue with OpenGL and KSP's fullscreen mode that would cause an 'access violation' on startup, though I don't offhand remember what I had to do to solve it; IIRC it was something in the windows registry that had to be edited to fix it, as the setting is normally only changable from in-game)
-
So.. other mods having issues with DX11 is somehow my problem? (and BTW, KS3P should work fine with DX11 as long as you grab the newest DX11 compiled shader bundle from the thread; can't say anything about RS*** as I stay the hell away from all things RO/RSS related, nothing but problems) You've likely got some serious driver or hardware issues if something like that is occurring. Likely drivers if it is causing an access-violation. I would start there...