Krydax
-
Posts
54 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Krydax
-
-
On 7/22/2022 at 8:14 PM, Chris Bolland said:
I FOUND THE ANSWER.
You have to go into the config in the mod files, under the folder "upgrades" and then change the configs 'techrequired level' for the unlimited size upgrade to, say engineering 101 or something low level. You can delete all the other upgrade levels, since unlimited is what you want.
This works!
A bit more detail for those wondering:go to procedural parts/parts/TechTree/upgrades.cfg and edit it
I just set every single "techrequired = ___" line to "techRequired = start". You probably can just do the unlimited ones but I went overboard and it worked like a charm!
-
11 minutes ago, Grenartia said:
Sorry to say, I have none, since I don't use procedural parts anyways. Have you considered asking in its dedicated thread?
Yeah I've headed over there. I just figured I'd revive this as Galileo may or may not have interest in updating it to work, and also always helpful to post when things are/aren't working as expected so other people can see that they're not the only ones, etc.
---------------------------------------
I was able to fix it, as per this comment
Basically just setting the techRequired in the gamedata/proceduralparts/partstechtree/upgrades.cfg file to "start" for all the upgrades.
-
On 6/22/2024 at 11:10 AM, Zah said:
The problem with this is: it doesn't work as described, and there's quite a few threads with people saying it doesn't work and hacking their way around it in all kinds of ways*
As the poster you reply to wrote, not having "unlimited" sizes available from the start makes this mod useless for reducing part count lag. Calling people who want to do that "cheaters" is also not exactly nice. I suggest you reconsider that thinking -- part count lag is a problem people try to mitigate with this.
It'd be awesome if the mod had an easy pre-configured state people could just switch in and out without having to spend a lot of time learning how to properly write mm patches.
Did you ever find a solution? I also wasn't able to figure out how to make the "readme" method work. Definitely didn't work as advertised. And the "procedural start" mod
doesn't seem to be working either.
I feel that it's a relatively simple patch that needs to be applied to procedural parts, but I don't know squat about KSP modding so it's not really something I know where to start with. -
3 hours ago, Grenartia said:
I don't know why you'd think B is most likely. Current version is 1.12.x, the earliest mods that are still generally recognized as compatible with the current game are from 1.8.x, and this mod hasn't been updated since 1.4.x
Yeah idk. I've had it working before though on 1.12, so I'm just not really able to figure out what's different. My guess is that something changed in procedural parts in one of the "recent" updates and so the old solution to making stuff unlocked from the start doesn't work anymore. I would love a new solution, it's weird to me that this idea doesn't have more traction! I love being able to just make my fuel tanks the size I want them to be, it feels so weird to need to stack 8 of them or whatever. Personal preference, of course. But anyhoo, any ideas are greatly appreciated!
-
Just started a career run and this mod doesn't seem to be working. I'm guessing either
A. outdated and simply doesn't work with PP anymore (I could test this by removing all other mods and starting career mode, etc, but that takes a lot of time I haven't had yet)
B. There's a conflict within my mod soup.
I'm thinking B is the most likely, but I have looked through all my mods and just can't seem to figure out what would be causing it. This is my modlist: https://pastebin.com/SMpyRr7mAny help or ideas would be greatly appreciated!
-
Oh, well, carry on then! Thanks for the great mod
-
I seem to be having a new issue with Realchute with my current mod soup, never had an issue with it before. Right now it's not really "loading" when I'm in the VAB. There's no button for it, and when I look at the possible buttons on the blizzy toolbar, you can see that the icon is there, and selected, but no button actually shows up on the toolbar which is odd. And nothing happens when you select a parachute in the action groups mode (which always used to pop up the editor), etc.
https://imgur.com/a/vHftTs2
However, the "show editor" right click menu appears to work. So not totally sure what's wrong.
https://imgur.com/j63VMjS -
So the rescale mod includes "rescaleAntennas.cfg", which includes the following:
@PART:FOR[SigDim2]:FINAL { @MODULE:HAS[#name[ModuleDataTransmitter]] { @antennaPower *= #$@SigmaDimensions/Rescale$ } }I add the ":FINAL" to it, because it was ONLY applying to the probe cores, and none of the antennas. However, that did not seem to fix the problem. Antennas still are not multiplied by 3.2x range. Any ideas? I have commnet antennas consumptor, exntension, info, as well as scansat, and NFE exploration (to name the mods that affect antenna stuff)
-
14 hours ago, Lisias said:
Great! So I'm presuming you don't need me anymore to look into your problem, right?
Cheers!
Well I guess that depends on if the new tweakscale works better/more safely or not! Haha. Either way, the weird behavior I was running into is probably worth looking into as I'm sure other players will run into it too eventually.
-
26 minutes ago, Lisias said:
I'm revisiting the topic, and concluded that your case is related to:
https://github.com/net-lisias-ksp/KSP-Recall/issues/41
https://github.com/KSP-RO/ProceduralParts/issues/315
and unfortunately also on
https://web.archive.org/web/20230615130933/https://github.com/KSP-CKAN/NetKAN/pull/9076
I removed AttachedOnEditor from Procedural Parts because, at least at that time, it apparently wasn't necessary and I was still wanting to prevent drama with CKAN (see my last link). This is the comment where I did it:
https://github.com/net-lisias-ksp/KSP-Recall/issues/41#issuecomment-1102662484
I thought this would be the wisest move to prevent friction about the respective authors.
Obviously, on the urgency of getting rid of that unwanted attention, I surely missed testing some use cases and I'm betting yours is one of them.
There's also the probability of the problem, now, is being induced by some 3rd parties that weren't present (or did exist at all) at that time - perhaps something new in the stack destabilised something in Editor, creating the problem. Or, alternatively, something that used to prevent the problem in the past is not being used anymore, allowing the problem to surface. Who knows? I'm surely don't!
Anyway, now I have some time to burn and I will toy with your jankycraft thing on my test bed. I will know precisely what's going on now.
Stay tunned!
Thanks for your work!
There's also a NEW tweakscale fork in the works now. What a time to be alive! So many modders still keeping this amazing game alive! Can't wait until KSP2 actually has enough stability & features that it can be better in every way than KSP1! -
18 minutes ago, Lisias said:
I would settle with 3rd parties following KSP standards, instead of going their own way just because it's easier for them.
TweakScale works fine out of the box with everything that uses KSP Standard, needs a Companion when there're new things being inserted to KSP - but have problems when they go rogue and break expectations and standards just because doing that didn't broke anything under their noses.
There was a serious problem of Team work around here.
1st, make a full backup of your rig - not to mention the savegames. This kind of experiment can go South badly - worst, go South after some time when you became confident that everything was going fine.
That said, brute forcing AttachedOnEditor into Procedural Parts is easy. Write this patch on a file somewhere in the KSP's file hierarchy (I suggest GameData/__LOCAL/ProceduralPartsOnAttachedOnEditor.cfg for easy localising):
@PART[*]:HAS[@MODULE[ProceduralPart]]:NEEDS[TweakScale]:FINAL
{
%MODULE[AttachedOnEditor]
{
%active = True
}
}This should do the trick. Be aware that, perhaps, only some Procedural Parts would need the AttachedOnEditor injected on the Part, while others may misbehave by doing that - there must be a reason I withdrew AttachedOnEditor from the mainstream 2 years ago (and I wish I had took note of it on somewhere easily findable - I really don't remember the details).
Let me know what you find. Cheers!
I guess I'll be the guinea pig
-
3 hours ago, Lisias said:
KRAP. I can't edit comments now. (sigh).
Anyway:
This is weird. Procedural Part is being specifically avoided while patching AttachedOnEditor, that it's the PartModule that prevents exactly the problem afflicting you.
https://github.com/net-lisias-ksp/KSP-Recall/commit/5d3056e78b85d2ba6fa462002ead237010d01bfe
This patch have about 2 years already.
Initially I wondered if this is not something related to an old issue on Procedural Parts ( https://github.com/KSP-CKAN/NetKAN/pull/9076 ), but then I realised I withdrew AttachedOnEditor from PP one month before.
I'm trying to remember why I removed AttachedOnEditor from Procedural Parts right now. On a superficial analysis, adding it back may fix your problem, but I need to remember why by Kraken's sake I removed it at first place.
— — POST EDIT — —
And now I can edit posts again.
How would I, for experiments sake, add AttachedOnEditor back to the Procedural Parts?
-
25 minutes ago, Lisias said:
It's the exact reason I tried to support PP in the past, applied pull requests with fixes, etc.
But in the long run, there's so much I can do by myself. What I can do is to try to work around problems as possible.
Yeah it's frustrating when compatibility isn't being supported from both sides
-
14 minutes ago, Lisias said:
KRAP. I can't edit comments now. (sigh).
Anyway:
This is weird. Procedural Part is being specifically avoided while patching AttachedOnEditor, that it's the PartModule that prevents exactly the problem afflicting you.
https://github.com/net-lisias-ksp/KSP-Recall/commit/5d3056e78b85d2ba6fa462002ead237010d01bfe
This patch have about 2 years already.
Initially I wondered if this is not something related to an old issue on Procedural Parts ( https://github.com/KSP-CKAN/NetKAN/pull/9076 ), but then I realised I withdrew AttachedOnEditor from PP one month before.
I'm trying to remember why I removed AttachedOnEditor from Procedural Parts right now. On a superficial analysis, adding it back may fix your problem, but I need to remember why by Kraken's sake I removed it at first place.
— — POST EDIT — —
And now I can edit posts again.
Haha. Classic programming issue. Trying to understand 2-years-ago-you is like trying to decipher ancient greek texts.
In any case, thank you for your work looking into a fix! If it does indeed fix it, just let me know how to add it back in. And who knows. Maybe it breaks something else, but it's not as annoying? Cause currently this issue is annoying enough that it's gonna cause me to not use PP tanks at all which is kinda defeating the whole point.
-
I am very intrigued on trying out this tech tree. I'm curious if it's still a good experience if I don't use BDB? I do have all of Nertea's mods, as well as things like spaceY, restock+, dmagic orbital science, infernal robotics.
Also does this mod prune its own empty nodes (if it has them?)
EDIT: Oh, i just realized this mod has BDB as a dependency. Nevermind! I'm not sure if I can handle BDB since I'm not really into the whole historical-missions/parts thing anyway. -
22 minutes ago, Lisias said:
That's interesting… Please restore your rig, reproduce the problem, quit KSP and send me somehow the KSP.log and the screwed craft file for analysis.
Yay! I love when I find new and interesting bugs. Makes me feel special....
I did what you said. Open game, make the craft i explained above, launch, revert to vab, glitch is happened, quit KSP, and here you go!
https://filebin.net/saih0x8b958ahsq3 <- KSP loghttps://filebin.net/8c4vekh75my7l6er <- Janky craft in question. Launch & revert to VAB as many times as you want to increasify the jank! =D
-
Okay
More testing complete.
By changing the engine on the bottom to uncheck "KSP-Recall::Attached on Edit", the engine properly "follows" the tank up into the service bay. So they both move together. (this is still bad though, cause the tank moves up into the service bay in the first place, because the service bay is tweaked to be smaller and the procedural part somehow double compensates when it loads in or something)That being the case, now I'm convinced that the issue is that the procedural tank does NOT have the "attached on edit" module. Is that meant to be the case? Or is it supposed to be lacking the attached on edit module?
-
I also saw that in KSP-Recall.cfg,
Line 17, ProceduralPartsAttachmentNodes = false
That stuck me as odd, but changing it to true didn't fix anything either. So idk. I think I'm in too deep at this point and have no idea what I'm messing with. -
Here's an interesting fact:
You mentioned the 999-KSP Recall 101_ProceduralPartsAttachmentNodesFix.cfg
Guess what, I deleted it out of my gamedata folder (just to see what happened), and the bug still persists the same way. So was that cfg even doing anything? It seems like it isn't doing what its intended to do. -
Just now, Lisias said:
I think Forum still have that problem with attachments? Anyway, if you have a github account, shove the Log on a comment here:
I don't think that's the same issue. In this case, a procedural part is not the root. I started with a probe core.
To add more info, I just reproduced it easily:
1. Probe core (okto in this case)
2. Service bay 1.25m, tweakscale it to .625
3. add procedural fuel tank
4. add terrior, tweakscale it down.
5. launch craft
6. revert and BOOM. Things moved and now stuff is janked.
I just tried with a flt400 instead of a procedural fuel tank, and the issue did NOT occur. So that does narrow it down to being procedural part related.
-
Just now, Lisias said:
Wait!!
Looks more like this: https://github.com/net-lisias-ksp/KSP-Recall/issues/41
Please be sure this patch is being applied:
Unfortunately, a proper fix on the Procedural Parts itself was denied, so we will need to deal with workarounds forever.
You are amazing. I will try this!
Here's my ksp.log too if you're interested. I'll report back with results!1 minute ago, Lisias said:Wait!!
Looks more like this: https://github.com/net-lisias-ksp/KSP-Recall/issues/41
Please be sure this patch is being applied:
Unfortunately, a proper fix on the Procedural Parts itself was denied, so we will need to deal with workarounds forever.
Ah. Just checked. I already have that file/patch. So I don't *think* that's the issue then?
-
1 minute ago, Lisias said:
This looks similar to this old issue : https://github.com/TweakScale/TweakScale/issues/168
Are you using B9PS?
I'm firing up my test bed to check this possible regression…
Yes, I have b9 part switch. As well as firespitter. I also have smart parts, but the auto-stuff is disabled on them, so that *shouldn't* be messing with anything. I can try removing it and see if bug continues.
-
21 hours ago, Lisias said:
Hi, sorry for that. It's a known bug on TweakScale - https://github.com/TweakScale/TweakScale/issues/307 .
The only known workaround at this time is to do not change Variants on scaled parts - set the part to the default scale, change the variant, and then scale it back to the desired one.
The root cause of the problem is that I didn't fully understood what Editor does under the bonnet under certain circumstances. Apparently the Editor is breaking the Modules OOP encapsulation doing things outside the Part's life cycle, screwing with Modules that tries to follow the cannon Life Cycle.
But it's a guess.
Adding insult to the injury, I quit trying to fix these on the 2.4 series, as only the 2.5 have some refactoring that are allowing me to implement/fix things with better chances of not breaking something else - right now, on 2.4, things are kinda on a fickly equilibrium where changes can trigger a crapstorm. But the 2.5 series will be problematic to deploy, because (due unrelated issues to this problem) I'm currently unable to add new add'ons to CKAN and, so, I will not be able to publish KSPe as a separated support library - and the 2.5 series don't use that KSPe.Light stunt anymore.
There's a chance that the 2.5 Series will be published only on Curseforge, as any attempt to update SpaceDock (where CKAN gets the new releases) will break the user's installations.
uhoh. New issue. Now when i revert to vab, things are disconnecting when I have tweakscaled parts. In this case, upon reverting to vab, a 1.5long0.625diameter procedural fuel tank moved "up" into a tweakscaled 1.25 -> 0.625 service bay (and a tweakscaled 1.25 -> 0.625 terrier on the bottom of the fuel tank is now "floating" underneath). So it's like the fuel tank moved but nothing else did. https://imgur.com/a/uFDZ2Lq
If tweakscale is going to break stuff every single time I revert/load a craft, then that may be too much of a thing for me to work around unfortunately. With any luck, there's something I can change, or I'm doing something wrong to cause this? If so I'm not sure what it is though. -
7 minutes ago, Lisias said:
Hi, sorry for that. It's a known bug on TweakScale - https://github.com/TweakScale/TweakScale/issues/307 .
The only known workaround at this time is to do not change Variants on scaled parts - set the part to the default scale, change the variant, and then scale it back to the desired one.
The root cause of the problem is that I didn't fully understood what Editor does under the bonnet under certain circumstances. Apparently the Editor is breaking the Modules OOP encapsulation doing things outside the Part's life cycle, screwing with Modules that tries to follow the cannon Life Cycle.
But it's a guess.
Adding insult to the injury, I quit trying to fix these on the 2.4 series, as only the 2.5 have some refactoring that are allowing me to implement/fix things with better chances of not breaking something else - right now, on 2.4, things are kinda on a fickly equilibrium where changes can trigger a crapstorm. But the 2.5 series will be problematic to deploy, because (due unrelated issues to this problem) I'm currently unable to add new add'ons to CKAN and, so, I will not be able to publish KSPe as a separated support library - and the 2.5 series don't use that KSPe.Light stunt anymore.
There's a chance that the 2.5 Series will be published only on Curseforge, as any attempt to update SpaceDock (where CKAN gets the new releases) will break the user's installations.
Aha. Thank you for confirming! At least it's known. Guess I'll just deal with it for now
Thanks for all your hard work!
[1.8+] Procedural Parts
in KSP1 Mod Releases
Posted
I was able to fix it, as per this comment
Basically just setting the techRequired in the gamedata/proceduralparts/partstechtree/upgrades.cfg file to "start" for all the upgrades, rather than whatever tech it previously had.