Jump to content

[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

Lisias

By Lisias
in KSP1 Mod Releases

 Share

Recommended Posts

kcs123

kcs123

Posted
Posted
5 hours ago, Carni35 said:

Hi !

I have no idea about the amount of work needed for make a mod compatibility with tweakscale ^^

So I just wondering if there is any chance to have ''Tantares'' compatibility with this great mod ?

Maybe this post from few pages back can answer your question:

Maintaining TS at current state already take too much time, so support for any other mod have to be included trough that mod. In your case it should be done on "Tantares" side. Things are still messy due to improper implementation of TS patches from various mod authors. Plenty of issues are already discovered and solved, but it will take some time until each rogue patch is ironed out.

Hopefully, any new mod TS support will follow guidelines how to write TS patches, so such issues will be avoided in future.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
1 hour ago, kcs123 said:

Maybe this post from few pages back can answer your question:

Maintaining TS at current state already take too much time, so support for any other mod have to be included trough that mod. In your case it should be done on "Tantares" side. 

Yep! That should be the ideal solution.

But not all Add'On authors would want to keep TweakScale patches themselves. So an alternative solution is an Add'On those solely function is to add TS patches to Tantares. With the patches stable later, Tantares' maintainer can decide to adopt them as default on the Distribution.

Making History patches for TweakScale apparently was born this way, and later incorporated into TweakScale. It's not a bad idea, not at all. We just need to do better job on synchronising efforts on the merge, so we don't stomp on each other toes later.

On the MH patches, instead of deleting the source Add'On, I would issue a new release, empty, with the newest TweakScale version (with the patches) as hard dependency. This would make the transition smoother for CKAN users. ;)

Edited by Lisias
Kraken damned Autocompletes
Link to comment
Share on other sites
DarkNounours

DarkNounours

Posted
Posted (edited)
14 hours ago, Lisias said:

Yep! That should be the ideal solution.

But not all Add'On authors would want to keep TweakScale patches themselves. So an alternative solution is an Add'On those solely function is to add TS patches to Tantares. With the patches stable later, Tantares' maintainer can decide to adopt them as default on the Distribution.

Making History patches for TweakScale apparently was born this way, and later incorporated into TweakScale. It's not a bad idea, not at all. We just need to do better job on synchronising efforts on the merge, so we don't stomp on each other toes later.

On the MH patches, instead of deleting the source Add'On, I would issue a new release, empty, with the newest TweakScale version (with the patches) as hard dependency. This would make the transition smoother for CKAN users. ;)

Assuming someone made TS config files for a mod which is not supported at the moment, what would be the right way to include them ? Give them to you so that you could add them to TS or include them in the target mod itself ?

EDIT : information already given.

Edited by DarkNounours
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
On 11/27/2019 at 4:26 AM, rocket_scissors said:

There is a problem with TweakScale but I don't know what it is. Could anyone help me?

Got it. 

[LOG 17:50:01.838] [TweakScale] INFO: WriteDryCost: Started
[LOG 17:51:16.772] [TweakScale] INFO: WriteDryCost Concluded : 1528 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 1 Show Stoppers found; 9 Sanity Check failed; 855 unscalable parts.

No big deal, just one FATALity: 

[LOG 17:51:16.461] [TweakScale] ERROR: **FATAL** Part pp.vvmach (Plume Party Vapor Vent Mach) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

But this is a new one! Let's improve our TweakScale knowledge base a bit! :) 

[LOG 17:40:24.198] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:24.201] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:28.101] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:28.102] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:28.103] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:28.104] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:51.786] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:51.786] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:51.793] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:40:51.793] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:03.758] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:03.758] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:03.767] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:03.767] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:04.615] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:04.617] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:04.662] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 17:41:04.663] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]

Well.. This is a new. There're many patches being applied to pp_vvmach, every one of them twice! This is a new one, indeed!

Looking into the KSP.log, I realized that there are more than one copy of PlumeParty on your installment!

  • [LOG 17:40:14.583] KSP-AVC -> D:\Steam Games\steamapps\common\Kerbal Space Program\GameData\PlumeParty\Version\PlumeParty.version
  • [LOG 17:40:14.583] KSP-AVC -> D:\Steam Games\steamapps\common\Kerbal Space Program\GameData\Shuttle Orbiter Construction Kit\PlumeParty\Version\PlumeParty.version

I'm pretty sure you copied the Folder on Shuttle Orbiter Construction by accident. Delete it, it will no only fix your issue but probably prevent some others that TweakScale doesn't knows about! :)

Cheers!

"install safe!" ;)

Edited by Lisias
Kraken damned Autocompletes
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
On 12/6/2019 at 12:46 AM, The-Doctor said:

Is the robotic parts completely unable to be scaled or is it a wip feature? Scaling them would be really useful for making centrifuges on ships

It's a long time WiP feature. On the current Beta for TS 2.5 , I made the Helicopter Blades to be scalable, but besides it had worked fine on 1.7 , on 1.8 it didn't behaved as good as it did.

You can give it a shot here.

Please try this stunt on a disposable Game installment, as the patches are still Alpha and can be change at not notice - what would ruin your current savegames. This new version also have working scalable Wheels.

As soon as I get my new rig to work (damn, Apple! You make life a misery for no reason!), I will add also a (optional) patch to automatically apply a new Behaviour to Resource Converters that will make them scale resource consumption as well (currently, only production are being scaled) - this last one is not "default" yet (you need to manually apply a Behaviour on your parts) because savegames already using scalable Resource Converters would break using it, as suddenly your Resource Converter will stop working due lack of input resources (as it will scale the consumption now, and then the current design will not be enough anymore!).

Edited by Lisias
kinda of tyops.
Link to comment
Share on other sites
DarkNounours

DarkNounours

Posted
Posted (edited)

Hi guys. Sorry to ask this because I have not read the 50 pages of this thread but are there special recommendations or best practice advises to build a cfg file for Tweakscale ?

I made this file for Restockplus (which still need to be extensively tested and verified if someone wants to play with it please use a disposable KSP installation) and was told that using %variables was better but I have not enough knowledge to understand the advise.

Edited by DarkNounours
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
On 12/14/2019 at 8:11 AM, DarkNounours said:

Hi guys. Sorry to ask this because I have not read the 50 pages of this thread but are there special recommendations or best practice advises to build a cfg file for Tweakscale ?

Yes.

http://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch , I had posted it here too but… Couldn't find it easily on the Search. :(

My bits of advise:

  • Don't use "type" without "%", unless you use ":FOR" - ie, only the owner of the Add'On should define what's cannon for his Add'On.
  • Corollary: you need to use :FOR[<your-addon-name>].
  • You :NEED to use :NEEDS. :) to prevent shoving unneeded data on the GameDatabase. Choose where you think makes more sense on your design
    • %MODULE[TweakScale]:NEEDS[TweakScale]
    • @PART[restock-leg-2-rigid]:NEEDS[TweakScale] // Medium Rigid Legs

Keep in mind that this is my opinion about how a patch should be made. :) 

 

On 12/14/2019 at 8:11 AM, DarkNounours said:

I made this file for Restockplus (which still need to be extensively tested and verified if someone wants to play with it please use a disposable KSP installation) and was told that using %variables was better but I have not enough knowledge to understand the advise.

The "%" is a command that says "create or edit a thingy with this name". On your patches, you are already using %MODULE[TweakScale] command, that says "Get me the Module with name TweakScale, or give me a new empty one is none is found".

The "@", on the other hand, says "edit a thingy with this name, or ignore this whole section if none if found". So, on the PART section, if the guy has not any part with the name on the brackets, the whole patch section is plain ignored - what makes sense, no need to shove data for parts that doesn't exists.

You can't use "@" on the TweakScale module, however, as surely there's no TweakScale module for this part (otherwise, you would not be writing the patch), so you need the "%" thingy. By using no command in the front of the thing, you are stating "create this thing and that's final" - something that should be done with caution, because if someone else had added that thing before you, you would be adding a new entry for the data and things can go very badly from now on (or not, it dependes of the Module - on TweakScale, it's plain terrible when this happens!).

However, there're one situation where not using "%" can be helpful - when you are the owner of the thing you are patching. Doing that, if anyone else makes a mistake while patching your part, it's slightly less hard to detect the problem. It also makes easy to detect when your Add'On is double installed on the GameData (relying on the module to check this helps, but doesn't solves the problem for Add'Ons that don't add new modules to the game).

Link to comment
Share on other sites
DarkNounours

DarkNounours

Posted
Posted (edited)

Well as IMHO nobody has made such a patch for Restockplus the final goal is that the file be integrated to your mod or Restockplus with the program to generate it. 

On a sense it is designed to be the one official. 

If nobody wants it not a problem as I am already my own customer. 

Let me a while to look at your materials and to understand how it works under the hood. 

Edited by DarkNounours
spelling
Link to comment
Share on other sites
DarkNounours

DarkNounours

Posted
Posted (edited)
18 hours ago, Lisias said:

Yes.

http://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch , I had posted it here too but… Couldn't find it easily on the Search. :(

My bits of advise:

  • Don't use "type" without "%", unless you use ":FOR" - ie, only the owner of the Add'On should define what's cannon for his Add'On.
  • Corollary: you need to use :FOR[<your-addon-name>].
  • You :NEED to use :NEEDS. :) to prevent shoving unneeded data on the GameDatabase. Choose where you think makes more sense on your design
    • %MODULE[TweakScale]:NEEDS[TweakScale]
    • @PART[restock-leg-2-rigid]:NEEDS[TweakScale] // Medium Rigid Legs

Keep in mind that this is my opinion about how a patch should be made. :) 

 

The "%" is a command that says "create or edit a thingy with this name". On your patches, you are already using %MODULE[TweakScale] command, that says "Get me the Module with name TweakScale, or give me a new empty one is none is found".

The "@", on the other hand, says "edit a thingy with this name, or ignore this whole section if none if found". So, on the PART section, if the guy has not any part with the name on the brackets, the whole patch section is plain ignored - what makes sense, no need to shove data for parts that doesn't exists.

You can't use "@" on the TweakScale module, however, as surely there's no TweakScale module for this part (otherwise, you would not be writing the patch), so you need the "%" thingy. By using no command in the front of the thing, you are stating "create this thing and that's final" - something that should be done with caution, because if someone else had added that thing before you, you would be adding a new entry for the data and things can go very badly from now on (or not, it dependes of the Module - on TweakScale, it's plain terrible when this happens!).

However, there're one situation where not using "%" can be helpful - when you are the owner of the thing you are patching. Doing that, if anyone else makes a mistake while patching your part, it's slightly less hard to detect the problem. It also makes easy to detect when your Add'On is double installed on the GameData (relying on the module to check this helps, but doesn't solves the problem for Add'Ons that don't add new modules to the game).

Thank you very much for the information and the guidance provided :)

There is still something I have not understood yet: the behavior thing such as 

#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
  • What # and / do for the empty block {} ?
  • What are the different behaviors ? I made a find/grep search in the whole mod (cfg files and .cs) and I found Science, SRB, Engine, Decoupler. 

Have a good day and may the kraken remains asleep all day long :D

Edited by DarkNounours
grammar
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
10 hours ago, DarkNounours said:

There is still something I have not understood yet: the behavior thing such as 


#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
  • What # and / do for the empty block {} ?
  • What are the different behaviors ? I made a find/grep search in the whole mod (cfg files and .cs) and I found Science, SRB, Engine, Decoupler. 

A Behaviour is a way to create "scaling receipts" for some parts, usually when you need to handle a module differently from what was defined on the Exponent.

It's kind a "macro" - every time you use this stunt, you insert a lot of scaling commands on the part without having to type it yourself. Exponents are the same, but are automatic - you don't have to explicit "call them", as you have to do with Behaviours.

These two stunts are what make so easy to add support for a new part (as long such part use them!), all you have to do is to set up the %type and the %scale , as the rest of the needed information is automatically injected by a Exponent - or explicitly injected using a Behaviour when the Exponent doesn't fits.

 

10 hours ago, DarkNounours said:

Have a good day and may the kraken remains asleep all day long :D

I think I waked one when I farted…. :D

Spoiler

https://youtu.be/q0Cjo1MWGZg

 

Edited by Lisias
typos! Surprised? :P
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted

Hi, guys.

The moratory is over (thanks Krakens!). I'm not on vacancy, however, I'm still working - but on a way slow pace. :)

So, back to business: I found a misbehaviour on TweakScale - if you scale a root part, half the subtree is displaced on the Y axis proportionally to the scale. I just found this on KSP 1.7.3, I will be grateful if anyone could confirm this problem on others KSPs too (so I would not need to do it myself! :) ). I'm specially interested on knowing if this is something that was always there, or if it's something that was introduced recently.

Link to the ticket: https://github.com/net-lisias-ksp/TweakScale/issues/86

(and, yeah, the new machine is way better for KSP!! It took me only one month to be able to put it to work!!! :sticktongue:)

Link to comment
Share on other sites
DarkNounours

DarkNounours

Posted
Posted

Hi Lisias.

I have one question about this sentence in the "How-to-write-a-patch" tutorial.

Quote

On the past, some of these patches were included into the TweakScale Standard Distribution - but nowadays, I'm trying to avoid the practice, as it adds to TweakScale the burden of maintaining these patches. It's better to move them to independent "Plugins" to the TweakScale distribution.

Which patches are currently in this situation ?

-----

New release of the patch :

https://github.com/xot1643/TS-Restockplus/blob/master/config/Restockplus_Tweakscale.cfg

 

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
2 hours ago, DarkNounours said:

Which patches are currently in this situation ?

Right now (details on the Deprecated Folder), this is the current Status Quo:

As I find maintainers willing to keep the patches him/herself on the Add'On ("There can be only one!"), or Add"Ons became unavailable for some reason, I will move my patches to the Deprecated.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
33 minutes ago, zer0Kerbal said:

https://spacedock.info/mod/940/Large Structural Components Redux ?

Weird... The thing is there again.

I don't remember when I added that remarks, but I would not had typed that I had found the page for downloading! The URL was there because I detect and register the URL the Forum Post pinpoints, even when I get a 404 on it.

Well... In a way or another, it's not M.I.A anymore. But yet, it's a SA-ND license (no derivatives), so without the maintainer around I can propose fixes neither fix it myself, so the patch is a liability to the mainstream. Is will stays on the Deprecated, so.

-- -- POST EDIT -- -- 

From the patch:

Quote

// A Redux release was released, but it's unrelated to this one.
// https://forum.kerbalspaceprogram.com/index.php?/topic/147354-*
// https://spacedock.info/mod/940/Large Structural Components Redux

:D

I should read my own notes before answering things about my notes!!! :sticktongue:

Edited by Lisias
post edit
Link to comment
Share on other sites
DarkNounours

DarkNounours

Posted
Posted
On 12/21/2019 at 1:06 AM, Lisias said:

Right now (details on the Deprecated Folder), this is the current Status Quo:

As I find maintainers willing to keep the patches him/herself on the Add'On ("There can be only one!"), or Add"Ons became unavailable for some reason, I will move my patches to the Deprecated.

So the idea would be that such a patch should become its own mod ? Correct me if I misunderstood you.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
4 hours ago, DarkNounours said:

So the idea would be that such a patch should become its own mod ? Correct me if I misunderstood you.

Should? Not. Can? Yes.

It doesn't needs to be internalised by the Add'On being patched (as I did with KAX), an "Add'On in the Middle" is also a good idea - an Add-On maintained outside TweakScale, being hard dependent from TweakScale and the Add'On being patched.

For example, the Near Future *** patches will be moved to an Add'On called "TweakScale Near Future *** Support" (maintained by me, at least initially) on TweakScale 2.5 (or a bit later, depends on how I push some needed changes first).

So, that "TweakScale NF*` netkan will state TweakScale and NF *** as hard dependency.

The thing I'm still working on is how to make this transparent to the CKAN user: I can't just move out a patch to a "Companion Pack" without breaking users that would not be aware of the move. Moving the patches to the patched Add'On (as I did with KAX) is seamless on CKAN, the next update will have all sorted out automatically, mainly if doing the way I did on KAX, making sure it's patched after TweakScale and deleting the "old" patches before applying the new ones, then on a next TweakScale version that patches "vanishes" and then would be nothing to be deleted, but the new official patches would be still there.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted

Hi, guys.

I unfortunately found a silly mistake that can play some havoc if not fixed, but also play havoc by not being fixed. At leat one part had the Default Scale wrongly set, and this is incredible annoying while using. However, fixing it will break existing parts.

Spoiler

71559737-a6076f00-2a40-11ea-8221-d23292e

Issue #87.

Since this part is the Mk3 Engine Mount, I expect some grief while fixing this. But by not fixing it, I also expect infinite annoyances to users wondering why in hell the part is note being scaled as its counterparts - not to mention third-party add'ons that should handle exceptions from the rule ("all mk3 parts scales this way, except adapterEngines, that should be scale by this different factor") - so, yeah, I plan to fix it.

This dong broke my legs on the Road Map. I had planned to finish this troublesome 2.4.3 series on the 2.4.3.10 Release, but now I'm working again on a new legacy problem that can cause nuisances to some users. Not to mention that, well, I will revise every single stock part again in order to issue this new pain on you guys only once.

However, I still have a long time needed change to be applied, the use of ":FOR[TweakScale]" on the Standard Patches, that also would break some legacy. Breaking legacy is a trend I'm definitively working hard to avoid unless absolutely needed. But at least these one are utterly needed.

So, now, I'm reworking the RoadMap. I'm checking all my (known) technical debts and trying to figure out the least expensive (for me) and painful (for the users) way to push them through the door. Kerbal-X is an absolutely marvellous tool to support me on this, as i can help to to estimate the potential damage of the fixes by checking how many crafts there are using the affected part.

So I ask for some patience as I work out these issues, and please help me to detect all the current misconfigurations still lingering on the system by checking Issue #87 and advising there any mistake you find.

Cheers, and Scale Safe! :)

Link to comment
Share on other sites
kcs123

kcs123

Posted
Posted

Well, that is unpleasant, but sooner or later it will be necessary to bite a bullet and do necessary changes. IMHO, better to do this sooner than later and dedicate free time to more fun parts of development. Just anounce when breaking changes will happen, so players can remove affected crafts from career saved game playtrough.

Or maybe to create procedure how to edit savegame files and hopefully fix crafts with broken parts. If it is even possible, of course.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...