blowfish Posted February 8, 2016 Share Posted February 8, 2016 23 minutes ago, pellinor said: From a first glance at the new PartSwitch code, TweakScale support will probably take more than MM patches. I'll have a closer look later this week. The MM patches for scaling of B9 parts are bundled with TweakScale, please come to that thread if you'd like to contribute or complain. Ah yeah, TweakScale support has been at the back of my mind, but I never got around to dealing with it. Is there a simple way to listen for the part scale on the plugin side? Link to comment Share on other sites More sharing options...
pellinor Posted February 8, 2016 Share Posted February 8, 2016 1 hour ago, blowfish said: Ah yeah, TweakScale support has been at the back of my mind, but I never got around to dealing with it. Is there a simple way to listen for the part scale on the plugin side? Yes, you need the TweakScale API definition Scale_Redist.dll from here:https://github.com/pellinor0/TweakScale/tree/master/GameData/TweakScale/plugins This does not depend on KSP/Unity so it does not need any updates. Source:https://github.com/pellinor0/TweakScale/tree/master/Scale_Redist Here is an example how to use it:https://github.com/MagicSmokeIndustries/InfernalRobotics/blob/develop/InfernalRobotics/InfernalRobotics/Module/Rescale.cs You can work with the absolute scaling factor (100% = the prefab) or the relative one (100% = the state before this rescale event). For tanks TweakScale already scales the amount and maxAmount on an existing resource node. What you need to do is to insert a scaled tank when switching part subtypes. So you can either scale your tank templates (this is how it works in FSFuelSwitch) or keep the scale as an internal variable. Do you also touch attachment nodes? They work pretty much the same, TweakScale will move them correctly but you need to account for the current scale when creating new nodes on an already scaled part. For mass and cost, TweakScale scales the (dry) mass/cost of the prefab. You need to take care of the modifiers that apply when changing subtypes. Again, FSFuelSwitch does this by scaling its tank templates. If all variables that need scaling are exposed as kspFields (float/double or lists of float/double), then we can do the scaling purely with MM patches. In this way FSFuelSwitch works without including any TweakScale-related code. InfernalRobotics is an example where this was not possible because it needs to move meshes on each rescale event. Link to comment Share on other sites More sharing options...
blowfish Posted February 8, 2016 Share Posted February 8, 2016 12 minutes ago, pellinor said: Yes, you need the TweakScale API definition Scale_Redist.dll from here:https://github.com/pellinor0/TweakScale/tree/master/GameData/TweakScale/plugins This does not depend on KSP/Unity so it does not need any updates. Source:https://github.com/pellinor0/TweakScale/tree/master/Scale_Redist Here is an example how to use it:https://github.com/MagicSmokeIndustries/InfernalRobotics/blob/develop/InfernalRobotics/InfernalRobotics/Module/Rescale.cs You can work with the absolute scaling factor (100% = the prefab) or the relative one (100% = the state before this rescale event). For tanks TweakScale already scales the amount and maxAmount on an existing resource node. What you need to do is to insert a scaled tank when switching part subtypes. So you can either scale your tank templates (this is how it works in FSFuelSwitch) or keep the scale as an internal variable. Thanks for that ... might not make it into the next release but I'll definitely look at implementing it soon. I'll probably keep scale as an internal variable, then I can just multiply by it when putting in the resources. Question: is the scale I'm going to get a length scale or a volume scale? 15 minutes ago, pellinor said: Do you also touch attachment nodes? They work pretty much the same, TweakScale will move them correctly but you need to account for the current scale when creating new nodes on an already scaled part. I just switch them between stack and docking nodes in the editor so they're not attachable (and change them all back in flight). So this shouldn't be an issue. 17 minutes ago, pellinor said: For mass and cost, TweakScale scales the (dry) mass/cost of the prefab. You need to take care of the modifiers that apply when changing subtypes. Again, FSFuelSwitch does this by scaling its tank templates. I have a separate module that sets the mass (since that's kind of messy), so I'll probably just need to implement it there too. But it should be pretty simple once everything is set up. 20 minutes ago, pellinor said: If all variables that need scaling are exposed as kspFields (float/double or lists of float/double), then we can do the scaling purely with MM patches. In this way FSFuelSwitch works without including any TweakScale-related code. InfernalRobotics is an example where this was not possible because it needs to move meshes on each rescale event. That might work (still leaning toward internal handling but maybe). Does TweakScale call any methods on the PartModule after its fields are changed that I could listen for in order to update everything? Link to comment Share on other sites More sharing options...
Beetlecat Posted February 8, 2016 Share Posted February 8, 2016 On 12/18/2015 at 11:28 PM, Virtualgenius said: With the procedural wing is it possible to make the ends rounded or you only get square or triangle, as I have never used procedural wings before I thought I would ask An "old" post, but your question wasn't fully answered -- because you can stack p-wings end-on-end, you can create a rounded wingtip by using a couple tiny winglets that decrease in width as you go. The more you use, the smoother the curve. Link to comment Share on other sites More sharing options...
pellinor Posted February 8, 2016 Share Posted February 8, 2016 (edited) 3 hours ago, blowfish said: Thanks for that ... might not make it into the next release but I'll definitely look at implementing it soon. I'll probably keep scale as an internal variable, then I can just multiply by it when putting in the resources. Question: is the scale I'm going to get a length scale or a volume scale? I just switch them between stack and docking nodes in the editor so they're not attachable (and change them all back in flight). So this shouldn't be an issue. I have a separate module that sets the mass (since that's kind of messy), so I'll probably just need to implement it there too. But it should be pretty simple once everything is set up. That might work (still leaning toward internal handling but maybe). Does TweakScale call any methods on the PartModule after its fields are changed that I could listen for in order to update everything? factor.*.linear is the length, there is also factor.*.cubic as a shortcut to the volume scale. I consider cost even messier than mass because of this unfortunate design decision to include the resource cost. As far as I know you only have the onRescale call from the API. And I am never sure about the order of operations (change of kspFields and API notification) because that is determined implicitely by the order of some list of rescale events (that is the part of the code I am least familiar with). Edit: looking at the IR code it should be first scale kspFields then do API notification. Edited February 8, 2016 by pellinor Link to comment Share on other sites More sharing options...
blowfish Posted February 8, 2016 Share Posted February 8, 2016 1 minute ago, pellinor said: factor.*.linear is the length, there is also factor.*.cubic as a shortcut to the volume scale. Good to know 2 minutes ago, pellinor said: I consider cost even messier than mass because of this unfortunate design decision to include the resource cost. Yeah, that's a problematic aspect ... I got around it by just saying that the base mass for switchable parts does not include any resource mass and adding the cost of resources in the module cost. I still think mass is messier because module masses don't affect physics - you have to set part.mass directly. Is this going to be a problem if TweakScale is trying to set the mass and I am too? Link to comment Share on other sites More sharing options...
pellinor Posted February 9, 2016 Share Posted February 9, 2016 21 minutes ago, blowfish said: Yeah, that's a problematic aspect ... I got around it by just saying that the base mass for switchable parts does not include any resource mass and adding the cost of resources in the module cost. I still think mass is messier because module masses don't affect physics - you have to set part.mass directly. Is this going to be a problem if TweakScale is trying to set the mass and I am too? We'll have to test, and compare to the FSFuelSwitch-TweakScale interaction. I think I scale a 'baseMass' value in FSFuelSwitch and then it overwrites what I do to part.mass, which ends up with the right mass when both modules are present. Or something remotely like that. Link to comment Share on other sites More sharing options...
Joshwoo70 Posted February 9, 2016 Share Posted February 9, 2016 13 hours ago, blowfish said: I didn't change the names of any parts. If you're talking about the RT patch, all I did was copy the Mk2 cockpit to legacy and duplicate it for the new cockpits. But if something is broken, then patches are welcome. I can't possibly test all the compatibility patches myself with each release. Then it should continue to work. Thanks Link to comment Share on other sites More sharing options...
Autochton Posted February 9, 2016 Share Posted February 9, 2016 @blowfish My main interests lie in the Realism Overhaul/Realistic Progression-0 suite of mods. FAR and RF support is a boon, there. Some scaling is applied within RO, I know, which'll need going over, but that's within RO to deal with. There'll probably be the usual headaches regarding reentry heat mods and whatnot, as well. Mainly, I figured it was a good idea to have it clear which mods are supported actively by the B9 pack. Other mods may or may not support, but that's more on them. Link to comment Share on other sites More sharing options...
pellinor Posted February 9, 2016 Share Posted February 9, 2016 17 hours ago, blowfish said: Yeah, that's a problematic aspect ... I got around it by just saying that the base mass for switchable parts does not include any resource mass and adding the cost of resources in the module cost. I still think mass is messier because module masses don't affect physics - you have to set part.mass directly. Is this going to be a problem if TweakScale is trying to set the mass and I am too? Small correction on the mass question: TweakScale treats part.mass like any other kspField, so it scales the original (prefab) value and overwrites the part field. The mechanic of incrementally adding the scaling contribution is only done in getModuleMass which drives the engineer's report. So yes, messy stuff that easily breaks if multiple actors change part.mass. Link to comment Share on other sites More sharing options...
blowfish Posted February 9, 2016 Share Posted February 9, 2016 31 minutes ago, pellinor said: Small correction on the mass question: TweakScale treats part.mass like any other kspField, so it scales the original (prefab) value and overwrites the part field. The mechanic of incrementally adding the scaling contribution is only done in getModuleMass which drives the engineer's report. So yes, messy stuff that easily breaks if multiple actors change part.mass. Right, hence the issue. So does TweakScale call OnRescale() before or after updating the part's mass. If it's after, then everything will probably work, because the mass I set will override the default mass, but if it's before, then there might be conflicts. Link to comment Share on other sites More sharing options...
pellinor Posted February 9, 2016 Share Posted February 9, 2016 3 hours ago, blowfish said: Right, hence the issue. So does TweakScale call OnRescale() before or after updating the part's mass. If it's after, then everything will probably work, because the mass I set will override the default mass, but if it's before, then there might be conflicts. I am not sure because scaling the part.mass is implemented as an OnRescale() call of the same kind. https://github.com/pellinor0/TweakScale/blob/master/Updater.csIf I read the method CreateUpdaters(Part part) right then the partModules end up first in the updating list, and the part fields come at the end. But this is really a part of inherited code that I never understood properly. Probably the best solution is to just code a prototype and see what happens. Sorry for being so vague about this ;-) Link to comment Share on other sites More sharing options...
blowfish Posted February 9, 2016 Share Posted February 9, 2016 1 hour ago, pellinor said: I am not sure because scaling the part.mass is implemented as an OnRescale() call of the same kind. https://github.com/pellinor0/TweakScale/blob/master/Updater.csIf I read the method CreateUpdaters(Part part) right then the partModules end up first in the updating list, and the part fields come at the end. But this is really a part of inherited code that I never understood properly. Probably the best solution is to just code a prototype and see what happens. Sorry for being so vague about this ;-) Thanks, I will try it out, but if that's the case then it sounds like it's not going to work. I was sort of working on a unifying solution for a while, but the fact that everyone who wants to modify mass would need to use it made it difficult (for now I just integrated it into B9PartSwitch, which means that I can have any number of modules that modify mass but it's still not compatible with any other modules that modify mass, and it looks like that might include TweakScale). Link to comment Share on other sites More sharing options...
Speedster159 Posted February 10, 2016 Share Posted February 10, 2016 (edited) KSP-AVC is notifying me for 6.0 but CKAN is not prompting yet? I'm just about to start making planes/spaceplanes on my save and I'd like to get this before that just so I won't break anything later on. Edited February 10, 2016 by Speedster159 Link to comment Share on other sites More sharing options...
blowfish Posted February 10, 2016 Share Posted February 10, 2016 (edited) 6 minutes ago, Speedster159 said: KSP-AVC is notifying me for 6.0 but CKAN is not prompting yet? I'm just about to start making planes/spaceplanes on my save and I'd like to get this before that just so I won't breaking anything later on. Yeah, because I updated the repository to 6.0.0.-100 (prerelease), but there is no official 6.0 release yet. I'm not going to do anything with CKAN until the final release, but you're welcome to manually install the prerelease I linked on the last page (or just follow the maintenance port link in my signature and click on downloads). Edited February 10, 2016 by blowfish Link to comment Share on other sites More sharing options...
Speedster159 Posted February 10, 2016 Share Posted February 10, 2016 49 minutes ago, blowfish said: Yeah, because I updated the repository to 6.0.0.-100 (prerelease), but there is no official 6.0 release yet. I'm not going to do anything with CKAN until the final release, but you're welcome to manually install the prerelease I linked on the last page (or just follow the maintenance port link in my signature and click on downloads). How craft breaking is 6.0 anyways? Link to comment Share on other sites More sharing options...
blowfish Posted February 10, 2016 Share Posted February 10, 2016 40 minutes ago, Speedster159 said: How craft breaking is 6.0 anyways? It will mostly only break craft in flight. In the editor, you just have to go through and re-select the fuel tanks. Note that the old Mk1 and Mk2 parts have moved to the legacy pack. Additionally, anything using the engine pylons won't load as they're now integrated into the engines (and switchable!). So if you've got a craft with the pylons, open it up with the old version, remove pylons, then install the 6.0 prerelease and load it back up (at which point you can select the correct pylons on the engines). Link to comment Share on other sites More sharing options...
Speedster159 Posted February 10, 2016 Share Posted February 10, 2016 (edited) 39 minutes ago, blowfish said: It will mostly only break craft in flight. In the editor, you just have to go through and re-select the fuel tanks. Note that the old Mk1 and Mk2 parts have moved to the legacy pack. Additionally, anything using the engine pylons won't load as they're now integrated into the engines (and switchable!). So if you've got a craft with the pylons, open it up with the old version, remove pylons, then install the 6.0 prerelease and load it back up (at which point you can select the correct pylons on the engines). What do you mean re-select fuel tanks? I'm trying to decide if I should update to 6.0 pre or stay in 5.4. Right now I'm only building atmospheric aircraft, nothing complex enough to reach orbit. Is there any compatibility issues with 6.0 and other mods? Edited February 10, 2016 by Speedster159 Link to comment Share on other sites More sharing options...
blowfish Posted February 10, 2016 Share Posted February 10, 2016 16 minutes ago, Speedster159 said: What do you mean re-select fuel tanks? I'm trying to decide if I should update to 6.0 pre or stay in 5.4. Right now I'm only building atmospheric aircraft, nothing complex enough to reach orbit. I mean you have to re-select what type of fuel each fuselage piece holds, as it will revert to structural (no fuel). 17 minutes ago, Speedster159 said: Is there any compatibility issues with 6.0 and other mods? It doesn't work with Tweakscale. Other than that I know of no explicit incompatibilities. Link to comment Share on other sites More sharing options...
Speedster159 Posted February 10, 2016 Share Posted February 10, 2016 1 hour ago, blowfish said: I mean you have to re-select what type of fuel each fuselage piece holds, as it will revert to structural (no fuel). It doesn't work with Tweakscale. Other than that I know of no explicit incompatibilities. So remove the B9 Patch in Tweakscale? Link to comment Share on other sites More sharing options...
blowfish Posted February 10, 2016 Share Posted February 10, 2016 6 hours ago, Speedster159 said: So remove the B9 Patch in Tweakscale? Yeah, that should work. Link to comment Share on other sites More sharing options...
Speedster159 Posted February 10, 2016 Share Posted February 10, 2016 3 minutes ago, blowfish said: Yeah, that should work. Just did that and it made it worse... I was using a scaled down circular intake for a subsonic aircraft and it reverted back to original after removing the B9 Patch.. I did not know the part was from B9 and I thought B9 6.0 was not compatible? Link to comment Share on other sites More sharing options...
blowfish Posted February 10, 2016 Share Posted February 10, 2016 52 minutes ago, Speedster159 said: Just did that and it made it worse... I was using a scaled down circular intake for a subsonic aircraft and it reverted back to original after removing the B9 Patch.. I did not know the part was from B9 and I thought B9 6.0 was not compatible? Well, if you have scaled down B9 parts and you remove the TweakScale patch, then they'll revert back to their original size. I'm not sure what's confusing about that. It's incompatible as in "some craft will not load and others will exhibit strange behavior," this being a case of the strange behavior. Link to comment Share on other sites More sharing options...
Speedster159 Posted February 10, 2016 Share Posted February 10, 2016 (edited) 2 minutes ago, blowfish said: Well, if you have scaled down B9 parts and you remove the TweakScale patch, then they'll revert back to their original size. I'm not sure what's confusing about that. It's incompatible as in "some craft will not load and others will exhibit strange behavior," this being a case of the strange behavior. I thought all B9 parts were incompatible. I'll just keep the patch in for now. Edited February 10, 2016 by Speedster159 Link to comment Share on other sites More sharing options...
pellinor Posted February 10, 2016 Share Posted February 10, 2016 17 hours ago, blowfish said: Thanks, I will try it out, but if that's the case then it sounds like it's not going to work. I was sort of working on a unifying solution for a while, but the fact that everyone who wants to modify mass would need to use it made it difficult (for now I just integrated it into B9PartSwitch, which means that I can have any number of modules that modify mass but it's still not compatible with any other modules that modify mass, and it looks like that might include TweakScale). A simple common ground would be that mass is only added incrementally. So everyone who touches it multiple times should remember how much he added before and only apply the difference. I have already gone a part of this way when implementing getModuleMass for the editor display. This special treatment would break many existing cfgs so I'm a bit hesitant. I could also force relative scaling for mass, that means it always scales the current mass instead of the prefab one. This probably does not break any other mods using TweakScale. You can test this by setting the line "mass = 3" to "!mass = 3" in ScaleExponents.cfg (and I would force it in the code so it also applies to overrides of this value). This is probably the simplest solution because you don't need to touch part.mass on rescale. Generally this is the better behavior for values that other actors might touch, unfortunately it is not the default and clashes with MM syntax (so it can be used in configNodes but not in patches). Link to comment Share on other sites More sharing options...
Recommended Posts