[WIP] TweakScale - Development Thread

[emerald]

On 4.4.2016 at 2:06 AM, emerald said:

https://github.com/emerald79/TweakScale

Some adaptions for KSP 1.1, TweakScale dll seems to work, not sure about the required changes for non freescale scaling (node scaling), since KSPAPIExt is no longer.

Adaptions for KSP build 1209 done. No warranty.

[Enceos]

Hi @pellinor, a lil idea popped into my mind. I was stuffing a probe with science experiments when I realized that scaling down the science parts reduced the cost of the probe significantly. Is it possible to produce a reverse behavior for the cost scaling in science parts? Smaller part - expensive, bigger - cheaper.

Edited April 16, 2016 by Enceos

[pellinor]

On 16.4.2016 at 5:17 PM, Enceos said:

Hi @pellinor, a lil idea popped into my mind. I was stuffing a probe with science experiments when I realized that scaling down the science parts reduced the cost of the probe significantly. Is it possible to produce a reverse behavior for the cost scaling in science parts? Smaller part - expensive, bigger - cheaper.

I already have a half done commit for this lying around, and some doubts that a general solution does not exist. For the materials bay it seems reasonable (my plan is to make mass invariant and cost decreases with size). On the other hand, something like a thermometer (which fortunately is not scalable) should not get significantly cheaper because the mass and size are negligible.

[Enceos]

8 hours ago, pellinor said:

I already have a half done commit for this lying around, and some doubts that a general solution does not exist. For the materials bay it seems reasonable (my plan is to make mass invariant and cost decreases with size). On the other hand, something like a thermometer (which fortunately is not scalable) should not get significantly cheaper because the mass and size are negligible.

There are many science mods which would benefit from this type of scaling. I scale down the science parts to reduce mass as well and to make myprobes look as tiny as possible, like in real life. Making the mass stay would mean bigger fuel tanks for these tiny probes, and they won't be tiny anymore.

But I still feel like I'm cheating when a science part which costs 60k becomes worth only 5k after scaling down. I would be glad to pay 150-200k for such technological miniaturization of the part. I hope I'm not the only person which finds dissatisfaction in this.

Edited April 18, 2016 by Enceos

[pellinor]

13 hours ago, Enceos said:

There are many science mods which would benefit from this type of scaling. I scale down the science parts to reduce mass as well and to make myprobes look as tiny as possible, like in real life. Making the mass stay would mean bigger fuel tanks for these tiny probes, and they won't be tiny anymore.

But I still feel like I'm cheating when a science part which costs 60k becomes worth only 5k after scaling down. I would be glad to pay 150-200k for such technological miniaturization of the part. I hope I'm not the only person which finds dissatisfaction in this.

Yes, constant mass is somewhat fishy, might also run into physics problems when densities vary too much. Another big point for just changing the cost side is that physical properties are preserved, so the change will not break crafts. This is a good way for a minimal change that at least makes things less broken than they are now.

Next question: which parts and which exponent? We are looking for parts with a size-independent gameplay value, that's more or less science and probe cores. Cost exponent should be zero or less, shall we go with -1 for now?

Edited April 18, 2016 by pellinor

[emerald]

I thought about this too, for science parts a realistic change would be something like

default: cost = x

sized up from default: cost = x * 1.5 ^ (mass_resized/mass_default), (or x * 2.5^((mass_res/mass_def) - 1))

size down: cost = x * 2.5 ^ ((mass_default / mass_resized) - 1)

That would be some realistic, scale up some more expensive, scale down alot more expensive.

[Enceos]

@pellinor In the past I ran into an issue when scaling down probe cores with Remote Tech present. The probe would not have enough electricity in itself to spin up which resulted in "No connection" even with batteries present. So I stopped scaling the probe cores. I'd be glad to test out the config, if you give me one, on all the science parts I have (stock, DMagic science parts, Surface Experiment pack and several others). And I can assemble a list of science parts from various packs for the config patch.

@emerald I don't think scaling the science part up should increase the cost. The increased weight itself is already punishing enough.

Edited April 18, 2016 by Enceos

[pellinor]

3 minutes ago, emerald said:

I thought about this too, for science parts a realistic change would be something like

default: cost = x

sized up from default: cost = x * 1.5 ^ (mass_resized/mass_default), (or x * 2.5^((mass_res/mass_def) - 1))

size down: cost = x * 2.5 ^ ((mass_default / mass_resized) - 1)

That would be some realistic, scale up some more expensive, scale down alot more expensive.

So scaling up would give you a part with the same abilities, just larger, heavier and a lot more expensive? Then why would you ever build such a thing?

I think different configs for up- and downscaling would add too much complexity for the benefit it brings. Actually I consider it as quite a good measure of balance that both up- and downscaled parts should have some use in the game. It is also a good safeguard against the very common habit of "just balance my usecase and punish everything else".

17 minutes ago, Enceos said:

@pellinor In the past I ran into an issue when scaling down probe cores with Remote Tech present. The probe would not have enough electricity in itself to spin up which resulted in "No connection" even with batteries present. So I stopped scaling the probe cores. I'd be glad to test out the config, if you give me one, on all the science parts I have (stock, DMagic science parts, Surface Experiment pack and several others).

This sounds like a problem with remote tech. But might also be a general KSP problem with tiny resource nodes. My thought is just that this is a good time to also make probe cores a bit less broken.

[emerald]

Ok, scaling up is rare, scaling down not as much, put like a whole storage bay full of experiments, and all cheap, it's a bit too easy. And large stuff ('little brother surveillance cam') simply scale down so a tiny satellite is enough defeats the purpose of it being large in the first place

[pellinor]

3 minutes ago, emerald said:

Ok, scaling up is rare, scaling down not as much, put like a whole storage bay full of experiments, and all cheap, it's a bit too easy. And large stuff ('little brother surveillance cam') simply scale down so a tiny satellite is enough defeats the purpose of it being large in the first place

We do agree about that part, shrinking science stuff should be expensive.

[pellinor]

Dev update: basic recompile for KSP 1.1

Just did a quick test on windows and simple scaling seems to work. Still struggling to get KSP running stably on my dev system (linux).

[pellinor]

Dev update:
* new stock parts'
* new TWEAKSCALEBEHAVIOR[Science] which contains a mass exponent of 2 and a cost exponent of -1. I'm still considering making the cost -2.

 

Bad news of the day: the root part bug is still there. With so much changed there is some hope that a new way of coding around it might present itself. If anyone with a bit of unity knowledge would like to help I'd be grateful.

[pellinor]

Dev update:
* Workaround for the camera breaking (don't try to scale the model of the root part on revert/load since this will fail anyway)

The distinction between launch from revert/load is a bit hacky (vessel=null on launch), but it works for now.
We are getting closer to a release.

Edit: I'm still pretty stuck with the root part issue, collecting ideas in the github issue:
https://github.com/pellinor0/TweakScale/issues/3

Edited April 22, 2016 by pellinor

[Nhawks17]

Might be a long shot but have you tried poking squad about the camera and root part issue? Considering the bug tracker is being looked at adamantly given the 1.1 release, I wonder if they'd be able to look into it? Maybe possibly who knows?

[Enceos]

Maybe @taniwha can help with this... since he's familiar with the KSP code in depth.

[pellinor]

I also poked NathanKell on github since he fixed the rescaleFactor, which had the exact same problem.

There has been an issue on the tracker for more than a year. Since they generally don't update that tracker I can't even tell if it is considered a bug, or has been looked at at all. I'll add a new one for the root part refusing to scale, since that is technically a separate issue from the camera breaking.

Edit: new issue http://bugs.kerbalspaceprogram.com/issues/9444. As an issue that can be avoided this has priority low, we will see if it gets any attention.

Edited April 23, 2016 by pellinor

[pellinor]

Release v2.2.7.1
(same as the last dev update)

Things that might need testing:
* Wheels and Legs
* the inflateable heatshield
  ("procedural drag cubes" sounds like things could go wrong)
* everything: are there any new properties that need scaling, or old ones that broke?

[drtedastro]

Procedural drag cubes??????

What could POSSIBLY go wrong..

 

Cool, need to check this out quick.

many thanks for update and all of the work.

Cheers.

[FizzerUK]

Awesome stuff....  All the good mods being updated for 1.1

Having sooooo much fun modding the hell outta this update.

[drtedastro]

hello to all.

When i change / tweakscale items such as fuel tanks, the size changes per normal but the volume is not changing.

I have tested to make sure that it is not just a label error, tried burn times on two tanks one normal size and other tweaked. both burn for same time.

I am running ksp 1.1 full package (not steam early one)

Win64 version of ksp.

 

thanks and let me know if logs will help or what else i can test.

Cheers.

[pellinor]

Dev update:
* get "model" transform by name instead of assuming that it is the first. This should fix the root part bug.

[drtedastro]

just checking in.

I have tested latest 'dev' build of tweakscale on new, min modded kps 1.1 64bit installation and still not getting any updated fuel amounts.

craft mass is changing, but not the volume / amount of goodies in the tanks.

man, am i missing something here?

Cheers, and thanks for any and all help / info / advise.

[pellinor]

7 hours ago, drtedastro said:

I have tested latest 'dev' build of tweakscale on new, min modded kps 1.1 64bit installation and still not getting any updated fuel amounts.

Thanks for reporting. What I can reproduce is that scaling a part does not update the right click menu. Once I launch the vessel or attach another part, the values are right. So there is probably some 'shipModified' event missing in the editor. I'll have a look.

Edit: looks like the event is there, the tweakables are just not updating like they did in 1.0.5.

And there is a future issue that we now have two more stock tweakables for float values. Scaling their limits won't work out of the box, we'll need some extra code for that.

Edited April 24, 2016 by pellinor

[drtedastro]

Thanks.

I will go back and double check from my end.

I 'thought' that I had tested for that, but must have not done it correct.  Not enough coffee and bacon yet.

Most important, thanks for all of your great work for the mods.

Cheers.

 

[pellinor]

I made a few issues on github for the current to do list, and will try to keep them up to date:
https://github.com/pellinor0/TweakScale/issues