Gaalidas
-
Posts
1,723 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Gaalidas
-
-
So... it's a mod to make my eyes bleed as I strain to see the blurry areas with any clarity. I am impressed. Total bleed time is off the charts, and time to bleed start is incredibly short compared to other eyes-bleeding mods available.
Maybe I'm missing the point... good work though.
-
On 3/3/2020 at 1:46 PM, Shadowmage said:
No doubt C++ is better suited for the implementation of specific functions, or for use in specific performance-critical places; but a general purpose scripting language, it is not.
My only use for it is in the area of C# not being able to return anything to the process that runs it. You'd have to export something to a file and read it from the calling process, like a batch file or something. So, when i try to expand my batch files to use C# methods... I can't provide any success or fail feedback without a bunch of work.
-
Nice. Always enjoyed these parts.
-
28 minutes ago, dtoxic said:
ill do some more tinkering (i want to avoid specifying every single part too much work :D) anyway do let me know what you find!
Not finding a lot of details... reading code and deciphering it are two different skill sets. Stills at it though. It appears that parts do load in with their mod directory logged somewhere.
You might be able to specify a part category, or a part author in your specifications. For instance... some patches I see in the list specify this: "@PART[*]:HAS[#category[Engine]" to specify a certain category. If the parts in that specified set you want to alter all have a shared category, you could use that to specify it. I imagine you could use that to specify other part parameters.
For example: ":HAS[#author[author_value]" or ":HAS[#manufacturer[manufacturer_value]" I imagine one could even specify based on the part tags, but I stopped playing KSP before they added that to the part configs, so i wouldn't know how that all functions with MM.
-
Just now, dtoxic said:
thx for the replay....i actually tried that "@PART[*]:FOR[MarsDirect]".... etc but this way everything gets a rescale factor witch is specified in the patch by my logic the :FOR should be enough but then again i am struggling with MM patches since forever to understand exactly how the syntax in MM works
Gotcha. Yeah, the syntax is a little confusing at first. I'm not gonna say you get used to it quickly either. It's also been several years since my last self-made patch but I don't think it has changed a lot. You might need to specify part names directly instead of using the asterisk. You can also use partial wildcard for the part name. for example "@PART[*cabin*]" to, in this example, grab anything with the word "cabin" somewhere in the middle of the part name.
The trouble with directory filters is that MM doesn't actually run on the files themselves as they are on your drive. It runs on the configurations after they are loaded into KSP. This way none of the original configurations are altered permanently. As a result, it doesn't actually know what specific directory the parts are in. It can, however, detect what mod it came from which is a feature I do not, at this moment, understand how it determines. I do, however, have the source on my drive somewhere which i intend to loo kat after posting this. I'm super curious now as to how that works.
-
3 hours ago, dtoxic said:
does anyone know how one could resize all the parts in a specific directory via MM patch? i cant figure it out
I suppose, if you added a :FOR[Mod_name] to it, you could do a patch to every part in a specific mod. I am unsure if you could specify by directory.
I have theorized that you could add a bogus module to a bunch of parts to specify that they are part of a part group for the purpose of later finding them all, removing the bogus module via a patch, and then doing things to them based on the name of said bogus module. However, taht may be beyond the scope of what you're wanting. I don't beleive you can specify a patch to run only on a specific directory unless you move those parts into a separate top-level mod directory.
It's been a long time since I've done anything in this scene though, so who knows.
-
Either way you go... I wouldn't suggest anyone export into DDS from gimp. There have been a lot of reports, mine as well, of nasty artifacts on some Gump exported DDS images. That's why I export to TGA first, then go to DDS from there. I'd do PNG, but it's quicker to export to TGA and, this ay, my batch files can differentiate between png files that I'm allowing to remain like that, or haven't yet vertically flipped, with those that are ready for conversion. Then I can just iterate thought the entire directory structure.
Anyway, yeah... I'd like to go code-only at some point but it's proving a bit difficult to do at my current knowledge level. Even some of the other tools I've used before were simply calling up an external command line utility to do the actual work. I'm gonna look at that github repo you posted though... very interesting.
Also.. I agree, C++ is ugly. C# is the future... maybe...
-
Or, at the very least, split the camera stuff into a common library for ease of handling cameras in mods. I hope this camera thing hasn't affected the color sampling camera I put into Kerbal Foundries way back in the day... now integrated into KSPWheel.
-
5 hours ago, Shadowmage said:
now I just need to update all of my tools to support BC5 as an export format...)
Dunno what tools you're using or speaking of... but I do a lot of texture modification, daily, and I've developed a few tricks to handling DDS.
First off... if you're using GIMP or another tool with outdated plugins for DDS, I suggest converting any texture you intend to edit into a TGA format first. I found that the GIMP plugin left artifacts on any exported DDS image, and PNG takes a lot longer to export to than TGA in the same image when I timed it.
Then, to handle DX11 texture formats, I had to get creative. There are multiple command line utilities out there for handling texture conversions and I've discovered one that works in about 95% of the cases I run into. I'd called "DirectXTex" or, just "texconv.exe" and it's pretty powerful. Unsure where I got it originally though. I've spent the last few years developing a set of complicated batch files to handle all of my texture formatting and converting needs. Even went as far as you write one to separate the filenames from extracted unity textures for easy editing, and then restitch them together. Helps a lot when you want to update texture IDs for new versions of games without re-editing all the files by hand. I'm a bit of a mad man with batch files... so titled by my old school buddies.
Anyway... if you can find that converter, it can handle just about everything you'd need including a few obscure cases where there isn't a specified format or compression in the file. I've only discovered a few different types that I couldn't use this tool on, and in those cases, the batch-processing utility in Irfan-View did the job (if I could live with the alpha channel disappearing).
I've even handled 8k BC7 textures with relative ease, and those usually don't even import into a DDS handling program except for the higher end ones.
-
3 hours ago, Shadowmage said:
Yeah, that's mostly how my GUI's in KSP have gone as well.
The new 'Unity GUI' system is actually very workable. But only if you can build the game from the editor; it is painful for use by mods. The issue being that all the GUI elements require scripts to function, you can't pack scripts into AssetBundles, and AssetBundles are the only way to get the GUI's out of the UnityEditor and into KSP. So, you pack up all your carefully laid out GUI into an asset-bundle, and then in KSP you need to extract them, and spend a few thousand lines of code to hook up all the scripts and fix all the binding info that was lost during the AssetBundle export/import process.
I wonder if, within Unity, you can get access to the source of the created GUI and, at the very least, be able to copy the script code for the positioning of the elements and such into VS after using the Unity tools to do it. I haven't done anything in Unity itself in years, so I'm unsure what I'm talking about really. Just a thought. I'd bet someone out there has built a good library for translating what you see in a GUI designer into what KSP would understand. You might try asking around on other major GUI-using mod topics for information on how they did it.
In the meantime, I've had some people contacting me (as if I know anything at all... shh! don't tell them the truth)... about various ways around the stock code oddities. So I'm gonna try my hand at redirecting some things around with them. I'll get back to looking at our little problems here later.
By the way, I did some sifting through old posts here and I am absolutely loving what you've done with the models and textures of the mod. Beautiful stuff. The code, for the most part, ain't too bad either. Looks like lo-fi agrees too, and he's a rare visitor indeed.
-
On 2/23/2020 at 9:34 PM, vardicd said:
Maybe you mean this one?
Yup, I'd say that's pretty much spot on. Those were the old glory days of KSP modding.
23 hours ago, Shadowmage said:Yes, a vessel module would be the root handler for interaction/spawning the UI, and persistent storage of grouping data. The individual settings would still reside in the existing sub-modules, simply to keep things 'modular'. Would use a custom attribute system (similar to [KSPField]) or other tagging system to have the vessel module grab references to the fields to be controlled right out of the sub-modules, and then dynamically construct the UI based on the available fields and any persistent data that was available regarding grouping.
The technical aspects of the back-end were never too much of an issue for me, I think I already have a basic controller class in the repository that does most of this; my problem has always been designing a UI that made sense, in KSP. More so the difficulty of creating GUI's in KSP rather than creating a functional design; I could easily create something usable in WPF, Unity-GUI, or any other number of UI systems, none of which are available to KSP.
I've never figured out how to import Unity-GUI's through AssetBundles, or if it is even possible, nor had the time to learn how to construct them through code -- but that is what would really need to happen next. The IMGUI system that I use elsewhere is good for simple debug displays, or a few buttons to click... but if you want tabs, tree-menus, or anything more complicated than a scroll-panel, you need to use the Unity-GUI system (or something entirely custom).
GUI development, for me, has been a love-hate thing. I only managed the old settings GUI in KF by a lot of trial and error. The Unity GUI creator wasn't a thing back then. I had a look at the IR source today and that mod is a pure mess of chaos and damnation. It's a wonder it even compiles at all, much less work. Yet, it does... mostly. So... I'm afraid I'm a dead end in that area.
On another note, I've been going over a lot of mod related code lately and have found some really odd stuff in the KSP DLLs related, especially, to part resources (as in fuel, EC, etc.). For instance... apparently the method of requesting a resource using the resource ID (an integer) and a float (for usage I think) in tagged as obsolete. However, the method which uses the resource ID and a double instead is not obsolete. To make it stop throwing warnings at me, I've had to do some strange stuff such as changing the variable to a double, casting the usage as a double, and then re-casting the result to a float later down the line. I don't get at all why they would tag the method as obsolete in the first place though. Also, apparently the WWW class is obsolete, but there doesn't seem to be any clear way of translating what we would have used for those WWW calls into the new method suggested in the resulting message.
Things made a lot more sense back in v0.23.5.
-
9 hours ago, Shadowmage said:
Certainly possible, and could be enabled as an auto-safety feature. Something simple like "if accelerator is not pressed, and above max safe speed, apply brakes momentarily". Would have to be set on a per-part toggle, through the parts right-click menu.
Will give it some thought, see if there are any as-yet unforeseen issues that pop up. Likely it could be implemented for the next release.
This is an interesting one. A while back (like years ago now I think) there was a mod I used that implemented an anti-lock braking system... sorta. When activated it would pulse the brakes so you could slow down without just slamming down and flipping over. Very useful in low-gravity environments. I also remember that the old KF code had curves to control the amount of acceleration/torque/whatever it is that I don't fully understand, the stuff applied to the wheel at certain speeds.
With these two things in mind, I imagine you could implement a feature like what is described pretty easily while limiting the chances of killing your Kerbals via sudden slamming on the brakes. Whether this is a good or bad thing is up to you.
-
9 hours ago, Shadowmage said:
I did eventually include a 'wheel group' setting that works as you describe, but what I'm looking for in the potential new UI is a few steps beyond that -- allow each feature on a part to be grouped separately. So you can have a group that controls max torque for -all- wheels, a separate group for steering limits on the front wheels only, a group for motor inverts for the left wheels, and another group for motor inverts on the right wheels. I really should try and mock something up, as it would probably make more sense that way...
OH... holy crud... are you mad? Silly question, of course you are. Oh god... I my head hurts just thinking about coding something like that in Unity.
Okay... so thinking out loud, so to speak... In order to make all those settings able to be grouped independently... at the moment I would think they would all have to go from being fields, in the current modules they belong to, to being sub-modules of their own that feed their settings into the parent module. Then, I could imagine, you could set a certain option to be synced between different parts without needing to add a group selector for each individual settings in the context menu.
Then again... you'd still have to have a group selector for each individual setting. That's where a separate UI would come in handy though.
No... my head is hurting again. This could be a challenge. I still think each option being a separate sub-module would be ideal. Otherwise the code for the parent module is goingt o get very long with a group number for each and every field and a ton of utility methods to keep it all straight. Might need a new vessel module to make them all talk to each other between the parts...
You are indeed mad aren't you? Oh god this is bad...
-
10 hours ago, Shadowmage said:
The one thing that could still be really useful to implement would be a per-vessel wheel-controller system, allowing to group together specific functionalities of the wheels on the vessel in a new UI, so the player can both see what all the wheels are doing, and organize/control/adjust them without going to each individual part. Never figured out how to do a good layout for this feature, but it is still something I would like to look into at some point.
If you haven't removed the feature, already we should have a wheel group setting which previously allowed the user to modify a setting on one wheel and have to update to the others in the same group. However, I never figured out a good way to make those settings visible without looking into the context menu for one of the wheels. Also, the settings in question only auto updated when changed via action groups. Manual updating was possible with a context menu button I think. I imagine a copy and modification of the IR configuration GUI might be useful, but that's a bit beyond me at the moment. I haven't done anything with Unity menus since that first config menu I made before my long sabbatical. That thing was clunky as heck.
-
Sup boys. Been thinking about getting into KSP again. Nice to see this old thing is still being worked on.
In fact, I've already re-familiarized myself with the code. Looking good... other than a few cringe worthy moments where I noticed some sub-optimal method naming convention issues. Still, seems to be working rather well. Unfortunately I haven't launched KSP is so long and I'm so out of the loop on the mod scene, I'm having to play catch-up.
-
On 8/17/2017 at 7:12 AM, Shadowmage said:
https://github.com/shadowmage45/KSPWheel/issues/24
Wouldn't be just dust/sounds (those are quite integrated into KSPWheel), but would be a complete overhaul/conversion of the stock parts to use KSPWheel. There is a patch set floating around somewhere that you can try if you want ( https://github.com/shadowmage45/KSPWheel/tree/master/GameDataDisabled/Patches/Stock ), but it hasn't been worked on in awhile, and I'm not sure if it was updated with either sound or dust.
I can confirm that those configs were all about the functionality of the KF wheel system, not necessarily sound or dust related but, back in those days, the KF modules were set to add the dust module to the part, if not found, and sound was part of the KF wheel module itself.
As for the dust itself, technically, the original implementation I made, back in the day, was not based solely on KF. It was a heavily modified CollisionFX module. It was later added to KF and integrated into it when I became a more active member of the development team for KF. A version could be made for the stock wheel system with very little overhauling needed for the module itself. It could even be shipped with KF. However... if couldn't easily be made into the current dust module. It could use the current camera color sampler, but it would be a duplicate module for handling the dust itself due to the differing parameters for the two wheel modules (KSPWheelBase vs. ModuleWheelBase, free-typed without looking at the actual module names.) Making this might be considered a waste of time, however, if shipped with KF. A better option might be to alter the configs for the base wheels to use the KSPWheel module instead which would eliminate the need to use a different dust/sound module.
-
On 8/7/2017 at 8:02 AM, Shadowmage said:
Neither; that is a new and as-of-yet unreported bug. File it on the bug tracker please
(otherwise I'll forget about it and it'll never get fixed)
Goes to show how many people actually use that part, doesn't it? Sad really...
-
The KF thread is still rather active and I'm still working on it in my rare spare time. It's under new management though, so there have been a lot of changes. The sliding, however, is not unique to KF. I've witnessed it with completely stock rockets sliding around after landing vertically on Kerbin.
-
3 hours ago, Tivec said:
A good suggestion but alas, didn't work out. Tried with motor lock on and off, motor strength set to 0, but no luck.
And, I assume, you've attached stock gear to it to be sure it doesn't happen with those?
-
I really didn't see a lot of changes that really needed to be made on the Catapult mod's side to make it work really. They would just need to use a bunch of reflection stuff to maintain compatibility with non-KSPWheel setups. It would take a little testing and manipulating... but it most likely can be overcome.
Anyway... I don't have any time to really dig into it so... that's how it'll be until someone can convince the other party to look into it.
On the topic of the bouncing and spinning... and video does show it off nicely. Some bounce when landing is pretty normal for a plane, but that flip was crazy.
-
I had a look at it and it could be modified to work with KSPWheelBase... but that's not on our end. One things that is on our end is the fact that the ModuleWheelBase "isGrounded" boolean is called "grounded" in KSPWheelBase instead. If that were renamed to "isGrounded" like the stock module, then altering their code to work for either the stock or the new module would be extremely easy I think. I didn't look at al lof the code though, so there's still a chance there would be some conflict somewhere. I just caught the last method in the Catapult class where it looks up all the modules on the parts.
-
4 hours ago, Grease1991 said:
So my guess is that if KSPwheelBase was added to that then it would most likely work. can that be done Via MM patch?
I highly doubt that would fix it really. It's likely locking into a specific transform on the models that are used for stock landing gear and/or modded landing gear under the stock modules. I'd need to dig into the source for the catapult to know for sure.
-
19 hours ago, Shadowmage said:
It really should be doable through a separate submodule (e.g. KSPWheelAutoConfigure), that is added to the parts after the steering module. It can then run its code either when parts are added/removed from the craft, or once on the first startup of the flight scene; all it should need to do is hook into the existing steering module and adjust its high/low steering limits and bias setup (which are all public vars). Should be no need to override existing methods; just hook into the steering module and adjust some of the existing config variables.
I would prefer to not make you do any extra work to make this function... and it really would be better to have this as a separate sub-mod for KF/KSPWheel so I can update it at my own pace and/or add other new features to various modules. Thanks for the tips though... I'm going to continue fiddling around with various ideas and see what I can come up with. I hit these coding-blocks in my brain from time to time that make it hard to see the right path to take... or even see what it is I'm trying to make happen. My biggest block right now is in the way the steering limits are implemented (your high and low limit vs. the old steering ratio that lo-fi used) and which of those limits I should be modifying for the desired effect. I would have thought there would only be one limit, with the other limiting factor being the default position of the wheel when not steering any which way. I need to dig into the part configs a bit to see what you've set them all to, as well. Is there are single value that best represents the overall steering ratio in the current steering module?
Another thought that I need to put into action is to disable the auto-calc when the wheel type is a track, since it has really no point (except for with the surface track, which has wheel-style steering I think?) when track steering is in play, unless a part uses both forms of steering together.
I think best case scenario is to not replace the class entirely with a derived class. That would make more work for me if/when you update the steering module with some new feature or whatnot. Would cause the end-user to get some strange results. The best plan would be to alter the way the module is working though another module.
Delegates... oi. When the class I took covered them, the idea, from what I could figure out, was that it allowed you to input an unknown function as a parameter instead of just a data type. This differed from providing a data type using a method like we do all the time, but rather providing the method itself for the parent method to use. I suspect I have it all wrong though and the teacher was just condensing it.
This all being said... in the process of making this I have discovered several ways the existing code could be updated for some efficiency bonuses. I'll probably have some coding recommendations for you in the future. I also managed to implement a few features that you had in To-Do comments. I'll include those when I make any recommendations. As for now.... there are floors to vacuum and I'm the vacuum technician (glorified carpet janitor really) so... off I go.
-
I literally noticed you use virtuals and such just after writing the last comment. Anyway, they're new to me... so still exciting stuff.
I will look into that. I hadn't thought of looking into the submodules considering my only experience is in simply modifying public variables in other stand alone modules. I'll have to mess around with that. One thing that may be a bit problematic is that you have a low and high limit setting for steering while, in the old code, we simply had a single variable for max steering angle. It turns out lo-fi's code is deceptively simply. It really just counts out all the wheels of a compatible type are on the craft and gives them a position in an array of sorts, then uses a curve to set their optimal angle. That's simplifying it, but that's it in a nutshell.
So, the current plan is to simply make it a toggle option in the wheel's configuration. If any single wheel has the option set, it will take the other wheels into consideration when setting up the angles for that one wheel, but will only update and disable the manual configuration for wheels that also have that setting applied. Thus you could have steering that only uses the front wheels, but they'll take the rear wheel positions into account when setting the angles. That's the idea anyway. It would be a lot more efficient, of course, if the detection and settings could be run from a vessel module instead, keeping it form being repeated for every wheel with that setting applied, but I'm unsure as of yet how that might be achieved while still allowing for per-part toggling of the option. I'm still playing with it though.
As for delegates... I really hate those. Mostly for the reason that I simply can't seem to wrap my brain around them.
Morning-after update:
So, I guess I'm going to have to launch KSP with KF installed and do some fiddling around. I don't actually know how most of these settings are applied or what they do. I did take a look at hooking into the submodules class, but I can't just add my module in there and do things, I need to override things that are happening in other modules. This is all getting really complicated and I wonder if I should just make some modifications to the original steering class in your project and submit them to you directly for integration.
(otherwise I'll forget about it and it'll never get fixed)
[1.8.x] KSPWheel - Physics Based Alternate Wheel Collider [API Only]
in KSP1 Mod Releases
Posted
Indeed, our new fearless leader has kept up the mod really well despite other more demanding projects he has up his sleeve.
You and your locomotives... it's gonna take you out of this world someday. Mark my words.
Ah ha! I see what's going on here... the "legs" are just wheels that have their "turning" animation tuned to a sequence that imitates "walking" across the landscape. Well played! Almost had me fooled.