Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 (edited) On 2/28/2019 at 1:45 AM, AccidentalDisassembly said: OK - I continue to believe something is messed up within TweakScale, I don't believe. I know it. I'm not really fixing things for now, I'm patching them up to prevent the worst scenarios. There're no easy way out of this. I'm not masochist , I really didn't found a better solution other than that Big Refactoring from Krakens of mine. On 2/28/2019 at 1:45 AM, AccidentalDisassembly said: This is the picture I'll be referring to - this is what CERTAIN parts look like every time. Can't be scaled (except down by one step, but values in either slider do not change): That's interesting. I will investigate. [Reproduced. See the POST EDIT below] On 2/28/2019 at 1:45 AM, AccidentalDisassembly said: Just in case of MM screwiness (or something), delete all MM cache files, and also delete PartDatabse.cfg. I think this is a good time to explain that Module Manager is not the problem. It only happens that it doesn't have, at least to the momento, any features that would allow it to be part of the Solution (at least, the Solution I managed to cook). The problem are rogue patches. And the only sane fix is to detect and fix the patches. Clutches to cope with the rogue patches will just make things worst, as the clutches themselves can induce new colateral effects in a chain reaction - sometimes without perceptible symptoms until the crash and/or game corruption. On 2/28/2019 at 1:45 AM, AccidentalDisassembly said: All of that was wrong too. I have no idea what's going on, but it's borked even in a purely stock/TweakScale install, so something is messed up for sure. I tried. Thanks for your efforts. We don't need to agree on every step to recognize the huge efforts you are doing for TweakScale. If a purely stock with TweakScale is borking, you are right on pinpointing TweakScale as the source of the bork. I should had done this again after the new discoveries of past few weeks to tell you the true. What I know for sure is that TweakScale doesn't add itself to any part (and only recently I added code to withdraw itself from some nasty detectable scenarios), so the source of the glitch (to say the least) are the patches. This will be a dirty and gruesome task, but another one I need to accomplish is to test adding the patches gradually (it's a bit less painful using a binary tree search approach) in order to reduce the scope of the hunt. But, on the other hand (and again), that BFR (Big Fine Refactoring ) would render this task unneeded, as Add'On support will be dismembered, drastically reducing the surface of attack for such bugs. So I'm kind of uncertain if I should waste yet more time on patching new roles on the dam instead of solving the thing properly. On 2/28/2019 at 1:45 AM, AccidentalDisassembly said: On another note, for purposes of safety and reducing duplication, I would suggest that EVERY patch in TweakScale be edited to use "%type =" and similar rather than "type = " when doing patches - just in case someone else has already defined a type for a part (etc.). This is where I'm get some reserves with. This will not fix the rogue patches, this will hide them. The reasons for that follows: A bad standard is better than no standard. It's TweakScale the reference for scaling. Instead of blindly patching it to cope with random Add'Ons, it's that random Add'Ons that should, ideally, be patched to cope with TweakScale. By doing this, everybody will be on the same page. If TweakScale would cope with rogue patches by demand, so we would have no standard or expected defaults to cope with - and that would be a unholy mess of biblical dimensions. It's already hard to cope with the current patches (as you are pinpointing above). Now try to imagine the huge colateral effects we would have by blindly changing the patches. See below for a technical explanation This will not prevent rogue patches to exist. It will make them harder to detect. Right now, it's feasible to monitor MM as it applies patches in order to catch who is duplicating things once you have named a part with double data. It's one of the features I'm planning for somewhat in future, by the way. Without this, I would have to instrument Module Manager itself so he would raise an exception when such part is detected - but this would need to inject more knowledge on MM than it really needs to work, and a already complex piece of software would had it's already huge surface of attack for bugs even wider without not direct benefit for its core business Dismembering the patch support will drastically reduce that surface of attack to manageable levels, as the majority of the users will not be exposed to more patches than they need. This appears to be the biggest lesson we can take from your reports. That technical reason I mentioned is due the way ConfigNode handles "arrays". When you add an array to a ConfigNode, you have a ordered (but not necessarily sequential) collection of data with the same name. You need to use a specific call to get all the values under that name, and if you use the call for singleton values you get the last value. But I'm used to see code that uses the "array version" of the call and then getting the first value (I wonder if by similar reasons). This last scenario would break beautifully if I edit an value that people are used to get duplicated and selecting the first one, and then people start to get the value from the later adders instead of the expected value added by the first one! And since by the ASCII ordering TweakScale tends to be the last guy on the chain, it also tends to be prevalent on that scenario - i.e., any guy that have a disagreement with TweakScale on something and is used to get the first value will get suddenly "wrong values" came from nowhere. So… It will accomplish very few, can potentially break expected behaviour (wrong behaviour, but a expected one nevertheless - remember when I said that a bad standard is better then no standard at all?) and the rogue patches will still be there. And the real problem are the rogue patches. On 2/28/2019 at 1:45 AM, AccidentalDisassembly said: Also - some patches have superfluous definitions, e.g. the engine plate's TS patch defines incrementSlide and scaleFactors, but does not need to because those are already defined by its scaletype (unless some custom increments are being used which I didn't catch). Patches getting old without proper supervision. The dismembering will help on this too. On 2/28/2019 at 6:40 PM, Barzon Kerman said: @Lisias how do I make Tweakscale configs? I want to make them for @DylanSemrau's WIP Provenance Aerospace? You need to understand a bit about Module Manager patches first. A TweakScale config is nothing more than a patch. Unless you are considering support TweakScale directly, and then TweakScale would be a hard dependency for your parts. If this is the case, I would suggest you to rethink this. Not everybody wants to use TweakScale - this could limit your audience. In my humble opinion, the best approach is to write MM patches for your Add'On and include them on the release, and tell MM to ignore such patches when TweakScale is not installed (see the :NEEDS clausule). On 2/28/2019 at 10:03 PM, Tyko said: what app are you opening them in? I use Notepad++ and they are fully formatted... Or give a peek on the github directly, and make use of the auto-formatting features of the site. https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/Examples.cfg https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/documentation.txt @Tyko - some text editors are using proportional fonts as default nowadays, messing up beautifully the visualization of the good, old and faithful text files. It's one of the reasons I, by default, use TABs and not spaces on my projects - my colleagues can set up the TAB width in pixels as they want, and (almost) everybody end up happy. — — — POST EDIT — — — I reproduced the problem described above (with a screenshot). Things are a bit hairy, by the way. This is the grep for my KSP.log looking to EnginePlate4 (the internal name for the EP 50): $ cat KSP.log | grep "EnginePlate4" [LOG 00:31:43.977] Config(PART) SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4 [LOG 00:31:44.020] Config(@PART[EnginePlate4]) TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] [LOG 00:31:51.727] [ModuleManager] INFO: Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] to SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/PART [LOG 00:32:32.018] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' [LOG 00:32:32.048] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' has no database record. Creating. [LOG 00:32:32.055] DragCubeSystem: Creating drag cubes for part 'EnginePlate4' [WRN 00:33:17.429] [TweakScale] Removing TweakScale support for EnginePlate4. [ERR 00:33:17.429] [TweakScale] Part EnginePlate4 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13. This confirms my thesis de the MM is not on the guilty list for this problem. I used MM3 by the way, to prevent any worries due the new parallelized patching routines. On the MM cache I found this: UrlConfig { name = EnginePlate4 type = PART parentUrl = SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4 PART { name = EnginePlate4 module = Part author = RoverDude rescaleFactor = 1 node_stack_top = 0,0.4,0,0,1,0,4 node_stack_bottom = 0,0,0,0,-1,0,4,0,0,1,0 breakingForce = 2500 breakingTorque = 2500 fx_gasBurst_white = 0.0, 0.0650517, 0.0, 0.0, 1.0, 0.0, decouple sound_vent_large = decouple TechRequired = metaMaterials entryCost = 3000 cost = 300 category = Coupling subcategory = 0 title = EP-50 Engine Plate [ CUT -- CUT -- CUT -- CUT -- ] MODULE { name = TweakScale type = stack defaultScale = 5.0 scaleFactors = 0.1, 0.3, 0.625, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 20 incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2 TWEAKSCALEEXPONENTS { mass = 2 } TWEAKSCALEEXPONENTS { name = TweakScale DryCost = 0.5 } } } } Well. we have a problem: a duplicated TWEAKSCALEEXPOENTS thingy. This is fixed on the development branch, and was identified by @Tonka Crash here. The hairy situation is that TweakScale 4.1.0 is detecting the EnginePlate4 as an unsupported part, and then it's withdrawing itself from the prefab. However, the thingy somehow survived to tell the history on the GUI. Twice, as we can see. The double slider appears to be due the double TWEAKSCALEEXPOENTS , but frankly, the while shebang should had been deleted from the prefab by now. Need some time to figure my way out of this. The good news is that a new maintenance release for TweakScale is on the works to have this solved. The bad news is that EnginePlate, as any Part using MODULEVARIANTPART with Mass on the variants, is not supported and the patch will be withdrawn on startup. I'm sorry for this, but this part is one of the probably causes for the KSP crashes due improperly mangled mass. Edited March 20, 2019 by Lisias tasting my own medicine :) Quote Link to comment Share on other sites More sharing options...
KOCMOHABT Posted March 1, 2019 Share Posted March 1, 2019 (edited) Screenshots: https://yadi.sk/i/Eq4nm3kxYDotxQ https://yadi.sk/i/xptH_iSw5ktRhg https://yadi.sk/i/jcOpJt-HoxPmow My question is, why did this happen? Why the smaller engine makes bigger jet stream? Played on 4 different versions of the game with different versions of the mod, every time there is a graphic illogical nonsense. Is it possible to fix this graphical issue? As for me, this is the main reason why I want to abandon your beautiful mod. But I use it. Translated with the help of translator (rus -> en). Edited March 1, 2019 by KOCMOHABT my mistakes Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 1, 2019 Share Posted March 1, 2019 Hey guys, so I've had a couple of people ask me to make a mod that I'm working on TweakScale compatible. So I went ahead and wrote up a Module Manager patch, but I can't get it to work. I've asked a few other modders and they can't quite seem to be able to find what's going wrong. I know Tweakscale works because I added a module into the part cfg to test it out. If someone could help me out that'd be great! Here's the code that I've written up @PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted March 1, 2019 Share Posted March 1, 2019 I'm pretty sure that if you're adding a module you do not need the % in front of it Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 1, 2019 Share Posted March 1, 2019 8 minutes ago, linuxgurugamer said: I'm pretty sure that if you're adding a module you do not need the % in front of it Removed the % and it didn't change anything Would it be helpful if i shared a github link? Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted March 1, 2019 Share Posted March 1, 2019 (edited) 3 minutes ago, DylanSemrau said: Removed the % and it didn't change anything Would it be helpful if i shared a github link? Being able to see everything is always helpful Not sure if you know about these links: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax Edited March 1, 2019 by linuxgurugamer Quote Link to comment Share on other sites More sharing options...
Barzon Posted March 1, 2019 Share Posted March 1, 2019 Here you go: https://github.com/DylanSemrau/Provenance-Aerospace Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 (edited) 8 hours ago, KOCMOHABT said: My question is, why did this happen? Why the smaller engine makes bigger jet stream? Nice catch. I totally missed this feature, the effects are being scaled backwards! It's consistent, I tested with NERV as you, but also with Reliant and with Terrier. The glitch is less visible on some engines, but it's clearly there! I can't give you a deadline to have this fixed, as I have some more pressuring issues to solve (as to support stock parts at all). But I will tackle this down as soon as I get rid of that pressuring thingies. https://github.com/net-lisias-ksp/TweakScale/issues/27 Edited March 1, 2019 by Lisias uh… some really bad grammars. X-( Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted March 1, 2019 Share Posted March 1, 2019 This is what I think you need: @PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] { MODULE { name = TweakScale type = stack defaultScale = 3.75 } } Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 1, 2019 Share Posted March 1, 2019 (edited) 2 minutes ago, linuxgurugamer said: Being able to see everything is always helpful https://github.com/DylanSemrau/Provenance-Aerospace/tree/Tweakscale-Testing @Barzon Kerman No no no that's the wrong one Edited March 1, 2019 by DylanSemrau Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 16 minutes ago, DylanSemrau said: Hey guys, so I've had a couple of people ask me to make a mod that I'm working on TweakScale compatible. So I went ahead and wrote up a Module Manager patch, but I can't get it to work. I've asked a few other modders and they can't quite seem to be able to find what's going wrong. I know Tweakscale works because I added a module into the part cfg to test it out. If someone could help me out that'd be great! Here's the code that I've written up @PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } Are you using a MODULEVARIANTPART with mass? Please publish your KSP.log so I can give a peek! Quote Link to comment Share on other sites More sharing options...
Barzon Posted March 1, 2019 Share Posted March 1, 2019 Testing @linuxgurugamer's patch. It didn't work. This is my edited copy of the tweakscale compatibility cfg: @PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] { MODULE { name = TweakScale type = stack defaultScale = 3.75 } } @PART[engine] // First Stage Engine Cluster { MODULE { name = TweakScale type = stack defaultScale = 3.75 } } Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 (edited) 14 minutes ago, Barzon Kerman said: Testing @linuxgurugamer's patch. MM is not applying your patches. acmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance" Provenance Aerospace [LOG 19:27:54.280] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal [LOG 19:27:54.401] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture [LOG 19:27:54.494] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal [LOG 19:27:54.571] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture [LOG 19:28:29.814] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model [LOG 19:28:33.852] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model [LOG 19:28:56.347] Config(@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] [LOG 19:28:56.347] Config(@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale] [LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster [LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank Added : Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale.cfg Added : Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster.cfg Added : Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank.cfg ProvenanceAerospace [LOG 19:29:05.221] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass [LOG 19:29:05.221] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass [LOG 19:29:05.221] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass [LOG 19:29:05.222] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 19:29:05.223] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 19:29:05.675] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' [LOG 19:29:05.839] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' has no database record. Creating. [LOG 19:29:05.972] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' [LOG 19:29:05.988] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' has no database record. Creating. Look how it applies the PartInfo patch, but remains silent about TweakScale. (I'm testing the HEAD from the repository you pinpointed). — — — — — POST EDIT — — — — — Are you sure you named the part correctly on the patch? I'm not finding a part with that name on the GameData… macmini:Provenance Aerospace lisias$ find . -name "*.cfg" -exec grep "First_Stage_Fuel_Tank" {} \; @PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] The command above should had returned at least a second occurrence of the "First_Stage_Fuel_Tank" string from the basket of cfg files that it's GameData! — — — — POST POST EDIT — — — — HERE. You forgot to put "_" on the partname. PART { name = First Stage Fuel Tank Edited March 1, 2019 by Lisias post edit Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 1, 2019 Share Posted March 1, 2019 2 minutes ago, Lisias said: MM is not applying your patches. acmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance" Provenance Aerospace [LOG 19:27:54.280] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal [LOG 19:27:54.401] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture [LOG 19:27:54.494] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal [LOG 19:27:54.571] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture [LOG 19:28:29.814] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model [LOG 19:28:33.852] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model [LOG 19:28:56.347] Config(@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] [LOG 19:28:56.347] Config(@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale] [LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster [LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank Added : Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale.cfg Added : Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster.cfg Added : Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank.cfg ProvenanceAerospace [LOG 19:29:05.221] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass [LOG 19:29:05.221] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass [LOG 19:29:05.221] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass [LOG 19:29:05.222] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 19:29:05.223] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 19:29:05.675] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' [LOG 19:29:05.839] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' has no database record. Creating. [LOG 19:29:05.972] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' [LOG 19:29:05.988] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' has no database record. Creating. Look how it applies the PartInfo patch, but remains silent about TweakScale. (I'm testing the HEAD from the repository you pinpointed). So does this give any indication to what the issue might be? Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 2 minutes ago, DylanSemrau said: So does this give any indication to what the issue might be? We posted at the same time! Check the name of the part on the CFG file, you forgot the "_" there. Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 1, 2019 Share Posted March 1, 2019 4 minutes ago, Lisias said: We posted at the same time! Check the name of the part on the CFG file, you forgot the "_" there. Well now the part doesn't even show up in ksp anymore It's the same name as the folder the cfg is in so I'm not sure why there's an issue there Quote Link to comment Share on other sites More sharing options...
Barzon Posted March 1, 2019 Share Posted March 1, 2019 (edited) Does this look any better: @PART[First Stage Fuel Tank]:NEEDS[TweakScale] { MODULE { name = TweakScale type = stack defaultScale = 3.75 } } @PART[engine] // First Stage Engine Cluster { MODULE { name = TweakScale type = stack defaultScale = 3.75 } } I've been adding the changes talked about here. Edited March 1, 2019 by Barzon Kerman Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 27 minutes ago, DylanSemrau said: Well now the part doesn't even show up in ksp anymore It's the same name as the folder the cfg is in so I'm not sure why there's an issue there Humm… Unexpected. Well, there must be a reason for the stock parts names not using "_'. So I edited your CFG files and got rid of "_" and " ", ie, named the parts as FirstStageEngineCluster and FirstStageFuelTank on all configs/patches. That made some difference: macmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance" Provenance Aerospace [LOG 20:27:27.931] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal [LOG 20:27:28.070] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture [LOG 20:27:28.229] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal [LOG 20:27:28.321] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture [LOG 20:28:03.507] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model [LOG 20:28:07.625] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model [LOG 20:28:29.208] Config(@PART[FirstStageFuelTank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] [LOG 20:28:29.208] Config(@PART[FirstStageEngineCluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageEngineCluster]:NEEDS[TweakScale] [LOG 20:28:29.208] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster [LOG 20:28:29.208] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank ProvenanceAerospace [LOG 20:28:29.940] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 20:28:29.940] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageEngineCluster]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 20:28:37.626] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass [LOG 20:28:37.626] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass [LOG 20:28:37.626] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass [LOG 20:28:37.627] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 20:28:37.627] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 20:28:38.069] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster' [LOG 20:28:38.216] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster' has no database record. Creating. [LOG 20:28:38.323] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' [LOG 20:28:38.335] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' has no database record. Creating. But… TweakScale is not being applied yet. =/ Well, I have some ideas, I will be back to this post soon. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 1, 2019 Author Share Posted March 1, 2019 (edited) On 2/18/2019 at 2:36 PM, Tonka Crash said: I thought about including this above, but skipped it as it's really a different discussion. I ran into a patch ordering problem with Simple Fuel Switch a couple weeks ago and learned all about patch order directives. TweakScale would have to use :FOR[TweakScale] on every one of it's patches to allow the :BEFORE or :AFTER directives to function as intended. Tonka, I found some docs on MM about exactly this, and the problem is… Damn, @DylanSemrau's patches should be working by now: Quote The stuff within the needs section is based on either: A plugin .dll with the same assembly name. A subdirectory name under GameData. (Names with spaces can be used, just remove the spaces: GameData/My Mod/ => :NEEDS[MyMod] A FOR[Blah] defined would allow NEEDS[Blah] Source: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax TweakScale fails the first criteria, as the DLL is named "Scale.dll". But it should had been caught by the second criteria, as the there is a directory called "TweakScale" on the GameData. On the bright side, I will apply the FOR clausule on TweakScale this weekend, and then release (another) minor revision with the latests fixes until the moment. I think we finally are nailing why things are getting hairy with TweakScale lately. I wanna to dig in some code, however, before telling anything more about the issue. — — — POST EDIT — — — Boy, this is going to be a hell of a weekend! Near 1900 patches to apply that !#$#@$@#%@$% FOR. macmini:patches lisias$ find -name "*.cfg" -exec grep -H "@PART" {} \; | wc -l 1892 If I understood correctly, TweakScale is being caught by the "LegacyPassSpecifier" , that always returns "true" on the check. In order to be correctly ordered on the :AFTER , :BEFORE and (I'm not sure yet) :NEEDS , I need to apply that :FOR stunt on everything that "it's mine". Edited March 2, 2019 by Lisias post edit Quote Link to comment Share on other sites More sharing options...
Barzon Posted March 1, 2019 Share Posted March 1, 2019 (edited) With lots of little changes, I actually got Tweakscale working on the tank. Nevermind. now its not working at all. Edited March 2, 2019 by Barzon Kerman Quote Link to comment Share on other sites More sharing options...
KOCMOHABT Posted March 1, 2019 Share Posted March 1, 2019 1 hour ago, Lisias said: Nice catch. I totally missed this feature, the effects are being scaled backwards! It's consistent, I tested with NERV as you, but also with Reliant and with Terrier. The glitch is less visible on some engines, but it's clearly there! I can't give you a deadline to have this fixed, as I have some more pressuring issues to solve (as to support stock parts at all). But I will tackle this down as soon as I get rid of that pressuring thingies. https://github.com/net-lisias-ksp/TweakScale/issues/27 Screenshot: https://yadi.sk/i/u5T6Utj5WPcohg I think that this is wrong too. The width of the trace of such particles, though changing, but the length remains unchanged. 1) It is illogical. 2)It looks terrible. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 2, 2019 Author Share Posted March 2, 2019 (edited) 32 minutes ago, Barzon Kerman said: With lots of little changes, I actually got Tweakscale working on the tank. Nevermind. now its not working at all. Interesting. Now, using names without "_" neither " " I managed to make MM apply the TweakScale patch: macmini:1.6.1 lisias$ cat KSP.log | grep -i "FirstStageFuelTank" [LOG 21:03:06.688] Config(@PART[FirstStageFuelTank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] [LOG 21:03:06.688] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank [LOG 21:03:07.529] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 21:03:16.354] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' [WRN 21:03:16.358] [ShipConstruct for FirstStageFuelTank]: part cost (6400.0) is less than the cost of its resources (21103.2) [LOG 21:03:16.369] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' has no database record. Creating. [LOG 21:03:16.370] DragCubeSystem: Creating drag cubes for part 'FirstStageFuelTank' However, the scaling slider is not being shown on the part's menu yet. So, yeah, we have TWO cascading errors! (sigh). I just checked the MM cache, and the TweakScale MODULE section is there as expected. Now I'm trying to nail down this second problem. It's like TweakScale withdrawing support for parts (i.e., deleting the MODULE section for TweakScale from the prefab by code), but this part is not eligible for the withdrawn I had coded (and I do not do things without logging, and there's no log on the KSP.log for this part, while there're some for some others). I will compile a special DLL of TweakScale to further investigate this issue, @DylanSemrau . The first step is to, indeed, get rid of "_" and " " on the part names. This fixed a problem, as now the logs are showing TweakScale patches being applied to your parts. What we are facing now is another issue. Edited March 2, 2019 by Lisias some comments added Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 2, 2019 Share Posted March 2, 2019 @LisiasOh boy this is interesting. Thanks for helping out man, I appreciate it Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 2, 2019 Author Share Posted March 2, 2019 (edited) 13 hours ago, DylanSemrau said: @LisiasOh boy this is interesting. Thanks for helping out man, I appreciate it Well.. That's what I have to the moment: By removing "_" and " " from the part name (both on the config, and from the patch), I managed to make MM to apply the TweakScale patches. Evidence on the spoiler below. But the damn thing still doesn't works as expected. TweakScale is on the prefab at loading, but no slider are being shown and once you save a .craft with these parts, no TweakScale section is present on them. So, it's like the patches were not applied (but they were, the MM cache below confirms that). Until the moment, I have three theories: something on TweakScale is withdrawing silently the support for these two parts. Unlikely, but not impossible - there's some code there that I didn't proper reviewed yet. something else is doing that post dorsum . something somewhere else is preventing that specific module to be loaded from the prefab once the part is instantiated on the editor. I will pursue the 1st thesis by Sunday - tomorrow (Saturday) my block will be have the power cut for power lines maintenance and I don't have the slightest clue about how much time I will be offline. The 2nd and 3rd thesis will be a hairy and dirty job of guessing and trying in the hope to hit something. I think there're one "easy" test that you can do in the mean time. Since getting rid of spaces (and '_') solved the previous issue, perhaps it can solve this one too. How about getting rid of all spaces on the file and directory names? I tried to do that myself, but some filenames are hardcoded somewhere and things just don't work by brute-forcing my way on it. I will call it a day now. I'm up since early morning, time to get some sleep. Spoiler UrlConfig { name = FirstStageEngineCluster type = PART parentUrl = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster PART { name = FirstStageEngineCluster module = Part author = Dylan Semrau rescaleFactor = 1.0 node_stack_top = 0.0, 2.01521, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -2.97, 0.0, 0.0, -1.0, 0.0, 2 node_attach = 0.0, 1.08738, 0.0, 0.0, 1.0, 0.0, 2 attachRules = 1,1,1,1,0 fx_exhaustFlame_blue = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running fx_exhaustLight_blue = 0.0, -2.2, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_light = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_flameout = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, flameout sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout TechRequired = heavierRocketry entryCost = 9200 cost = 2300 category = Engine subcategory = 0 title = BE-4 Engine Cluster manufacturer = Blue Origin description = None mass = 8.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 7 breakingForce = 150 breakingTorque = 150 maxTemp = 2000 fuelCrossFeed = True bulkheadProfiles = size1, srf tags = new glenn first stage be-4 provenance aerospace MODEL { model = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model } MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 4500 heatProduction = 175 fxOffset = 0, 0, 0.1 EngineType = LiquidFuel exhaustDamageDistanceOffset = 0.35 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 330 key = 1 265 key = 9 0.001 } } MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 5 } MODULE { name = ModuleSurfaceFX thrustProviderModuleIndex = 0 fxMax = 0.8 maxDistance = 50 falloff = 2 thrustTransformName = thrustTransform } MODULE[TweakScale] { type = stack defaultScale = 3.75 } MODULE { name = ModulePartInfo } } } Edited March 2, 2019 by Lisias really need some sleep! =P Quote Link to comment Share on other sites More sharing options...
DylanSemrau Posted March 2, 2019 Share Posted March 2, 2019 3 minutes ago, Lisias said: Well.. That's what I have to the moment: By removing "_" and " " from the part name (both on the config, and from the patch), I managed to make MM to apply the TweakScale patches. Evidence on the spoiler below. But the damn thing still doesn't works as expected. TweakScale is on the prefab at loading, but no slider are being shown and once you save a .craft with these parts, no TweakScale section is present on them. So, it's like the patches were not applied (but they were, the MM cache below confirms that). Until the moment, I have two theories: something on TweakScale is withdrawing silently the support for these two parts. Unlikely, but not impossible - there's some code there that I didn't proper reviewed yet. something somewhere else is preventing that specific module to be loaded from the prefab once the part is instantiated on the editor. I will pursue the 1st thesis by sunday - tomorrow, saturday, my block will be have the power cut for power lines maintenance and I don't have the slightest clue about how much time I will be offline. The 2nd thesis will be a hairy and dirty job of guessing and trying in the hope to hit something. I think there're one "easy" test that you can do in the mean time. Since getting rid of spaces (and '_') solved the previous issue, perhaps it can solve this one too. How about getting rid of all spaces on the file and directory names? I tried to do that myself, but some filenames are hardcoded somewhere and things just don't work by brute-forcing my way on it. I will call it a day now. I'm up since early morning, time to get some sleep. Reveal hidden contents UrlConfig { name = FirstStageEngineCluster type = PART parentUrl = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster PART { name = FirstStageEngineCluster module = Part author = Dylan Semrau rescaleFactor = 1.0 node_stack_top = 0.0, 2.01521, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -2.97, 0.0, 0.0, -1.0, 0.0, 2 node_attach = 0.0, 1.08738, 0.0, 0.0, 1.0, 0.0, 2 attachRules = 1,1,1,1,0 fx_exhaustFlame_blue = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running fx_exhaustLight_blue = 0.0, -2.2, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_light = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_flameout = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, flameout sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout TechRequired = heavierRocketry entryCost = 9200 cost = 2300 category = Engine subcategory = 0 title = BE-4 Engine Cluster manufacturer = Blue Origin description = None mass = 8.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 7 breakingForce = 150 breakingTorque = 150 maxTemp = 2000 fuelCrossFeed = True bulkheadProfiles = size1, srf tags = new glenn first stage be-4 provenance aerospace MODEL { model = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model } MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 4500 heatProduction = 175 fxOffset = 0, 0, 0.1 EngineType = LiquidFuel exhaustDamageDistanceOffset = 0.35 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 330 key = 1 265 key = 9 0.001 } } MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 5 } MODULE { name = ModuleSurfaceFX thrustProviderModuleIndex = 0 fxMax = 0.8 maxDistance = 50 falloff = 2 thrustTransformName = thrustTransform } MODULE[TweakScale] { type = stack defaultScale = 3.75 } MODULE { name = ModulePartInfo } } } Okay cool, thanks again! Hopefully one of your theories are correct and the issue can be resolved Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.