Jump to content

[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.7.5 - 2024-0213


Lisias

Recommended Posts

As from 2018-1016 and under @pellinor agreement, I'm the New Management for TweakScale. From now on, it's all officially my fault! :D 

In a Hurry:

Spoiler

Description:

TweakScale lets you change the size of a part. Not just that, but it will figure out how much fuel is in the resized part. And if it's an engine, it will become more powerful by scaling it bigger, or weaker by scaling it smaller.

(Pictures are eternal work in progress! :) )

Credits:

Contributions From:

And future new features/bugs/mishaps from yours truly.

Support:

I need help in order to proper help you. :) Open the spoiler for instructions about how to get support:

Spoiler

Please provide:

  • A concise, textual description of the problem
    • Mentioning the KSP version and the TweakScale version involved
  • A screenshot of the problem
  • When applicable, the .craft file with a vessel that have the problem
  • When asked, the KSP.log and output_txt log from Unity.
    • See this article for instructions.
    • The Player.log changed location:
      • On MacOS
        • For KSP < 1.8, they are on ~/Library/Logs/Unity
        • On KSP >=1.8, you will find the Player.log on ~/Library/Logs/Squad/KSP/
      • On Windows
        • On KSP >=1.8, you will find the Player.log on C:\Users\<USERNAME>\AppData\LocalLow\Squad\KSP\
      • On Linux
        • On KSP >=1.8, you will find the Player.log on ~/.config/unity3d/Squad/KSP/
    • Publish the files on DropBox, Google Drive or similar, and post the link so we can inspect it.
      • DO NOT paste the log on Forum, this causes a lot of problems and it's useless, as Forum also truncate the file
        • It's ok to paste small excerpts to pinpoint something, but we still need the full KSP.log and Player.log in order to help you/
      • Do not use pastebin, gist or similars. They have a pretty small cap on the file size, and will truncate the log rendering yet more useless
    • Imgur is a good choice for publishing screenshots when needed.

Using the Issue Tracker is highly encouraged, as GitHub provides services that make everything above easier. You can open an issue there, and call me here pinpointing there to be sure to get my attention.

Thank you.

Scale Safe! :sticktongue:

Edited by Lisias
2.4.7.5 is on the wild. All your Distribution Channels are belong to us!
Link to comment
Share on other sites

First Post! (ok, it's unfair) :P 

In the next few days, a proper TweakScale release will be issued. The current "unofficial" of mine, by being… unofficial… , it's full of crazy ideas that still need to be proven. Eventually some of them will be merged into the 'mainstream', but until there, I'll keep the official releases the more orthodoxically as possible.

Welcome aboard. Fasten your seat belts and sit tight. :) 

Link to comment
Share on other sites

Just now, Lisias said:

You also have the feeling that pellinor is way too happy? :D 

Oh maybe. Maybe not. Depends on how much maintenance Tweakscale needs. I'm guessing not a huge amount.

Link to comment
Share on other sites

1 minute ago, GDJ said:

Oh maybe. Maybe not. Depends on how much maintenance Tweakscale needs. I'm guessing not a huge amount.

There're new attributes on KSP 1.5 (on the gears, for example) that will need to be handled or stuff will be blown into orbit against your will.

I think (but I still need to correctly study the problem) that some issues on 1.4 are due the same. The first step, probably, is to read cautiously every KSP's Change Log from 1.3.1 to 1.5.

Link to comment
Share on other sites

42 minutes ago, Lisias said:

There're new attributes on KSP 1.5 (on the gears, for example) that will need to be handled or stuff will be blown into orbit against your will.

I think (but I still need to correctly study the problem) that some issues on 1.4 are due the same. The first step, probably, is to read cautiously every KSP's Change Log from 1.3.1 to 1.5.

The only think I can add to the fix pile (sorry about this) is the strength of the parts when they are "blown up" to around 180% of original size or more. The mass increases predictably, but I find that certain parts can get destroyed easily or they peel off the craft under their own mass (ie wings). It gets worse if there is fuel in the mix (even more mass).

Link to comment
Share on other sites

15 hours ago, Lisias said:

First Post! (ok, it's unfair) :P 

In the next few days, a proper TweakScale release will be issued. The current "unofficial" of mine, by being… unofficial… , it's full of crazy ideas that still need to be proven. Eventually some of them will be merged into the 'mainstream', but until there, I'll keep the official releases the more orthodoxically as possible.

Welcome aboard. Fasten your seat belts and sit tight. :) 

Good to hear Tweakscale is in good hands. For a time I considered taking over myself as I had several ideas to improve it. but my hands are already more than full

But about ideas, I have several:

A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry.

B: Another big limitation of tweakscale is that is by default only always only one method of define is scaling growth which is a single exponent. Although this works reasonably well for scaling up, when scaling down it often resulted in ridiculous numbers. Therefore instead, I would like the ability to use float curves that allow we to define exactly how parameters should grow or shrink.

Edited by FreeThinker
Link to comment
Share on other sites

1 hour ago, FreeThinker said:

A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry. 

This is possible today by putting the "TechRequired" field in the part-specific config, which overrides the one on the scaletype. Yes, doing this for hundreds of parts is probably not the most elegant solution. And there is currently no transparency in-game when things will unlock.

Link to comment
Share on other sites

12 minutes ago, pellinor said:

This is possible today by putting the "TechRequired" field in the part-specific config, which overrides the one on the scaletype. Yes, doing this for hundreds of parts is probably not the most elegant solution. And there is currently no transparency in-game when things will unlock.

I don't think I was clear enough. I mend that a part cannot be tweakscaled to a specific after both the Tweakscale TechRequired and part TechRequired are BOTH unlocked. Currently the Tweakscale  TechRequired overrides the part TechRequired

Link to comment
Share on other sites

Just to clarify some things:

There're TWO development branches on the repository: the orthodox and the heterodox. All bug fixes and "safe" development are done on the orthodox, and this branch is the only one that can be promoted to master now and then.

The heterodox branch is where we can play with nitroglycerine without killing the neighbours. We can discuss and even implement some ideas on there just to see what happens - the worst it can happens is to ditch the code. This branch will be never merged back to the orthodox one. If the event an idea proves valid and worths the potential migraine of becoming mainstream, the changes will be cherry-picked and eyeballed prior being committed into the production safe branch.

On the other hand, every change on the orthodox is merged to heterodox, so it keeps synchronized with the status quo. This broke something on heterodox? Too bad: fix it or ditch it. I didn't mentioned Dante's Inferno just because. :D 

So… Yeah.We can go wild on new ideas and even try an implementation on the heterodox branch without opening the gates of hell into us.

Note to myself: Implement a very scary warning to be issued every time you enter Space Center on the heterodox branch.

Edited by Lisias
tyops, as usulla.
Link to comment
Share on other sites

2 hours ago, FreeThinker said:

I don't think I was clear enough. I mend that a part cannot be tweakscaled to a specific after both the Tweakscale TechRequired and part TechRequired are BOTH unlocked. Currently the Tweakscale  TechRequired overrides the part TechRequired

Ok then I was not clear enough. Most TweakScale config values can appear in two places: the scaletype or the part module. The code will first look in the config of the part module, any values found there will win over those in the scaletype (I'm talking about this part of the code). So if you put something like "techRequired = tech1,tech2,tech3" in the TweakScale module of a specific part, the requirements should only apply to the scaleFactors of that specific part. So my statement is that the current interface allows to specify a separate tech for any scale of any part, which is the finest granularity possible.

Or maybe the missing piece is that techRequired is not a single value but a list, mapping a tech to every scaleFactor?

Link to comment
Share on other sites

9 minutes ago, pellinor said:

. So if you put something like "techRequired = tech1,tech2,tech3" in the TweakScale module of a specific part, the requirements should only apply to the scaleFactors of that specific part. So my statement is that the current interface allows to specify a separate tech for any scale of any part, which is the finest granularity possible.

Yes I know, but its not a lack of granularity , but a lack ability to combine. Let me illustrate with a little example

PART
{
	name = AdvancedFuelTank
	module = Part

	TechRequired = specializedFuelStorage


	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 2.5
		scaleFactors =  0.625 1.25, 2.5
		techRequired = heavyRocketry,heavierRocketry, veryHeavyRocketry
	}

}

 

Now currently the AdvancedFuelTank will get unlocked  with heavyRocketry, what I want is that you require BOTH at least specializedFuelStorage and heavyRocketry to use this fuel tank.

Link to comment
Share on other sites

1 hour ago, FreeThinker said:

Now currently the AdvancedFuelTank will get unlocked  with heavyRocketry, what I want is that you require BOTH at least specializedFuelStorage and heavyRocketry to use this fuel tank. 

Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

Link to comment
Share on other sites

10 minutes ago, pellinor said:

Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

Yes, that would be even better. It would allow use to balance tweakscale much better. Tweakscale is often shunned because it gives access to higher sizes too fast, well with the discussed improvement we can balanc it better by using the higher technodes like veryHeavyRocketry, giganticRocketry and colossalRocketry, which is now not used

Edited by FreeThinker
Link to comment
Share on other sites

So Random question, The mod is posted on CKAN as well.  Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. 
I ask because I tend to check for updates out of CKAN and not the forums themselves. (i found out about new management out of fluke TBH lol) unless the mod in question isnt listed on CKAN in the first place. 
 

Link to comment
Share on other sites

5 hours ago, Trollsama said:

So Random question, The mod is posted on CKAN as well.  Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. 
I ask because I tend to check for updates out of CKAN and not the forums themselves. (i found out about new management out of fluke TBH lol) unless the mod in question isnt listed on CKAN in the first place. 
 

Well that sound be to hard. Its just a matter of changing the download reference to the new spacedock location where the new releases are hosted

Edited by FreeThinker
Link to comment
Share on other sites

8 hours ago, Trollsama said:

 Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. 

I'm not an enthusiastic user of CKAN, mainly because the Mono defaults are a mess on Linux and Mac, and I'm a heavy user of these OS'es. I was also bitten heavily when a bunch of mods were automatically updated, but one of them caused undesired behaviour and it took me an awful amount of time to figure out what happened. Doing things by hand revealed to be a better solution for me, with me relying on KSP-AVC to keep me informed about updates.

That said, I will not drop CKAN support on Releases, but pre-releases (the present state) and experimental will not be CKAN'd (neither published on SpaceDock and Curseforge) for obvious reasons. 

Edited by Lisias
Link to comment
Share on other sites

13 hours ago, pellinor said:

Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

Meddling with Module Manager and Hide Empty Tech Nodes, I understand how they handle customized Tech Trees. On the fly, in the case of HETN.

The same technique appears to be applicable on parts list - obviously, this info is to be confirmed.

However...  There're risks on such endeavor. I found that it's currently common practice to "hijack" the TechTree unconditionally, what ends up in a race condition where the TechTree currently in use is determined by the not necessarily deterministic order in which such "hijacks" happen. I'm foreseeing the same happening here. 

I think we will need an Arbitrator for customs Parts List. I think we already need one for TechTrees...

Link to comment
Share on other sites

 

6 hours ago, Lisias said:
12 hours ago, mattinoz said:

Is there a more advanced version of Tweakscale that allows scaling independently in one direction?

Almost a purely aesthetic thing that parts that transition between to sizes often feels to short blend nicely with the next part.

Curiously, I thought on something like that recently. But I consider this to be "tricky" to implement as it would break an (programming) interface that are in use for years. OK, there're techniques to make things coexist, but we need to balance cost and benefits of such a feature.

The "easier" changes on the programming interface would render the user interface less intuitive, and vice versa.

(quoting this from the old TweakScale thread)

The scaling part is quite simple and has been done before (for example the DIY Kits in GC). Some other questions are

* Many parts in TweakScale assume the scaling has one degree of freedom, for example the config interface (scaleFactors, exponents, techRequired), the API for other mods. Is it clear how they should behave once a part can be scaled with two or three degrees of freedom? What additional config possibilities does this need?

* Will the resulting config interface still be usable for the average modder?

* How many parts benefit from non-isotropic scaling? This is the main point why I haven't done this yet. Most models just look bad when stretched.

Edit: for simple cases like visually stretching an adapter, it could also be a separate part module that lacks all the interaction with other part modules.

Edited by pellinor
Link to comment
Share on other sites

5 hours ago, Lisias said:

That said, I will not drop CKAN support on Releases, but pre-releases (the present state) and experimental will not be CKAN'd (neither published on SpaceDock and Curseforge) for obvious reasons. 

My experience is that CKAN hasn't caused trouble for TweakScale yet. It targets inexperienced users and should only see the stable releases.

I found it quite useful for the initial installation, but also prefer to update things manually and selectively.

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.

×
×
  • Create New...