pellinor
-
Posts
940 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by pellinor
-
-
1 hour ago, ZodiusInfuser said:
Maybe @pellinor can weigh in here (if they are still around), as they were the original coder for IR's control system. Maybe there is some way the system can be modified?
A servo could run in two modes:
1) It once gets a target and then autonomously moves there, such that the trajectory respects the limits (range, speed, acceleration) and comes to a stop at the target. This process is what I call interpolation.
2) Some other device does the interpolation, and sends a position to the servo at every physics tick. The servo moves to this position without trying to stop there. It may enforce its limits, or leave that to the other device and just blindly copy the position.
When I wrote the interpolator, we built the interface for mode 1 because that was the most straightforward use of a servo. It is totally possible to add the other mode too. The simplest way would be to bypass the interpolator and overwrite the servo position each tick.
-
21 hours ago, Lisias said:
I think it is, as the commit message says "get "model" transform by name instead of assuming that it is the first"
Yes that's it. It is actually not that hard to remember, because it was the worst bug during my TweakScale career, which was open a long time and cost the mod quite some reputation.
-
On 6/20/2019 at 4:00 AM, Lisias said:
Yet more interesting! So apparently the problem hits only a root part when scaled?
Just for your info: the last problem that only hit the root part was an access with a hardcoded index, something roughly like 'transform...getChild[0]', that should have been 'transform...getChild["model"]'. That code had worked for years, until in a new KSP version the index [0] of the root part pointed to some camera-related transformation. Which led to a hard to find bug that broke the camera whenever the root part was scaled. Maybe the issue here is similar.
-
9 minutes ago, OhioBob said:
FYI, an SRB's thrust should scale proportional to size^2, not size^3. Thrust is a function of the exposed surface area of the fuel, not its volume.
The problem is that this makes upscaled SRBs useless. Also the stock parts do not follow that logic. Instead they seem balanced with a useful TWR and burn time in mind. This was the motivation for the current SRB exponents.
-
8 hours ago, linuxgurugamer said:
The values I'm most interested in are:
- mass
- deflectionLiftCoeff
- dragAtMaxAoA
These are the exponents for the stock wing modules:
https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L169-L186Mass of wings is scaled with an exponent of 2, so that a large wing should be equivalent to the same area worth of small wings. dragAtMaxAoA does not appear (hopefully that means that it is a coefficient and not a total value).
-
6 hours ago, Lisias said:
- The second slider doesn't works - as expected, as the duplicate detector got rid of the Module instance that would answer to it
- The first sliders borking on NREs, as they are tied to the first occurrence of the TweakScale module that was not injected by my patches.
Just in case you haven't ruled that out already: the two sliders can also come from the same module. Both members "tweakScale" and "tweakName" have a tweakable, and a correctly initialized TweakScale module is supposed to use one of them and hide the other.
-
On 3/2/2019 at 3:21 AM, DylanSemrau said:
By removing "_" and " " from the part name...
I faintly remember that KSP does some automatic conversion that has caused confusion in the past. It was something along the lines of converting every "_" to "." in part names. Might also be config strings in general.
-
6 hours ago, Lisias said:
what's interesting, usually the first occurrence of the module in the craft file is the dominating one
The module disables itself if it is not the first one:
https://github.com/net-lisias-ksp/TweakScale/blob/master/Source/Scale/Scale.cs#L750-L757 -
2 hours ago, TranceaddicT said:
Or you could use :AFTER[TweakScale] so it gets applied ... wait for it ... after TweakScale.
Yes this will work. Just as :BEFORE[TweakScale] works because the patches that come with TweakScale take effect at an earlier time. So things are not as trivial as they seem. Actually I like the idea of preferring "%type=..." just because it leads to more robust behavior.
-
18 hours ago, AccidentalDisassembly said:
I'm having some of my parts quintuple in mass when scaled up just once. It's somewhat absurd.
My decisions for the exponents mostly came from gameplay considerations. For example stock tanks have a fixed ratio between fuel content and dry mass. If one stock tank is twice as big as another in all directions, it has 8x the fuel and 8x the dry mass. As a rule of thumb, an enlarged part should compare to the same mass, cost and utility as several copies of the original.
And most general, an exponent is right when both the enlarged and the shrinked part have some use in the game. A wrong exponent usually leads to one side being overpowered and the other being useless.Example: for a rocket engine, the exponents for mass, cost and thrust are equal. And that number is chosen in a way such that a scaled engine is able to lift a stack of somewhat reasonable and useful height.
Edit: since there are many parts whose utility scales with area (instead of volume), there are separate scaletypes for them: "stack_square" and "free_square":
https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/DefaultScales.cfg#L21-L62 -
18 hours ago, Lisias said:
Things starts to boil when the parts use custom modules. For each non-stock module, TweakScale must have custom, specific code, in order to make things work. And sometimes, we stomp on each other's feet and things start to blow - in a very unsatisfying and annoying way..
Actually most non-stock modules work fine with TweakScale's config interface, see all the non-stock entries in
https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L236-L463If the effect you need can be done by scaling a kspField in the target partModule, TweakScale support can be done with a ModuleManager config. Note that the exponent names refer to variable names in the C#-code (which might or might not correspond to config nodes appearing in some .cfg file). Only if this mechanism does not work do we need C#-code, either in the TweakScale codebase or in the other mod.
-
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.
-
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.
-
Let's move the discussion to the new thread and close this one.
-
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.
-
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?
-
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.
-
Announcement: It is no secret that my more active days in this community are long past, and I am not giving this project the attention it deserves. @Lisias has agreed to take over the development of TweakScale from now on, and I hereby pass the torch to him. Once he has opened his own release thread, this one can be closed.
-
I have to admit I missed the release, just downloading the game now...
Considering the scaletypes, I'm not really sold on adding many intermediate values. 1.875 is a stock scale now, so that one will probably get used a lot. Tbh, I never used any exact intermediate scale other than 1.875m myself.
For more exotic scales, everyone knows there is a slider for intermediate values right? So basically we are arguing about the ergonomics of some use cases avoiding the slider versus others having to click the arrows an additional one or two times.
-
On 7/29/2018 at 4:39 PM, linuxgurugamer said:
I noticed that all the included scale types which have scaleFactors corresponding to stock sizes don't have the 1.875 size. Are you planning on adding that anytime soon?
Yes, I guess that makes sense now that 1.875 has become a stock size.
On 7/26/2018 at 4:53 AM, captainb said:Hi I'm trying to use this mod with Nebula Decals. I'd like to rescale the decals without increasing the mass. I'd like to keep the other parts re-scaling behavior unaffected. Any ideas?
@PART[...] { %MODULE[TweakScale] { type = ... defaultScale = ... TWEAKSCALEEXPONENTS { mass = 0 } } }A patch like this should do the trick. Of course it also means that the mass does not decrease for a smaller part.
-
By setting the type to "free" you tell the module to use these intervals for the scaling slider:
SCALETYPE { name = free freeScale = true defaultScale = 100 suffix = % scaleFactors = 10, 50, 100, 200, 400 incrementSlide = 1, 1, 2, 5 }Defaultscale is which number the unscaled part should correspond to. In a %-based type the defaultScale should always stay at 100. (of course you still need to overwrite it if the old config used a different scaletype).
-
Update: TweakScale-v2.3.12
- configs for new parts
- fix for exceptions
- fix for solar panels
- recompile for KSP 1.4.2
Thanks for the pull requests!
-
13 minutes ago, xXKSP_playerXx said:
Curse link seems to be down for some reason...
Fixed, thanks.
1 hour ago, sp1989 said:Is there a way to get this to work on the making history parts. I gotta make the shroud fit right on top of the pod. How they could make such a frustratingly simple mistake is really well....frustrating lol.
You need patches like the ones in the TweakScale/patches folder.
By the way, I haven't bought the expansion, so if someone has working patches for the new parts I'd be happy about a pull request.
-
Update: TweakScale-v2.3.10
- don't overwrite stuff if the exponent is zero
- recompile against KSP 1.4.1
-
On 3/10/2018 at 5:35 PM, AYes said:
The engine flame is not scaled. Is it planned to fix it?
No, this is a stock limitation.
[WIP] Infernal Robotics - Next
in KSP1 Mod Development
Posted
Yes, if you want to check the limits, probably a second interpolator variant is the the way to go. The interface is supposed to provide a moving target and the servo tries to follow that target in real time.