Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate use of FSmeshSwitch to consolidate part variants #27

Closed
sumghai opened this issue Jul 3, 2014 · 1 comment
Closed

Evaluate use of FSmeshSwitch to consolidate part variants #27

sumghai opened this issue Jul 3, 2014 · 1 comment

Comments

@sumghai
Copy link
Owner

sumghai commented Jul 3, 2014

Mesh switching may allow the end taper to be toggled on/off, such that separate tapered and flat-ended module variants in the VAB/SPH parts lists are no longer required.

Assess if this is possible / feasible.

@sumghai sumghai added this to the R0.04a milestone Jul 3, 2014
@sumghai sumghai self-assigned this Jul 3, 2014
@sumghai
Copy link
Owner Author

sumghai commented Jul 4, 2014

Initial test involved successfully swapping of the tapered ring and plain bulkhead ring objects on a Karmony Mission Module (the base model used on most module variants). Since FSmeshSwitch could not reference objects from MODEL{} nodes, the tapered ring object had to be duplicated in the Mission Module model itself.

Contrary to Firespitter documentation, FSmeshSwitch was unable to handle multiple objects per variant, which is problematic considering the way the colliders for the recessed tapered end rings were initially configured.

Because it was essential to have these end taper colliders, the ultimate decision was to abandon this particular line of investigation - tapered and flat-ended parts will continue to have separate listings in the VAB/SPH.

@sumghai sumghai closed this as completed Jul 4, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant