Closed DMagic1 closed 10 years ago
Thanks for the pull; I was planning to do this myself, but I'm moving next week so my coding time is a little limited (plus I really want to fix cones in RT before I go; that and the silence from the resource mining people has made me a little reluctant to push ahead with Custom Asteroids :/ ).
One critique: wouldn't it make more sense to implement this method (and any analogous ones added later) in terms of getAsteroidData()
(which would become internal or private to keep the API compatible), to avoid duplicating the messy logic of looking in multiple places?
D'oh! That's a bug I overlooked.
Is there a standard way to convert a ProtoPartModule
to the equivalent PartModule
? I tried running it through a temporary ConfigNode
, but I get a NullReferenceException
when I call PartModule.Load()
.
EDIT: never mind, I thought of a much more sensible implementation. I'll try to have a working version up by tomorrow.
@DMagic1, I've got a placeholder implementation up. I've moved getAsteroidTypeName()
to CustomAsteroidData
, but the interface is otherwise what you proposed.
Now to rewrite pretty much the entire AsteroidDataRepository
class... :weary:
Basically the same method as getAsteroidData(), but returns the name string instead of the CustomAsteroidData instance.
Verifying that the vessel is actually an asteroid can be done on either end, here or by the caller; I included here.
Similar methods could be used for the other CustomAsteroidData fields in case someone needs to know them before they are moved onto the ModuleAsteroid, but I don't have any need for them.