Jump to content

[1.0.2] B9 Aerospace | Procedural Parts 0.40 | Updated 09.06.15


Recommended Posts

The next update will bring some neat features, but thanks to KSP saving uneditable properties like range from KSPField UI_Control (tweakable UI) types straight into the craft files and attempting to override definitions from the class with those values, tweakable UI will be partially or completely broken for every single wing part placed before the next update. As far as I understand after asking a few experienced modders, there is no way to fix it except:

  • Manually editing every single wing definition within every single craft file, removing the offending sections that break our stuff
  • Making a script that can do the operation above automatically to an arbitrary craft file

If there is anyone proficient in the latter, lend a hand - I don't have any experience with perl, .bat and other ways to create a script like that. The task is pretty simple, you need to find blocks called *_UIControl and remove them along with a set of properties surrounded by curly braces that follow them.

Edited by bac9
Link to post
Share on other sites

  • Asking Squad to stop doing that with craft files
  • Manually editing every single wing definition within every single craft file, removing the offending sections that break our stuff
  • Making a script that can do the operation above automatically to an arbitrary craft file

- first option will be most awesome and easiest solution for moders, but not likely that will happen

- second - not likely that people will be willing and skilled enough to manualy edit craft file each time when you make changes in SPH/VAB editor

- probably only solution, sorry, can't help you with perl, don't know if it is even possible to do thet trough bat file, maybe I could help you to create additional exe file in some more known programing language. So after saving craft file, you should be able to call program from command line like:

B9_procedural_change.exe "craft_file.craft"

Only problem is from my side that I don't know what need to be changed in craft files and I'm short with free time lately, so I can't prommise that I will be able to contribute at all with this on time. still don't think that is too bad idea to call external exe or dll to do the job.

Link to post
Share on other sites
The next update will bring some neat features, but thanks to KSP saving uneditable properties like range from KSPField UI_Control (tweakable UI) types straight into the craft files and attempting to override definitions from the class with those values, tweakable UI will be partially or completely broken for every single wing part placed before the next update. As far as I understand after asking a few experienced modders, there is no way to fix it except:

  • Manually editing every single wing definition within every single craft file, removing the offending sections that break our stuff
  • Making a script that can do the operation above automatically to an arbitrary craft file

If there is anyone proficient in the latter, lend a hand - I don't have any experience with perl, .bat and other ways to create a script like that. The task is pretty simple, you need to find blocks called *_UIControl and remove them along with a set of properties surrounded by curly braces that follow them.

I just don't use the tweakables menu :)

Link to post
Share on other sites

Not every new property is exposed through the alternative menu yet, there are too many of them to make it convenient (12 new ones). Shouldn't be an issue for you, because only properties that existed in the previous versions become broken due to that issue, but I'd like to have a permanent solution to avoid that problem with future changes.

Link to post
Share on other sites

Why not just more a traditional GUI like say RealFuels has? I mean the whole toggle and mouse drag thing I know people are used to from pWings but it seems awkward to me. In fact I keep my hand off the mouse when using the "alternate" UI because its too hard to be precise, whereas I can with the keys.

Anyway why not just instead of that, just make a traditional UI window that pops up with the settings? It would seem the whole mousing/toggling through poperties, etc would be more work than a normal UI.

Link to post
Share on other sites
The task is pretty simple, you need to find blocks called *_UIControl and remove them along with a set of properties surrounded by curly braces that follow them.

What about Regex?

[\w]*_UIControl[\s]*\{[\w|\s|\=]*\} should do, what you want.

Link to post
Share on other sites

If I have time & remember I could probably knock up some perl - kinda busy atm though.

Installed in 0.90, so testing latest.

* As soon as I open the rclick menu, memory use - which was stable at about 2.4GB - starts climbing somewhat erratically but at times in the order of 5MB/s. Closing the window doesn't always stop it! I know you had a bug issue open for the tweakables widgets, did anything come of that? ( actually now I waited ~10 mins or so there's no memory increase anymore, so maybe something got garbage collected ).

* If I've got one of your submenus expanded, click a different part, when I come back to the original part I expanded the submenus for the button that shows they're expanded is still lit, but the submenus themselves are not expanded anymore.

* I can't sweep the control surfaces back as much as I can the main wing parts - especially awkward for tailfins which can be really raked.

Once I launched the vessel memory use went back down to 2.7GB, so hopefully the leak is just in the configuration part.

Edited by Van Disaster
Link to post
Share on other sites
As soon as I open the rclick menu, memory use - which was stable at about 2.4GB - starts climbing somewhat erratically but at times in the order of 5MB/s. Closing the window doesn't always stop it! I know you had a bug issue open for the tweakables widgets, did anything come of that? ( actually now I waited ~10 mins or so there's no memory increase anymore, so maybe something got garbage collected ).

Once I launched the vessel memory use went back down to 2.7GB, so hopefully the leak is just in the configuration part.

Known bug with stock tweakables - fixing this one has to be done on Squad's end.

Link to post
Share on other sites
* As soon as I open the rclick menu, memory use - which was stable at about 2.4GB - starts climbing somewhat erratically but at times in the order of 5MB/s. Closing the window doesn't always stop it! I know you had a bug issue open for the tweakables widgets, did anything come of that? ( actually now I waited ~10 mins or so there's no memory increase anymore, so maybe something got garbage collected).

I moved every single tweakable slider to KSP API Extensions UI_FloatEdit, those don't seem to cause the same bloating issue (I got up to 15 megabytes per second use growth before switching, that's insane), but that will cause every single tweakable on previously saved crafts to stop working because of unwanted UI data KSP crams into craft files. I'll see what can be done, maybe a bash script that can convert your .craft files to clear that garbage from them.

If I've got one of your submenus expanded, click a different part, when I come back to the original part I expanded the submenus for the button that shows they're expanded is still lit, but the submenus themselves are not expanded anymore.

I'm aware of this, but I don't know what's causing it yet. I need more testing and reproduction steps, including stuff like whether second part you clicked was a symmetry counterpart of the first or not.

I can't sweep the control surfaces back as much as I can the main wing parts - especially awkward for tailfins which can be really raked.

Control surface offset is a multiplier for shifting vertices on the lateral axis by their distance to root on the chordwise axis. At the moment it can not go over 1, which means no control surface can be swept by more than 45 degrees. I'll look into altering that, but distortion that is very problematic and can potentially cause hourglass shaped intersections with inward offsets.

Once I launched the vessel memory use went back down to 2.7GB, so hopefully the leak is just in the configuration part.

Yes, obviously, as that was a scene change and Unity mops up everything with a garbage collector in that event. Same thing happens on creation of a new craft or loading of another craft in the editor - those are implemented through complete reloading of the editor scene.

Link to post
Share on other sites
I moved every single tweakable slider to KSP API Extensions UI_FloatEdit, those don't seem to cause the same bloating issue (I got up to 15 megabytes per second use growth before switching, that's insane), but that will cause every single tweakable on previously saved crafts to stop working because of unwanted UI data KSP crams into craft files. I'll see what can be done, maybe a bash script that can convert your .craft files to clear that garbage from them.

Given the dev status of this, I'd not be worried if I had to rebuild everything.

I'm aware of this, but I don't know what's causing it yet. I need more testing and reproduction steps, including stuff like whether second part you clicked was a symmetry counterpart of the first or not.

I did start paying attention when I noticed it happening - I'll do a more methodical set of tests.

Control surface offset is a multiplier for shifting vertices on the lateral axis by their distance to root on the chordwise axis. At the moment it can not go over 1, which means no control surface can be swept by more than 45 degrees. I'll look into altering that, but distortion that is very problematic and can potentially cause hourglass shaped intersections with inward offsets.

Maybe clamp deflection based on the deflection of the other end of the surface as well, so the distances between verts are limited rather than the absolute angles? not sure if you could clamp it based on the selected shape, that might be worth looking at too.

Link to post
Share on other sites

Given how brutally efficient you've been with fixing bugs and adding features, I don't see there being an issue in previous craft becoming slightly wonky/incompatible with new versions. It took me nearly no time at all to build my NASA shuttle, and I'd happily start over.

Link to post
Share on other sites

I don't have anything very important to chime in other than:

This mod is awesome, and it is heads and tails above PWings in my opinion. I have had no issues with crashing in editor or any other problems. My only quibble is the keybinding 'G' for the interactive menu is the same keybinding Part Angle Display uses to adjust fine tuning angle. Is there a way to adjust the keybinding?

I appreciate the awesome work, and can't live without B9 parts, or B9 wings.

Link to post
Share on other sites

Version 0.17

https://bitbucket.org/bac9/b9_aerospace_plugins/downloads

AR6Vgwuh.jpg

  • Implemented coloration - every wing surface (top/bottom/leading/trailing) can now have not just previously implemented separate material type, but also an appropriately masked paint overlay with configurable opacity, hue, saturation and brightness
  • Reimplemented alternative UI, it now closely resembles tweakable menu with a number of improvements over stock (color coded groups, longer labels, hints, collapsable sections)
  • Moved all sliders in the stock tweakable menu to KSP API Extensions UI_FloatEdit editor, which seems to positively affect the rate of a memory leak on tweakable window redraw (sometimes it even stops entirely).
  • Unified all properties, control surfaces and wings no longer use isolated fields (breaking change, all previously built crafts will not retain wing part configurations)
  • Added an option to set current configuration of a wing or control surface as default, making all subsequently created parts of that type use the same values (along with an option to reset default values back)
  • Shifted all properties into logical groups
  • Implemented collapsable menus to make editing more convenient
  • Geometry and performance fixes, refactoring and minor fixes in other areas
  • Improved some layer textures, surface type 0 in particular (rivets, more appropriate seam structure and so on)
  • Alternative UI is now opened with H instead of G to solve binding conflict with some mods

mJFRx2Cl.jpg

Note:

Again, this update completely breaks all procedural parts in crafts saved with previous versions of the mod. Hopefully there will be no need to change part field structure in the same way again, but there you have it.

Known issues:

  • Alternative menu will not reappear if you will exit to the KSC scene and return to the craft (this scenario is not triggering initialization of a window for some reason, looking into it)
  • Hint text in the alternative UI sometimes changes to description of a wrong field
  • Stock tweakable menu can still leak memory, probably from UI_Toggle buttons
  • Collapsible group contents and headers sometime come out of sync after certain sequences of switching between parts (can be fixed by double-clicking the group header)

Edited by bac9
Link to post
Share on other sites

bac9, awesome at each step of improvement :) Now it's clearly the stock wings replacement. I suppose your techniques can be applied to some hulls creation as well.

- - - Updated - - -

A tiny "issue" is found. Steps to reproduce:

1. Create a hull body (well, anything you are planning to attach wings to)

2. Attach B9-PW to the hull while SPH symmetry mode is on. Result: 2 raw wing surfaces created.

3. Start customizing the one you've attached (not the symmetry clone). Only the one you are customizing is changing visually.

4. Detach and re-attach the cloned wing in symmetry mode - both wings inherit the settings of the wing you grabbed for detachment. However, if you grab the one you are customizing & re-attach it - the magic will work for both wings and they ingerit customization settings.

Link to post
Share on other sites
1. Create a hull body (well, anything you are planning to attach wings to)

2. Attach B9-PW to the hull while SPH symmetry mode is on. Result: 2 raw wing surfaces created.

3. Start customizing the one you've attached (not the symmetry clone). Only the one you are customizing is changing visually.

4. Detach and re-attach the cloned wing in symmetry mode - both wings inherit the settings of the wing you grabbed for detachment. However, if you grab the one you are customizing & re-attach it - the magic will work for both wings and they ingerit customization settings.

That's not reproduced on my side, editing original parts correctly propagates all changes to symmetry counterparts. There is some other factor I guess.

Link to post
Share on other sites

Might help:

Here's a list of mods (directories) and additional fixes libs of my testing install:

000_Toolbar

000_USITools

ActiveTextureManagement.rar

AnchoredDecouplerFix.dll

B9_Aerospace

BahaSP

ChuteQuickloadFixer.dll

CommunityResourcePack

CrewRosterFreezeFix.dll

CrossFeedEnabler

EVAEjectionFix.dll

FerramAerospaceResearch

Firespitter

JSI

KAS

KerbalDebrisFix.dll

KerbalJointReinforcement

Kerbaltek

KSPAPIExt

list.txt

MagicSmokeIndustries

ModuleManager.2.5.6.dll

ModuleManager.ConfigCache

ModuleManager.ConfigSHA

NASAmission

Regolith

Squad

ToadicusTools

toolbar-settings.dat

TweakableEverything

TweakScale

Edited by Horus
Additional info
Link to post
Share on other sites

Works like a charm :)

Btw. remember I've posted a problem of missing textures. Seems I've found the source of the problem. When you start the game in window mode & switch from it to some other application while loading - textures might not be initialized properly because of GPU context losing (say hello to unity & squad :) ). And that causes your wings not having textures displayed properly.

Link to post
Share on other sites

Version 0.18

https://bitbucket.org/bac9/b9_aerospace_plugins/downloads

  • Fixed symmetry counterparts not updating properly

_______________________________________

Works like a charm :)

Btw. remember I've posted a problem of missing textures. Seems I've found the source of the problem. When you start the game in window mode & switch from it to some other application while loading - textures might not be initialized properly because of GPU context losing (say hello to unity & squad :) ). And that causes your wings not having textures displayed properly.

Ah, figures. Though I don't wait for the game to load, I always switch to other windows - but I never has this problem. Maybe you're not using Active Texture Management and it's a problem specific to stock texture loader?

Edited by bac9
Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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...