Jump to content

[1.4.x] TweakScale v2.3.12(Apr-16)


pellinor

Recommended Posts

I'm fiddling with a added scaletype, where I try to put tech restrictions on the heatshields, but I'm currently getting arrayoutofindex error.

@PART[HeatShield1]:FINAL

{

@MODULE[TweakScale]

{

@type = stack_square_techRestricted

}

}

SCALETYPE

{

name = stack_square_techRestricted

freeScale = true

defaultScale = 1.25

suffix = m

scaleFactors = 1.25, 2.5

techRequired = surviveability, enhancedSurvivability

// scaleFactors = 0.1, 0.3, 0.625, 1.25, 2.5, 3.75, 5.0, 7.5, 10, 20

// incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2

// techRequired = precisionEngineering, miniaturization, engineering101, surviveability, generalConstruction, enhancedSurvivability, advConstruction, advSurvivability, spesializedConstruction, advMetalworks

TWEAKSCALEEXPONENTS { mass = 2 }

}

Is this the right way to go about it, cause I cant seem to find any other examples or tweaks for limiting tweakscale in career mode. Would be great to get rid of some extra parts by doing this as well ;P

EDIT - seems I misspelled the first tech, should be "survivability" :P but if someone has a tip for career mode I'll listen, cause adding my own configs for every type seems like unnecessary much work :)

Edited by Vandreren
Link to comment
Share on other sites

This doesn't work for me. I've installed it, didn't work

Uninstalled and Installed it again, cause the Game to crash

Uninstalled and Installed it again - game loads but there is apparently no sign of tweakscale. If I right click on the item no scale bar is appearing

Help?

No idea what you are seeing. If tweakScale does nothing the most common error would be a missing moduleManager.dll in the gameData folder.

Link to comment
Share on other sites

I'm wondering, does it work if you:

- have a craft with tweakscaled parts in one save

- see that a new version of KSP has been released

- transfer the persistence file from the old version to the new one

- transfer the TweakScale GameData folder or download a new version of TweakScale

or does the mod break and you have the parts back to their default sizes?

Edited by Pipcard
Link to comment
Share on other sites

So I see the problem I'm having (parts reverting to normal size) is a known bug

For some clarification does this only happen on the root part? How about parts attached to the root part?

If it follows such rules I guess it's easy to avoid.

I've noticed that radially attached parachutes seem especially prone to it!

Link to comment
Share on other sites

I'm wondering, does it work if you:

- have a craft with tweakscaled parts in one save

- see that a new version of KSP has been released

- transfer the persistence file from the old version to the new one

- transfer the TweakScale GameData folder or download a new version of TweakScale

or does the mod break and you have the parts back to their default sizes?

If KSP does not break saves TweakScale should be fine.

- - - Updated - - -

So I see the problem I'm having (parts reverting to normal size) is a known bug

For some clarification does this only happen on the root part? How about parts attached to the root part?

If it follows such rules I guess it's easy to avoid.

I've noticed that radially attached parachutes seem especially prone to it!

The known bug only applies to the root part. I haven't reproduced anything special about parachutes. Note that the same bug happens in stock for parts with rescaleFactor != 1 (for example the MKS containers), also only for the root part on load/revert but not on launch.

- - - Updated - - -

Hey, I added the large and small radiators to the SQUAD patch. (not the deployable ones) Should I expect any unusual behavior out of them? Currently, they're of type free_square.

If the radiator function is done with a new part module it might need new scale exponents. Haven't really looked at for new part modules yet.

Link to comment
Share on other sites

You can't change crew capacities, that will break the internals.

You can, actually. Sort of. What I usually do is replace the part's IVA in the config file with the stock "Placeholder" IVA, which doesn't seem to have a set number of seats. You can also try one of the bigger IVAs, but those all have a set maximum.

- - - Updated - - -

What's wrong with it? Nertea probably does not use TweakScale with these panels, otherwise he'd already have complained.

EDIT: ah, didn't read the posts before, will have to check the part names.

- - - Updated - - -

Parts only scale if they are explicitely supported by a patch in one of the .cfg files that come with TweakScale (or with the part mod). I'll have a look at those panels, maybe some part names changed.

I hope I don't sound flippant by suggesting this, but instead of explicitly defining each part to apply tweakscale to, wouldn't it be easier to do some of it based on the modules the parts contain? Like, with solar panels, they're always radially attached, so you don't have to worry about picking which scale set to use. So (and forgive me for not knowing the proper way to format this) could you use a module manager config that says something along the lines of:

Do Last

For Part [*]

Contains Module [DeployableSolarPanel]

Add Module [Tweakscale]

Unless it has Module [Tweakscale]

And then insert the scale variables after that like:

%module=tweakscale

%Type=free

Wouldn't that save you some work having to update each time a new mod came out? Sorry again, I know I didn't do the formatting right. I'm on my phone so I don't have an example to look at.

Link to comment
Share on other sites

I hope I don't sound flippant by suggesting this, but instead of explicitly defining each part to apply tweakscale to, wouldn't it be easier to do some of it based on the modules the parts contain? Like, with solar panels, they're always radially attached, so you don't have to worry about picking which scale set to use. So (and forgive me for not knowing the proper way to format this) could you use a module manager config that says something along the lines of:

Do Last

For Part [*]

Contains Module [DeployableSolarPanel]

Add Module [Tweakscale]

Unless it has Module [Tweakscale]

And then insert the scale variables after that

Wouldn't that save you some work having to update each time a new mod came out?

The patches have their current form mainly because I inherited them like this, so I'm open to change there. My main point against wildcard patches is complexity. The sum of all moduleManager patches forms a piece of software that is

* hard to debug/diagnose

* different for each KSP install (depends on mods, player can add custom patches)

* scattered across GameData

So if something is wrong, it usually is hard to tell what exactly MM did, and where to find the code of the involved patches. To make modders' and players' life easier I tend to keep patches as explicit and readable as possible. Also, mods should not use the 'FINAL' time, because others might want to act later (e.g. balancing mods removing TweakScale patches).

PS: Just as a remark about "they're always radially attached": there are curved solar panels which use stack sizes, and there might also be a mod with foldable panels in a stacked package. Of course the solution would be to support those with explicit patches, but this illustrates how easy it is to hard-code assumptions that do not hold for all other mods.

- - - Updated - - -

Hello

I use tweak scale in 1.0.2. and when when I scale any stock fuel tanks, weights and fuel quantity do not change.

Is it a bug?

Sounds like a problem in your install. You can scale things, so the mod seems working. The effects of scaling are described in ScaleExponents.cfg, do you have this file? Maybe other mods that overwrite stuff? Fuel quantity should change instantly, the displayed weight may be bugged in the stock editor display (KER/Mechjeb should show the right weight). Any exceptions in the log?

Edited by pellinor
Link to comment
Share on other sites

I think what *could* (not saying should here) happen with respect to not having to write TS patches for every part is this:

1. Define one or two global scaletypes that will apply to all parts, make it go from (say) 0.25x size to 4x size. Or whatever.

2. Apply it to @PART

[*] (or do engines vs. other parts separately, depending)

3. Everything is now tweakscalable with one very, very simple config, but you lose some of the functionality of how things work now:

- Right now, patching parts individually means parts can be scaled between the same minimum and maximum actual sizes - like 0.625m (or whatever) minimum, 5m max, and the scale shown on the tweakable corresponds to the actual size of the part in meters too (for stack stuff).

- If you change it to a blanket scaletype, parts would be scaled between min and max relative sizes, so parts that are actually larger to begin with can now be scaled to humongous sizes, which may or may not be what you want.

- Result: Tiny parts can also be scaled down to absolutely minuscule sizes (like 0.15m for 0.625m parts in my example) as well, which is a bit weird. In short, you get a lot of weird size options now, but if everything's freescale, you can also move the slider to get the exact multiple you want.

4. One way around that might be to do a somewhat less simple config that reads cross-sectional size (if that's defined in part configs somewhere??), maybe... And somehow magically try to cover all the cases where someone didn't bother to define that, or for surface parts that don't have it at all.

5. Individual configs could still be written for particular parts requiring special mass exponents or whatever.

So long as the config is fairly straightforward (one kind of scaletype for engines, one for everything else), it would actually save quite a lot of work and be not that hard to debug.

BUT, as pellinor says, when you start trying to do something fancy - sorting parts by resources, size, modules, whatever - all in one config.. or if a user writes a config and doesn't know the difference between @MODULE and MODULE in an MM config (or some such)... I could see it getting hairy.

Just thinking out loud.

Edited by AccidentalDisassembly
Link to comment
Share on other sites

Sounds like a problem in your install. You can scale things, so the mod seems working. The effects of scaling are described in ScaleExponents.cfg, do you have this file? Maybe other mods that overwrite stuff? Fuel quantity should change instantly, the displayed weight may be bugged in the stock editor display (KER/Mechjeb should show the right weight). Any exceptions in the log?

Hello Pelinor, thank you for answer

I am still playing 1.0.2 du to heat bug trouble between F.A.R and stock on 1.0.4

I made an install on 1.0.4 by copying my 1.0.2 game data folder in 1.0.4 and making update for all folder that got a 1.0.4 update.

So my 2 game data folders are similar in 1.0.2 and 1.0.4 with many folders updated in KSP 1.0.4

Tweak scale appears in both log in both game data folders. I can't see any exceptions in each log, but i am not a specialist

ScaleExponents.cfg is present in both folders

I tried to play KSP 1.0.2 with tweakscale for 1.0.2 and also with updated folder for 1.0.4

Results are that:

Tweak scale works perfectly in KSP 1.0.4

Does not work (Tweakscale version 1.0.2 or 1.0.4) in KSP 1.0.2

Link to comment
Share on other sites

hey, excuse me if it was mentioned before, but the search function in this Forum is crap.... even didnt find this thread by looking for "tweakscale".

anyway:

Problem: it seems the AGU Grabbing unit does not grab anymore when upscaled.

i tried with 2.5m and 5m on an astroid - no Chance.

editing quicksave and resized it back to 1.25 (no changes but this) => works

so - is it a known error? Can it be fixed?

Link to comment
Share on other sites

is there a mod that can be used with tweakscale, to give more info on the stats of a part after tweakscale changes them?

i'm trying to write custom configs for some parts, and i'm the type that would like to see every number that is effected :)

i've tried saving craft, launching/savegame, to view files and see what gets edited

right click menu shows resources, you can watch cost of vessel and with work get the change

but i cant find a way to see the rest, heatconduction, emmisives, tolerances, maxtemp, etc

if there is no mod or other way to see, perhaps add a partmodule that would list full stats in vab on rightclick?

Link to comment
Share on other sites

so I tried scaling a part which contains ISRU which in turn generates heat (and throttles down ISRU converter when said part approaches 95% of 1/2 its maxTemp). Got 800% (or 6400% if scaling further) efficiency reading, and almost instant overheat.

Link to comment
Share on other sites

hey, excuse me if it was mentioned before, but the search function in this Forum is crap.... even didnt find this thread by looking for "tweakscale".

anyway:

Problem: it seems the AGU Grabbing unit does not grab anymore when upscaled.

i tried with 2.5m and 5m on an astroid - no Chance.

editing quicksave and resized it back to 1.25 (no changes but this) => works

so - is it a known error? Can it be fixed?


MODULE
{
name = ModuleGrappleNode
nodeTransformName = ArticulatedCap
deployAnimationController = 1
nodeType = size1
captureRange = 0.05
captureMinFwdDot = 0.866
captureMaxRvel = 1
}

There are no exponents for the grappling module, maybe scaling the captureRange will fix it. Anyone willing to test? No Idea what captureMinFwdDot does. nodeType looks like it should be scaled but would not work with the current system (because it uses hardcoded strings instead of a number).

- - - Updated - - -

so I tried scaling a part which contains ISRU which in turn generates heat (and throttles down ISRU converter when said part approaches 95% of 1/2 its maxTemp). Got 800% (or 6400% if scaling further) efficiency reading, and almost instant overheat.

I'm not playing KSP at the moment, so I'm not too familiar with the latest mechanics, and won't get much done during the summer. There might be an axponent missing. The stock ISRU hast a value generatesHeat=false, so the converter heat mechanics are probably not tested at all. For the engines there is a heat generation value that got an exponent, maybe the converter also has such a value (that is not set in the stick part). Generally, if an enlarged converter scales to 8x the power and 4x the surface area, I'd expect it to be more prone to overheating.

Link to comment
Share on other sites

is there a mod that can be used with tweakscale, to give more info on the stats of a part after tweakscale changes them?

i'm trying to write custom configs for some parts, and i'm the type that would like to see every number that is effected :)

i've tried saving craft, launching/savegame, to view files and see what gets edited

right click menu shows resources, you can watch cost of vessel and with work get the change

but i cant find a way to see the rest, heatconduction, emmisives, tolerances, maxtemp, etc

if there is no mod or other way to see, perhaps add a partmodule that would list full stats in vab on rightclick?

Sounds useful, and clearly out of scope for TweakScale. If you're interested in writing such a module there would surely be some demand for it.

- - - Updated - - -

can't nodeType be scaled as an enum? if so, then something similar can be done with docking ports I think

The idea behind an enum is to contain states like red/green/blue, and this is clearly how docking ports are intended. The assumption that red= 2*green = 4*blue only applies to the stock parts. For the mechanics they could just as well be "round" and "square".

For node size it depends how it is handled internally. Keeping a list of strings for a specific exponent would conflict pretty heavily with the way TweakScale works today.

Link to comment
Share on other sites

so it would only be useful up to the number of strings provided for it? is this a problem with current functionality or the scope of the mod's vision? because just having a list of strings that has the max size capped at 15m wouldn't be that bad because eventually the sizes are going to extend out of the VAB or hangar and just be unusable

Link to comment
Share on other sites

BUG (Or at the very least, and unwanted and unintended consequence of this mod):

Normally a simple left-click is all that's required to select a part from the VAB/SPH Catalog. Once I install TweakScale, there's about a 1-2 second delay after clicking a part before the part is actually loaded and picked up on the mouse pointer.

Edit: Not a bug with TweakScale. This happens when the game is running out of memory, so never mind.

Edited by Targa
Link to comment
Share on other sites

I'm having a problem I hope someone can help with. It seems that when scaling using tweakscale it is causing a CTD.

replication:

new KSP install

add following mods:

Animate Emissive

CRP

Crossfeed

MM

ModuleRCSFX

RealFuels

RealFuels: Stockalike RF Configs

Solver Engines

Tweakscale

Pick an engine and scale (up/down).

Launch.

CTD.

Thoughts?

Link to comment
Share on other sites

Hi!

Great mod!

I'm sure it's not super important, but the costs when scaling seemed to scale very interestingly. When I scaled up, costs went through the roof. I didn't bother graphing or fitting the data. This may very well be working as intended. I'd love to know more about how cost scales.

Also, if you scaled up a part attached to a craft, the cost won't be updated until you remove it from the craft, and reattach it. I haven't bothered uninstalling my mods and testing on a clean install.

Perhaps this may be because the cost is updated as a part is attached or removed from the craft.

Obviously not high priority, just trying to help out how I can.

Thanks again for the great mod.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...