[1.2.2] Netherdyne Mass Driver Mod- Version 1.3.2 is now LIVE!

[FreeThinker]

4 hours ago, Northstar1989 said:

Alright, so it appears that a PNG is actually smaller than a JPG for all the texture files except texture 001, so I converted that one and left the rest as PNG's (I will be updating the OP with the new version shortly).  Not that the format matters too much anyways except for download size/speed- as I understand it KSP internally converts all textures to .DDS format now, which is what made the DDS converter trend and related mod largely obsolete?

 

 

 

3

Well I attempted to convert all files to DDS but only one worked and it texture looked ugly, so I kept everything as it is.

3 hours ago, Northstar1989 said:

@FreeThinker it APPEARS that something about the recompile reverted the Mass Driver back to its original stats, causing me to have to go about re-balancing it all over again!   Do you have any idea what might have caused the config to revert back to an earlier form like this, @FreeThinker?

 

 

 

 

No I simply left everything the same except the code and the partmodel. I guess it was made before your critical balance changes.

Btw, I think we should add tweakscale support allow more massive parts to be launched

Btw, I added you as author. on my upload at spacedock  Seems to me this is the best way to do it. Does it allow you to edit and update the spacedock download?

Edited February 23, 2017 by FreeThinker

[rspeed]

FWIW, I'm going to be replacing textures in my overhauled version. The upshot is that I'll be including an editable version that can be included with the source code, plus a compressed version for distribution. And a Blender file!

[Northstar1989]

1 hour ago, rspeed said:

FWIW, I'm going to be replacing textures in my overhauled version. The upshot is that I'll be including an editable version that can be included with the source code, plus a compressed version for distribution. And a Blender file!

Your editable version???

What is it exactly that ypu want changed that requires you to start an entirely new version?

I generally like to try to avoid the balkanization (fragmentation) of mods.  It would be better to have you come in with whatever changes you want on the main project than to start your own branch.

That way, I can advise you on any issues pertaining to realism, keep you focused on KISS, and maybe even help with some changes now and then.  On the other hand, having somebody to bounce ideas off of is likely to make both our ideas better.

I extend you the same offer I made before- come in on the mod development and you should have more or less a free hand (and credit as a co-author), so long as you always prioritize realism first and foremost as the best way to obtain balance and believeability, and try not to get carried away with feature-bloat.

 

Regards,

Northstar

Edited February 23, 2017 by Northstar1989

[Kerbas_ad_astra]

1 hour ago, Northstar1989 said:

I generally like to try to avoid the balkanization (fragmentation) of mods.  It would be better to have you come in with whatever changes you want on the main project than to start your own branch.

That way, I can advise you on any issues pertaining to realism, keep you focused on KISS, and maybe even help with some changes now and then.  On the other hand, having somebody to bounce ideas off of is likely to make both our ideas better.

The best way to do that is to learn how to use git and GitHub.  That's exactly what revision control is for -- contributors can make forks of the main repository, make changes, comment on each other's revisions, and then merge updates into the primary release branch to produce releases.

[linuxgurugamer]

I'm a bit puzzled here.  Ate there two people doing different releases?

[Northstar1989]

9 hours ago, Kerbas_ad_astra said:

The best way to do that is to learn how to use git and GitHub.  That's exactly what revision control is for -- contributors can make forks of the main repository, make changes, comment on each other's revisions, and then merge updates into the primary release branch to produce releases.

Github is a *tool* for managing collaborations- and not one I ever objected to either, so I don't know why you're soapboxing about this when I was addressing rspeed.  Using it doesn't change the basic fact of whether people are working together or seperately on different release branches of a mod...

8 hours ago, linuxgurugamer said:

I'm a bit puzzled here.  Ate there two people doing different releases?

That remains to be seen.  I hope not.  Like I said, I find it works better and is easier to keep track of when people work together rather seperately.

 

Regards,

Northstar

Edited February 24, 2017 by Northstar1989

[linuxgurugamer]

4 hours ago, Northstar1989 said:

Github is a *tool* for managing collaborations- and not one I ever objected to either, so I don't know why you're soapboxing about this when I was addressing rspeed.  Using it doesn't change the basic fact of whether people are working together or seperately on different release branches of a mod...

That remains to be seen.  I hope not.  Like I said, I find it works better and is easier to keep track of when people work together rather seperately.

 

Regards,

Northstar

Yes it does, and that is where Github would come in handy.  Lets people work on it and then be able to merge it all back together.

I found this (among others) tutorial on github, you might find it handy: http://product.hubspot.com/blog/git-and-github-tutorial-for-beginners

[illectro]

So, what would it take to scale this up so we can fit larger vehicles through the middle? Could it be made to work with Tweakscale? 

[Northstar1989]

6 hours ago, illectro said:

So, what would it take to scale this up so we can fit larger vehicles through the middle? Could it be made to work with Tweakscale? 

The problem with that is that mathematics of Mass Drivers actually favor smaller diameters.  Due to the way the Biot-Savart Law works, a Mass Driver coil with the same length, coil thickness,  current, and twice the radius only experiences half the magnetic field strength in the center despite being twice as massive and requiring twice the electrical power to operate:

https://en.m.wikiversity.org/wiki/Physics_equations/Magnetic_field_calculations

https://en.wikipedia.org/w/index.php?title=Biot–Savart_law&oldid=581674678

Basically the strength of magnetic fields fall off with 1/r^2 whereas the circumference of a circle only increases according to C=2*pi*r.

Note that you *COULD* squeeze a bit more force out of a mass driver with a star-shaped driver rather than circular ring, and by increasing the thickness of the coils (if you doubled the coil wall thickness you could pass twice the current through due to only experiencing half the resistance- indeed thicker coils are necessary to maintain the same rate of electricity consumption per unit length), but then at that point you have a mass driver that masses a bit more than 4x (as increasing the wall thickness means the outer part of the wall is even FURTHER from the center) as much for the exact same Force per unit-length...

 

I *AM* thinking of creating a scaled-down version designed for 1.25 meter payloads.

A 1:2 scale part would only weigh 1.25 tons per 1 meter long section (vs. 10 tons per 2 meter long section, as it would have half the circumference, half the length, and half the coil thickness) and each individual Mass Driver segment would produce half the force of its 2.5 meter diameter cousin (each ring would also only be half as long- so you'd be able to use 2x as many coil segments for the exact same total track-length) for half the per-coil electricity consumption (the coil acts on the payload for half the distance, and so imparts half as many Joules of energy...)

 

2.5 Meter Diameter Mass Driver:

- 2 meter long segments

- 10,000 kg per segment

- 1471 kN max Force per segment

- 10 Ec/kN energy consumption

1.25  Meter Mass Driver:

- 1 meter long segments

- 1250 kg per segment

- 750 kN max Force per segment (slightly more Force per unit length as coils have non-negligible thickness)

- 10 Ec/kN energy consumption

 

As you can see, going SMALLER is more mass-efficient, and allows a substantially higher rate of acceleration of your payload (which has 1/4th the cross-sectional area but is exposed to slightly HIGHER force per unit of coil length).  Let's look at a theoretical Mass Driver optimized for 0.625 meter payloads, shall we?

0.625 Meter Mass Driver:

- 0.5 meter long segments

- 156.2 kg per segment

- 382 kN max Force per segment (as before, coils have non-negligible thickness)

- 10 Ec/kN energy consumption

 

Note one more thing here- a 4:1 increase in Force:Mass ratio does *NOT* equal a 4x increase in exit-velocity for the payload.

As the payload accelerates through the Mass Driver it picks up velocity, and thus passes through each segment more quickly.  For instance a payload passes through a 40 meter length of Mass Driver coil in only 2x the time it takes to pass through a 10 meter length, and thus only receives half the velocity in keeping with E = 1/2*m*v^2.  You expend 4x the energy to impart 2x the exit velocity- which is the same reason why electric thrusters have such anemic Thrust despite having exit-velocities measured in the 10,000's of meters/second...

 

So, I suppose it *WOULD* be possible to impart TweakScale compatibility (and in fact I was thinking of releasing a series of re-sized parts with the mod using the "rescaleFactor" line in the part configs- that works for creating scaled-up and scaled-down parts, right?), but I warn against scaling the Mass Drivers up and expecting the same performance...  Even setting aside mass concerns for a moment, the Force imparted by scaled-up Mass Driver coils per unit length should fall off as the Mass Drivers have a non-negligible thickness (I eyeballed the rate at which this happens, by the way, but I'm pretty sure it's actually HIGHER than this.  Calculus is required to actually create a correct formula for this...)

 

Note also that I haven't bothered with messing at all with the ratio of length to coil-thickness in any of these calculations.  Coils with a better thickness:length ratio require less electrical energy to impart the same Force to the payload, as they lose relatively less energy to wire resistance- but the Mass Driver parts we work with all assume the same rate of energy-loss in the coils (a 100% efficient Mass Driver requires less electricity than a 90% effocient one, for instance- we don't mess with efficiency at all) for mathematical simplicity's sake, with little regards to realism (also as I don't actually KNOW exactly how efficient Mass Driver coils actually are at turning electricity into force in real life, and everything in KSP is nonsensical when it comes to electricity-consumption anyways...)

 

Regards,

Northstar

P.S. Any serious discussion of energy-efficiency in KSP begs the question: WHAT IS A UNIT OF EC EQUAL TO?  If each Ec represents a kW, our Mass Drivers are only 20% efficient (providing 1 kN over the length of 2 meters for 1 second for each 10 kW).  If it represents 200 Watts they are 100% efficient and need to be slightly nerfed.   If it represents 100 Watts they are 200% efficient and need to have their Ec/kN ratio more than doubled...  Current figures for Ec consumption were selected for simplicity, but may be completely wrong based on what a single Ec represents...

P.P.S. I realize, in hindsight, that I may have gotten a little carried away here.  Mass-efficiency probably isn't an issue of all that much concern for most players, who will only use the Mass Drivers on the ground on Kerbin.  And, if you're Scott Manley (and yes I know I'm talking about you in the third person here Scott- most players probably don't realize that Illectro is your forum account) and decide to launch one of these things to the Mun, then you're probably just doing it for sheer awesomeness factor rather than because it's a particularly mass-efficient way to return payloads from the Mun to Kerbin (the MOST mass-efficient way of doing this in KSP would be to build a long tube of Mass Drivers from locally mined Ore on the Mun using ExtraPlanetary Launchpads.  Mass Driver coils are one of the few things we could REALISTICALLY produce on Luna in real life, as they are basically just long electrified coils of Aluminum, and the Lunar regolith is literally MADE of Aluminum Oxides in many places...  The solar panels, electronics, and energy-storage devices required to operate such a device would not be trivial to produce via Lunar manufacturing though, and would most likely need to be imported from Earth and assembled onto the coils by skilled technicians...)

Edited February 25, 2017 by Northstar1989

[rspeed]

I'm just making a new model for the hell of it, and will be making it available if you want to use it.

[Northstar1989]

5 hours ago, rspeed said:

I'm just making a new model for the hell of it, and will be making it available if you want to use it.

A new model?  How will it differ from the old one?

[Northstar1989]

Ohhhh boy, I've got a treat for you guys!  I decided it would be worthwhile to create larger (and smaller!) versions of the Mass Driver after all.  These will be released as independent parts so they will have their own tech nodes, descriptions, and unlock costs (of these 3, only setting tech limits on size is possible in TweakScale) as well as being specifically tested for issues at each size class.

I can't promise I'll have this done immediately, but I'm working on it!

 

Regards,

Northstar

Edited February 25, 2017 by Northstar1989

[Northstar1989]

Also, you guys can forget what I said before about the force falling off with increasing diameter of the coils- due to the way the strength of the magnetic field lines actually INCREASE as you move towards the edges of the tube (at any diameter), this may not actually be the case.  I've decided to just keep force:length ratio the same for all sizes as a simplifying assumption and to make the parts easier to test to ensure they are working properly (technically the force remains the same- the force DURATION for each part is what will change in accordance with size...)

I have also decided to reduce the 0.625 meter version (yes there's a 0.625 meter mass driver coming out!) of the mass driver's force by 1/4th beyond the effects of merely scaling down its length, as the ability to accelerate a payload with 2x the density of the StarTram's intended 40 ton, 13 meter long, 2.5 meter diameter payload (interestingly this yields a density not much lower than that of RP-1, which means StarTram probably anticipated use of Kero/LOX or even SRB's for orbital circularization in order to reduce the volume of the spacecraft and this minimize atmospheric friction...) at 480 g's is not only a little overpowered- it's impractical in real life.  At those g-forces any payload would collapse like a tin can or rip itself apart due to the gradients in force between the center of the tube and its walls (not simulated in KSP).

Thus I have enhanced both realism and balance by assuming a nearly 1:16 reduction in coil thickness for the 0.625 meter driver vs. the reference 2.5 meter mass driver instead of a 1:4 reduction- and a proportionate 1:4 reduction in maximum force at the center of the smaller coil (realistically, this would be due to a proportional 1:16 decrease in current, and a resultant decrease in the strength of the magnetic field...)

I have also made the smaller mass drivers slightly heavier than would be expected based on coil-thickness and size, and the larger ones slightly lighter.  This is as larger mass drivers would realistically require proportionally less insulation (due to the Square-Cube Law), electronics (which would increase in proportion to coil-length, but not thickness), and structural reinforcement (larger coils produce far less force on the payload relative to their own mass, and thus experience greatly reduced acceleration due to recoil) to operate.

I made this factor quite strong (the 5 meter Mass Drivers are nearly 10% lighter than you would expect based on their 8x larger volume) though- and may have somewhat exceeded the degree of this effect in real life, as I don't know how important these effects would realistically be (the mass-savings on insulation due to Square-Cube Law are significant, as these would be very high-current, heavily-insulated lines: but the most important factor would actually be the greatly reduced recoil and reduced need for structural reinforcement...)

 

Regards,

Northstar

Edited February 25, 2017 by Northstar1989

[Northstar1989]

Alright, the Experimental Build with the new diameter Mass Drivers is now up!

Note that the old 1.2.2 version is still set as the DEFAULT version to download from Spacedock until I can confirm this update works as intended (no testing done yet!)  To download it, you will HAVE TO go into the "Changelog" tab of SpaceDock and manually download it,  it will *NOT* act as the default download you get from hitting the "Download" button on the mod front page.  No idea if non-default builds even show up on CKAN (as I don't personally use it) either...

 

Regards,

Northstar

[Haifi]

The force settings on the old 1.2.2 build were way too weak, with 32 slave and one master accelerator it could throw a 2,5 x 3.0m tank roughly 500m into the air. I edited the .cfg I found that I need at least 15000 force on both master and slaves to nearly reach LKO. Without fairings I won't  even get close to LKO. Also firing the accelerator creates a stop motion like lag, as soon as the payload is out of the "barrel" everything runs smooth again.

[Northstar1989]

Alright, the mass drivers seem to working as expected with o e small hiccup...

When networking a tube of Mass Drivers, RED IS THE FIRING DIRECTION.  That is, attaching them in the normal" orientation will cause them to work as expected.  However when using a single *UNNETWORKED* Mass Driver (that is, just the Master part on.its own with no Network Units attached) BLACK IS UP.  For some reason you have to reverse the polarity of the Master unit (which is the teal bug) only when it operates on its own.  I haven't figured out why yet...

28 minutes ago, Haifi said:

The force settings on the old 1.2.2 build were way too weak, with 32 slave and one master accelerator it could throw a 2,5 x 3.0m tank roughly 500m into the air. I edited the .cfg I found that I need at least 15000 force on both master and slaves to nearly reach LKO. Without fairings I won't  even get close to LKO. Also firing the accelerator creates a stop motion like lag, as soon as the payload is out of the "barrel" everything runs smooth again.

Make sure you are orienting the Mass Driver slave units correctly (see above)  With just 6 slaved units I've already been able to throw 1.25 meter ore tanks a good few kilometers up in the air just in testing with the new X11 (which has half the force duration per-unit).

EDIT: Also, MAKE SURE you have enough batteries attached to the Mass Driver stack itself.  They consume a MASSIVE amount of energy (as in I use 16 of the 490 EC radial batteries just for a stack of 17 of the 1.25 metet Mass Drivers and it drains a good 20% of the Ec storage).  I would recommend firing a "dumb" payload up like a full ore tank and sticking with the mass driver stack itself during testing to ensure that you aren't running out of Ec during firing...

Edited February 25, 2017 by Northstar1989

[Northstar1989]

42 minutes ago, Haifi said:

with 32 slave and one master accelerator it could throw a 2,5 x 3.0m tank roughly 500m into the air.

I just tested with the exact same 32-1 Mass Driver setup, using the 2.5 meter drivers, and a C7 fueled adapter with a Rockomax-32 below it.  The payload made it 6.4 km up in the air (and it definitely would have been further if it hadn't flipped around to travel blunt-end first for some reason.  This is with stock aerodynamics, after all...

As for the lag" that's actually because the vessel goes on rails while it's accelerating through the mass driver itself (note this only happens once when the mass drivers have sufficient energy to fire- but it gets very jittery if they don't, as individual drivers might still fire midway through ascent as the batteries recharge).  That pause is the game taking the vessel on and off rails (it's supposed to represent an evacuated tube in a vacuum, regardless of the model not looking like it's sealed, which is why aero drag would be inappropriate)

Regards,

Northstar

[Northstar1989]

1 hour ago, Haifi said:

The force settings on the old 1.2.2 build were way too weak

The force settings are a lot more powerful than you saw, probably because you ran out of power (although it could be a bug you experienced).  Though if you're impatient for more powerful mass drivers, try out the 5 meter ones in the 3.0 Experimental Build on SpaceDock...

I just managed to launch a streamlined, 56 ton rocket I built using Procedural Parts (because the stock interstage adapters are far too blunt to use as nosecones- which is why my payload flipped before...) 7.8 km up in the air with nothing but 17 of the 5 meter Mass Drivers (1 Master and 16 slaves).  The larger ones don't actually exert any more force than a tube of the same length built out of smaller mass drivers (ezcept the 0.6w5 meter ones), but you can build much longer tubes out of fewer parts with them, which is greatly beneficial...

 

Speaking of longer tubes, if somebody can create me a hollow tube model that is longer than the ones I am using right now (let's say 4 or 5 times longer to start, but I'd like to eventually advance it up to at least 7 or 8 times longer, maybe up to 12), but with the same diameters for the internal hollow spaces, I can try and get it working as a replacement to the current model- so you can create longer tubes with fewer parts.  The force per unit length would remain the same, but each individual part would exert more force due to its longer length...  This should allow you to obtain higher speeds with the same number of parts, without sacrificing realism...

 

Regards,

Northstar

Edited February 25, 2017 by Northstar1989

[Northstar1989]

Version 1.3.1 is now LIVE and set as the default download on SpaceDock!  Get it now:

https://spacedock.info/mod/1227/Netherdyne Mass Driver Mod [Official]

As well as the promised larger Mass Driver rings (which I have bug-tested and found to work as-intended, accelerating payloads to high enough velocities to soar dozens of kilometers high with a tall enough Mass Driver stack...) this version also includes a readme with directions on how to use the mod and descriptions of known issues!

Also, don't forget, I'm looking for somebody to generate a longer model of the 2.5 meter ring (which I will then re-scale for all the other parts) to replace the current part model entirely!  The new model should be hollow and passable on the inside even when the Mass Driver is not firing (just like the current model's colliders allow for), and should ideally have at least 5-6 and possibly as much as 12 times the length:diameter ratio while maintaining the same internal diameter as the current model...

 

 

Hope to see some great work from you guys on these lines soon, and don't forget to check out the new update of the mod!

 

Regards,

Northstar

 

 

[Northstar1989]

Version 1.3.2 is now live.  The only change was moving the Mass Driver parts back in the tech tree, however (from Advanced Construction- a 90 Science node- to the 1000 Science node "Experimental Electrics", which they now share with RTG's).

Also, I would like to once again remind readers I am looking for somebody to create a longer part model for this mod to replace the current ring-parts.  This is a great opportunity to determine the future appearance of the mod!  I would prefer something that looks a little more, well, airtight- with sections fitting closely against one another- as the mass driver is assumed to contain a vacuum inside its central tube like with the StarTram design and operates on rails (no drag) even inside the atmosphere...

Also, I've received some comments that I could just make the changes myself.  I'd like to remind people that I am not the only one to use this mod, though, and my visual artistic sense is... questionable at best.  It would be much better for everyone involved if somebody else created the model instead.  The basic requirements are having at least the same internal diameter, a longer length, and having some sort of marking providing polarity (one end of the part does not look like the other from the outside) to allow players to determine firing-direction when one of these things is being fired in outer space, parallel to the ground on Minmus' flats, etc.

 

Regards,

Northstar

 

[Noppera-Bo]

I have two quick questions before I toss this into my soup of mods:

1-Does the recoil of an orbiting drive take attached masses into account?(ie. If I anchor it to a Type-E with KAS, will it acknowledge the 100s of tons attached to it?)

2-How're the G-forces? Will non-frozen Kerbals get liquified at launch?

[wasml]

I hesitate to say anything but I haven't seen any response to your call for models. I'm not much of a modeler myself but I did create a mass driver model intended for Minmus (not enclosed) made up of a support, a length of rail (one segment can be seen above the assembled unit and a loader (separate model off to the right above assembled unit). The Electro-magnets are encased in protective cover (totally not an attempt to avoid making a wire coil texture!).

http://imgur.com/EMZgciP

Not sure this meets your low poly count request either - about 2K tris for a segment of rail, though I used box colliders instead of mesh colliders to try and reduce the performance hit. Each segment has 8 colliders around the circumference of the tube. I can make some modifications but be warned progress would be slow.

[Northstar1989]

22 hours ago, wasml said:

I hesitate to say anything but I haven't seen any response to your call for models. I'm not much of a modeler myself but I did create a mass driver model intended for Minmus (not enclosed) made up of a support, a length of rail (one segment can be seen above the assembled unit and a loader (separate model off to the right above assembled unit). The Electro-magnets are encased in protective cover (totally not an attempt to avoid making a wire coil texture!).

http://imgur.com/EMZgciP

Not sure this meets your low poly count request either - about 2K tris for a segment of rail, though I used box colliders instead of mesh colliders to try and reduce the performance hit. Each segment has 8 colliders around the circumference of the tube. I can make some modifications but be warned progress would be slow.

All I get is an error message when I try to view your album...  Anyone else having this issue?

Anyhow, low poly count is kind of critical- otherwise I might as well just merge together a bunch of the existing models and call it a day...

Perhaps you'd find it easiest just to work off the existing model?  It already has a wire texture- all you need to do is change its color from copper to that of aluminum, and then cover the interior of the ring with it.  If you know how to model and have an artistic eye, I assume you could create a basic tube design by simplifying the existing model? (Removing the spools the wire texture is currently coiled around, for instance)  I'd do it myself- but once again, I lack that artistic eye...

On Mon Feb 27 2017 at 8:34 AM, Noppera-Bo said:

I have two quick questions before I toss this into my soup of mods:

1-Does the recoil of an orbiting drive take attached masses into account?(ie. If I anchor it to a Type-E with KAS, will it acknowledge the 100s of tons attached to it?)

2-How're the G-forces? Will non-frozen Kerbals get liquified at launch?

I'm not even sure the recoil follows Newton's Laws.  It doesn't even seem to occur 100% of the time.  So I can't make any promises there, unfortunately.

The G-forces on the payload are a bit kooky because the vessel gets taken on and off rails (so they show up as much higher than they should be based on the forces and masses if you Alt+F3, for instance).  I can't guarantee it won't liquify your Kerbals if you leave G-tolerances for crew/parts on...

Use at your own risk- but I suggest you do.  There's somethong really awesome about seeing a rocket shredding through the atmosphere at a thousand meters per second, propelled from the end of a long mass-driver stack...

Similarly, I can't remember many more awesome sights than watching Scott Manley bombard Kerbin with a Mass Driver on the Moon...

 

Regards,

Northstar

Edited March 1, 2017 by Northstar1989

[Noppera-Bo]

1 hour ago, Northstar1989 said:

G-forces on the payload are a bit kooky because the vessel gets taken on and off rails (so they show up as much higher than they should be based on the forces and masses if you Alt+F3, for instance).  I can't guarantee it won't liquify your Kerbals if you leave G-tolerances for crew/parts on...

Guess I just need to make sure to deep freeze my Kerbals before launch.

(I find rocketry too easy without heat and g-forces. Scary as it is, plasma trails are kinda beautiful)

1 hour ago, Northstar1989 said:

Use at your own risk- but I suggest you do.  There's somethong really awesome about seeing a rocket shredding through the atmosphere at a thousand meters per second, propelled from the end of a long mass-driver stack...

I will admit, I saw the portrayed use as an expensive confetti cannon... But I also jumped straight to contemplating merging one into my orbital shipyard design as a first leg in interplanetary transfer.

I'll just dive in and see how it works for my intentions. Once "Three Rocks Base" is fully assembled I'll report how it does.

[wasml]

1 hour ago, Northstar1989 said:

all you need to do is change its color from copper to that of aluminum, and then cover the interior of the ring with it

Texturing is my weakest spot - things come out rather cartoony. I'll play with it some but... don't hold your breath. Hopefully someone with better modeling skills will show up.