shoe7ess
-
Posts
291 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by shoe7ess
-
-
On 1/14/2024 at 7:00 AM, Apollo13 said:
That was the problem. Deleted the offending files and Spacewarp from plugins and patchers. Downloaded/Installed Spacewarp. I can launch in the new campaign and load and play with the previous "broken" one. THANK YOU
Man.... I wish I came here over at some point over the last 3 days instead of tried to decipher why my save broke, and when I figured out a way to fix that in the .json file I finally got in and had the same issue with launching rockets. Nothing would launch but I'd hear GUI reactive noises (like hitting escape) on the never-ending load screen, no matter how hard I tried, and I did the same thing, removed all mods but the "Core" ones (including this, Util, and the new dependency). Eventually I took out my BeepinEx folder and I could finally load up rockets on the launchpads so I slowly started returning my campaign and saves back in and came here just to find out that there were those 3 files that needed deleting on the update post.
FYI, I'm usually pretty good about following directions, but I grabbed the update through Spacedock and since the deletion instructions were in the changelog but not on the general information tab, I spaced right over it. I was getting some crazy errors too, like a brand new sandbox with a vessel I made that was literally just a Mk1-2 capsule and tried to launch it from the KSC screen (where I had seen some fixes work) and kept getting the "invalid or non-unlocked parts" error.
Seriously, I spent probably 14 hours trying to get this work (I'm very hard-headed) and all I had to do was see your message trail...
Anyways, mods great, thanks for the hard work! I will eventually turn the hours of debugging and .patch creating into true modding (I'm really interested in learning 3D modeling, figured here or KSP1 may not be a bad place to start), so I'm sure I'll have some use for it down the road
-
Removed - lack of ability to read on my part apparently when it comes to a mod update
-
On 1/7/2024 at 3:23 PM, Deadly_Laser said:
KSP 2 packs a lot more stuff into Unity assets instead of easily accessible files, so I suspect changing the flag mid-game may need an interface like the Patch Manager mod, but I defer to @cheese3660 on this.
Ahhhh that makes sense. I figured it would just be a "pointer" in the save .json file, but it's never that easy, is it? Guess it's time I start brushing up on one of the languages I'm not quote fluent in (until they implement flag changes mid-game or some other cheeky modder finds an alternate method. Thanks for the response, looking forward to this being in every KSP 2 saves for the next 12 years XD
-
Sorry if this is a necro, but is this mod still in development? The parts are fantastic and I've been very interested in seeing where this goes.
If it's abandoned I appreciate all you've contributed and hope you continue modding in the future! -
I love this mod and have added tons of custom country and real life agency flags to my game. However, I found the mod after I had spent a decent amount of time into a science campaign and wanted to switch the my vanilla flag. So I headed to my most recent save file and compared it against a new game with my custom flag chosen from the start of the save and found out that it was only found on the FlagSpriteLocation line and no where else that I could see. So I found that line in my campaign save and copy/pasted the same line with the custom flag location but it will not update in my game. I can't find any other lines within the .json file that would need to be updated so I'm wondering: is it even possible to change your flag mid-game at all? There's no flag data in the .meta file, so I'm at a loss unless someone else knows of a method to do the switch?
-
1 hour ago, munix said:
You got pretty close, the main differences are that you need semicolons after the assignments, and it's actually Module_Decouple without the "r" at the end. To access the data inside a module, you need to go a level deeper into Data_Decouple. Also, I don't think the impulse needs to be patched here. Here it is:
:parts #decoupler_1v_radial { * > Module_Decouple > Data_Decouple { ejectionForce *: 10; } }
And if you wanted to do it for all radial decouplers at once (also showing the shorter version of the selector):
:parts #decoupler_??_radial > Module_Decoupler > Data_Decouple { ejectionForce *: 10; }
Man, you are awesome. Thanks for the info, I'm glad I wasn't too far off. I could plow MM like a boss back in the day and I can't wait to reach the same point with PM
-
Spoiler
For the first one, it should be something like this:
@patch celestial_bodies; :json celestial_bodies > data { @if $$bodyName == "Mun" { rotationPeriod: 800; isTidallyLocked: false; } }
I tested only briefly, but it seems to work.
For the second one, there's no directly replacement, since Patch Manager can only edit or create JSON files (which the games for the definitions of parts, planets, science, and things like that), but the skybox is just a texture, and Konfig seems to have included a lot of custom code to get that to work, so the next best thing would be to take the C# code from Konfig's source and use it to put together your own mod that replaces the skybox textures similarly to how it did.
You are awesome. I was actually on the right (well, I thought maybe it had to be editing .json data), but thank you for saving me the time on that! I may make that my first C# project (never programmed with that language before and, although the stock one is quite beautiful, the one I made from Space Engine would be gorgeous).
However, I've worked on a part patch for about 3 hours of troubleshooting and is just not taking. I'm attempting to increase the ejection impulse of the radial decouplers in the game. Originally I wanted to just multiply the values by 10 but was running into too many errors I didn't understand in the log so I eventually just landed on a flat "5000" kN for each part. However, no matter how hard I try, I can't get it working. I have tried the following different methods:
Spoiler:parts #decoupler_1v_radial { > Module_Decoupler { ejectionForce: 5000 EjectionImpulse: 5000 } } :parts #decoupler_1v_radial { @merge { ejectionForce: 5000 EjectionImpulse: 5000 }; } :parts #decoupler_1v_radial { ejectionForce: 5000 EjectionImpulse: 5000 }I have attempted with and without the "EjectionImpulse" line and receive no errors in the log, but they still have default impulse values...
-
Hey, thank you for the mod! I've been working on my own .patch files and learning the syntax based on the wiki. I can make the part changes I'd like pretty easily, however I'm trying to convert a .konfig file over to a .patch file since I was told Konfig was being/already is deprecated. Could I get some help translating the Mun Rotation (and preferably a Custom Skybox) .konfig scripts over to .patch files? I honestly don't know where to start since I've only just started getting use to this language, but I can't quite wrap my mind around how to make it work. The black skybox and .konfig show that they should work on 0.2, but nothing loads (and I only get on kpatcher line in my log files, and it's a ton of errors). If anyone could help, the .konfig codes are:
Mun Rotation Konfig:
[Target(Mun)] [Module(CelestialBodyComponent)] [Data(CelestialBodyProperties)] Data.rotationPeriod = 800; Data.rotates = true; Data.isTidallyLocked = false; Module.SetDefinition(Data);Custom Skybox Konfig:
[Target(Black)] [Module(Skybox)] [Data(int)] Data = 1024;Thanks for the hard work on this mod. I'll continue to attempt to create the .patch files for the above in the meantime. If I come across a solution I'll update as needed.
-
Thank you for this amazing mod. I spent hours patching with MM after I understood the syntax but now I'm working on learning how to create the .konfig files and could use a little help with a (hopefully simple) part patch. I would like the radial decouplers to have a much stronger max impulse so I used the solid fuel booster patch example as a framework and tried to work out how to implement this using a language I'm not very familiar with (yet). I came up with the following, but I'm not sure if I have the syntax correct:
[Target(decoupler_1v_radial)] [Module(Module_Decouple)] [Data(Data_Decouple)] Data.ejectionForce *= 10; [Target(decoupler_2v_radial)] [Module(Module_Decouple)] [Data(Data_Decouple)] Data.ejectionForce *= 10;I can not get it to update the ejection impulse in-game. Am I on the right track or do I need to attempt this from another angle?
-
16 hours ago, viperfan7 said:
Having looked at it uses dotpeek, it doesn't seem to be fully implemented, but the base code is there, they're obviously going to make it, and they did state as much
Get ready for the strangest sized trusses you've ever seen!!!
-
9 hours ago, GoldForest said:
IIRC, Intercept said they were going to include some form of MM in game, and people have dug into the code already and found a mod manager already in the files. I don't remember where I heard talk about it, I think somewhere on the forums or reddit.
Anyway, a stock MM might already be in game, we just don't know how to access it/code for it without official support, and the first official modding support to come will be support for part mods only, with no word on plugin support.
Well that is awesome to hear. If I put my WakaTime from just MM coding for KSP1 public I would likely exile myself for shame. Think I spend more tweaking things than playing lol.
Oh, off topic, but your SISS came out amazingly!
-
1 hour ago, sarbian said:
My reply for MJ applies.
Unfortunate, but appreciated. Thanks for the heads up sarbian!
-
As the title states, I'm assuming something akin to Module Manger will come to KSP2, but I just figured I'd throw in a request or (maybe more-so a question) as to if/how/when MM or something similar could be implemented? If I'm able (time allowing) I really want to start modding, maybe using the base mod creation tutorial (obviously I'd have to do some more digging, different game and all) as a base, but I am a script-kiddie at heart and would love to delve into modding for this game at the start. If anyone else reading this has any other guides/systems/programs that would help in this regard I'd greatly appreciate it!
Thanks!
-
Really looking forward to module manager (hopefully), that'll be fantastic for player-sided balancing.
-
This. Of my top three suggestions, this is number 1 (maneuver node planner being number 2 tied with the trajectory/conics bug, and GUI re-sizing being 3). I'm trying to keep my suggestions to things that I'd assume (I'm no developer, so who knows), would be easier to implement sooner rather than later (obviously things like performance/visuals/etc are all things we want, but priority and time-sink wise some of those may take awhile to implement)
-
1 hour ago, CobaltWolf said:
Well, obviously we'll have to wait and see how things shake out. But we're moving forward on the assumption that the 'clean slate' will lead to a much better game in a year or two's time.
Ha, I've definitely thought about Pegasus/Taurus, but I wouldn't hold your breath this time around.
Some day, I'm sure...
Thank you! I'm certainly excited and we have some ideas for the new systems (colony parts based on old moon base proposals, anyone?)
These were my thoughts.
Think about how long it took to just get something like volumetric clouds in the game (though no small feat I can only imagine and I'd imagine held back by the engine being used for most of the life-cycle). Imagine if this game caught steam before it even it the shelves. The state of modding now is incredible, but back in the ~0.19 days the mods were great but the choices were much more slim comparatively (I think the front page always had FASA, RT, Karbonite, Proc Fairings, MLT, MJ, EVE, TR, and a handful of others I can't recall right now showing 99% of the time, not that you could surpass about 2Gb GameData at the time anyway without a crash every 30-45 minutes).
I'm not exactly looking forward to going right back to incremental builds but I have complete faith in Squad and their devotion to the quality of the game as well as reception of community feedback (hell, their phase plan is kind of built around how well their new mechanics are implemented). I think this would remain the case regardless of publisher (if they got picked up by any other pub than some indie-publisher would your view honestly change)? That's not to say that the split wasn't pretty excrementsty (I remember the circumstances being pretty "big-business"). I truly doubt studio interfering will be an issue. God I hope I didn't just feed a troll for 20 minutes...
-
2 hours ago, GoldForest said:
I'm also making this up as I go. I have no real plan.
I'm pretty sure that's the Official KSP In-Universe Motto.
-
1 hour ago, GoldForest said:
Sorry, was on my phone when I posted that and my phone likes to glitch out when using the forums... IDK why. It was erking me so I just posted what I had. I forgot to come back and edit it to thank you for your compliment, so thank you!
I do take suggestions, I'm not against them. I'm just against using tweakscale or procedural parts. I'm more of a... for lack of a better work, "As the parts were intended" kind of guy. Hence the question about 3.125 meter station parts.
Well keep them coming, I'm following this topic now. Not nearly enough beautiful ISS builds out there that I've noticed (maybe just not searching hard enough). I can definitely respect what I guess could be considered "native" parts only, just to me that would be a friggin challenge run XD
I look forward to the station coming together, I'll throw it in with my loading screen pics, maybe give me some inspiration (I'm running a historical progression contract/part career that eventually leads to FFT with OPM and then the Kcalbeloh System but I really am just looking forward to the 60's/70's era missions the most!
-
50 minutes ago, GoldForest said:
Lol, they're not the author of this thread.
Er... sorry for the confusion? Thought it was a clear agreement + additional reason to accept Tweakscale into your life
Maybe I should have started with "This." or "Exactly."?
You do you man. seems you're pretty against suggestions to your build, I can respect that, but man, that's all that stuck out to you, not complementing on your pics at the end or anything?
-
1 hour ago, DeadJohn said:
Maybe you should if you want parts at 3.125m.
Seems like it might help get you more parts fitting together more to your liking (along with TU/PP/Decals/etc). If you give it a shot, throw this in a .cfg file anywhere in your gamedata folder and you can get parts of any size, been working (with a few updates over the years) since pre 1.0:
Spoiler@PART[*]:HAS[!MODULE[ProceduralPart]]:FOR[!ProceduralParts]:FINAL // P-Parts since they're already scalable, the second occlusion is for redundancy sake. { %MODULE[TweakScale] { %type = free %defaultScale = 100 } } @PART[*]:HAS[@MODULE[RealChuteModule]]:NEEDS[RealChute]:FINAL // Used to break Real Chutes { !MODULE[TweakScale] {} } @PART[kerbalEVA*]:FINAL { !MODULE[TweakScale] {} } // Game Breaking (probably, don't care enough to test) @PART[PotatoComet]:FINAL { !MODULE[TweakScale] {} } @PART[PotatoRoid]:FINAL { !MODULE[TweakScale] {} } @PART[flag]:FINAL { !MODULE[TweakScale] {} } @PART[kerbalEVA]:FINAL { !MODULE[TweakScale] {} } @PART[kerbalEVAfemale]:FINAL { !MODULE[TweakScale] {} } @PART[kerbalEVASlimSuit]:FINAL { !MODULE[TweakScale] {} } @PART[kerbalEVASlimSuitFemale]:FINAL { !MODULE[TweakScale] {} }Regardless keep the mission coming, the visuals are gorgeous!!!
-
In case anyone actually is following, I've made further progress on the LV Builder description MM patch. I've gotten to Redstone, and thus my first multi-build part. I've found that the Redstone has some Juno parts that could be found with only "Juno" in the name, which wouldn't be caused by the patch so I'm not sure what to do about that unless I get into more detailed builds, which would just bloat the descriptions. Really wish I could embed links sometimes...
Anyone interested, made some fixes from the last. Still not sure about the syntax to add the description (I used another as an example with ^= at the beginning, but used the regex to insert the actual text to the end of the descriptors. I still have a ways to go but keep finding ways to improve/make things easier.Daily 2/14/2022 (Going to be making a repo soon and just tossing the random MM stuff you guys may see around the forums on it I think. we need a more up to date MM patch)
Spoiler// This adds the build information to help put together rockets to each LV (taken from https://github.com/friznit/Unofficial-BDB-Wiki/wiki) // Patch created by shoe7ess // These add the build description to the parts using the "real_description" already @PART[*Scout*]:HAS[#real_description]:AFTER[BDB_RealNames] // https://github.com/friznit/Unofficial-BDB-Wiki/wiki/Scout { +real_description ^= :$:Scout LV<color=yellow> First Stage = Algol | Second Stage = Castor | Third Stage = Antares | Fourth Stage = Star-20 Altair</color> : } @PART[*Vanguard*]:HAS[#real_description]:AFTER[BDB_RealNames] // https://github.com/friznit/Unofficial-BDB-Wiki/wiki/Vanguard { +real_description ^= :$:Vanguard LV<color=yellow> First Stage = Vanguard (SLR50) | Second Stage = Vanguard-800 AJ10 (Thor/Able) | Third Stage = Vanguard-100 (AJ10-37) | Star-20 Altair</color> : } @PART[*Redstone*]:HAS[#real_description]:AFTER[BDB_RealNames] { +real_description ^= :$:Jupiter-C/Juno I LV<color=yellow> First Stage = Redstone-1400+400 "Juno Config" (Sandstone) | (Juno Guidance Unit & Control Jets) Second Stage = Explorer (Sergeant Rocket) | Juno Nosecone</color> : +real_description ^= :$:SPARTA<color=yellow> First Stage = Redstone-1400 (Sandstone) | (Sparta Guidance Unit & Control Jets) | Second Stage = Star 31 Antares III | Sparta Interstage | Third Stage = Star BE-3 | WRESAT</color> : +real_description ^= :$:Mercury-Redstone<color=yellow> First Stage = Redstone-1400+400 "Juno Config" (Sandstone) | Redstone Guidance Unit | Second Stage = Mercury Command Pod (Assembly)</color> : } // These add the build description to the parts that don't have the "real_description" line in the part info, optional but useful @PART[*Scout*]:!HAS[#real_description]:FOR[BDB_RealNames] // https://github.com/friznit/Unofficial-BDB-Wiki/wiki/Scout { +description ^= :$:Scout LV Build<color=yellow> First Stage = Algol | Second Stage = Castor | Third Stage = Antares | Fourth Stage = Star-20 Altair</color> : } @PART[*Vanguard*]:!HAS[#real_description]:FOR[BDB_RealNames] // https://github.com/friznit/Unofficial-BDB-Wiki/wiki/Vanguard { +description ^= :$:Vanguard LV Build<color=yellow> First Stage = Vanguard (SLR50) | Second Stage = Vanguard-800 AJ10 (Thor/Able) | Third Stage = Vanguard-100 (AJ10-37) | Star-20 Altair</color> : } @PART[*Redstone*]:!HAS[#real_description]:FOR[BDB_RealNames] { +real_description ^= :$:Jupiter-C/Juno I LV<color=yellow> First Stage = Redstone-1400+400 "Juno Config" (Sandstone) | (Juno Guidance Unit & Control Jets) Second Stage = Explorer (Sergeant Rocket) | Juno Nosecone</color> : +real_description ^= :$:SPARTA<color=yellow> First Stage = Redstone-1400 (Sandstone) | (Sparta Guidance Unit & Control Jets) | Second Stage = Star 31 Antares III | Sparta Interstage | Third Stage = Star BE-3 | WRESAT</color> : +real_description ^= :$:Mercury-Redstone<color=yellow> First Stage = Redstone-1400+400 "Juno Config" (Sandstone) | Redstone Guidance Unit | Second Stage = Mercury Command Pod (Assembly)</color> : }
-
34 minutes ago, DeadJohn said:
Tweakscale? Not all parts are Tweakscale compatible, though.
I recently resized some Near Future Construction trusses that had a good artistic look for my station spine but were the wrong width. SSPXr has many more station parts but I forget whether they are compatible with Tweakscale.
I have been using a Tweakscale MM patch I made that adds it to just about everything (had to omit a few mod specific items as well as suits). I haven't had the incompatibility menu pop up on me (maybe because of when the patch passes or just it being an MM patch), but you do have to work it case-by-case sometimes. It generally does the job and you could always do the math on a part you like and MM patch it to rescale to that size (just create a new part based off the original and set the rescale to make it match 3.125 (like a 1.25m part would become 2.5x the original) then you can use either nodehelper, multiply an array, or just do the math for the attachment nodes yourself. If you set a tweakscale patch to use free scaling on something like the trusses mentioned by @DeadJohn you would just need to use the slider to get it to match (depending on shape I'd guess)
-
Hey all,
I just started a MM patch that adds the build guide/description found on the BDB unofficial wiki stages using the real rocket name information. Basically it lists the stages (and engines where possible) found on the wiki and appends it to the end of any part used for that launch vehicle. I plan on going through the descriptors, cross-referencing where needed (my knowledge of real life rocket names has vastly increased over the years since starting KSP but I'm not great with the stages on many of the launch vehicles/rockets still) and then adding to the existing MM patch little by little each day. However, I want to make sure this hasn't been done, or no one has started or is currently already working on something like this. So I figured I'd save my self some potential headache and ask first.
Example of what's being made (just finished the Scout and Vanguard, making a version for real_description parts and part names only):
Spoiler// This adds the build information to help put together rockets to each LV (taken from https://github.com/friznit/Unofficial-BDB-Wiki/wiki) // By shoe7ess // These add the build description to the parts using the "real_description" already @PART[*Scout*]:HAS[#real_description]:AFTER[BDB_RealNames] { +real_description ^= :$:Scout LV Build<color=yellow> First Stage = Algol | Second Stage = Castor | Third Stage = Antares | Fourth Stage = Star 20 - Altair</color> : } @PART[*Vanguard*]:HAS[#real_description]:AFTER[BDB_RealNames] { +real_description ^= :$:Vanguard LV Build<color=yellow> First Stage = Vanguard | Second Stage = AJ10 (Thor/Able) | Third Stage = Star-20</color> : } // These add the build description to the parts that don't have the "real_description" line in the part info @PART[*Scout*]:AFTER[BDB_RealNames] { +description ^= :$:Scout LV Build<color=yellow> First Stage = Algol | Second Stage = Castor | Third Stage = Antares | Fourth Stage = Star 20 - Altair</color> : } @PART[*Vanguard*]:HAS[#real_description]:AFTER[BDB_RealNames] { +description ^= :$:Vanguard LV Build<color=yellow> First Stage = Vanguard | Second Stage = AJ10 + Able | Third Stage = Star-20</color> : }
I got tired of having to alt-tab to look some stuff up when building my rockets (the notepad mod worked great, but it sadly stopped showing up in my save) and I'm following a historic progression career that utilizes BDB almost exclusively. I am very grateful that the part names are all very easy to grab on an @PARTS pass, so it's just adding the extra info using that as a starting point. I may change my mind on color and location but it's a start.
Any suggestions/help would be greatly appreciated (if you know the basic stage setup to some of the rockets in BDB and don't mind sharing it that would also be insanely helpful. The wiki tends to use real names and the BDB names interchangeably sometimes, and I want to make sure I'm following the right track, or plume, or whatever. Thanks! for all the awesome pictures by the way fam, I've started putting them in my loading screen to fill up that 20 minutes of monotony.
-
On 5/31/2022 at 9:20 AM, Aelfhe1m said:
None unfortunately. Best I've come up with is a Module Manager patch to show the internal experiment ID in the contract and in the part information box in the editor.
@PART[*]:HAS[@MODULE[*ModuleScience*]]:FINAL { @MODULE[*ModuleScience*] { @experimentActionName = #$experimentActionName$ ($experimentID$) } } @CONTRACT_TYPE:FINAL { @PARAMETER:HAS[#type[CollectScience]] { &title = "Collect science" @title = #$title$ [$experiment$] @PARAMETER:HAS[#type[CollectScience]] { &title = "Collect science" @title = #$title$ [$experiment$] @PARAMETER:HAS[#type[CollectScience]] { &title = "Collect science" @title = #$title$ [$experiment$] @PARAMETER:HAS[#type[CollectScience]] { &title = "Collect science" @title = #$title$ [$experiment$] } } } } }
This is only a partial fix however as some contracts are written in a way that won't display any useful extra info with this patch.
Thank you!
I've been working on an MM patch that takes duplicate experimentIDs and removes all but the ones from the part packs wanted (configured in the patch). But short of going through every single science def list I didn't see an easy way to populate it. This is so useful, thank you!
13 hours ago, SneakyGunz said:I found this mod amazing. I see it's no longer working in game. Will this be brought up to date at some time? Thanks.
I have no issue with it in either of my heavily modded installs (each with custom contracts galore). Do you have any errors/conflicts in your log? If the icon doesn't show up I have the same issue with another mod (kind of just stopped showing up), but I think it's just due to a 20Gb gamedata folder, too many icons >.<
[1.0.0] (LOABE) Lux's OAB Extensions
in KSP2 Mod Releases
Posted
Bump. This carry-over was a must have for me (and I'm assuming a lot of people) in KSP. It stopped working a couple updates ago, I think 2.0 broke it but I'm not sure. I'd love for this to get updated. I'm assuming it's not abandoned since you just updated the plume mod, I'm hoping you can get a version of this up for 2.1 (and I'm sure I'm not alone)?