Committed my take on the recent features - UMMU support and payloads, as well as some animation tweaks.
orbides.1gb.ru/orbf/genericvessel-130307.zip
UMMU section:
maxseats - max crew in the vessel.
airlock_position - Position of the airlock: x,y,z in vessel coordinates
airlock_size - size of the airlock: x,y,z in vessel coordinates
eva_rot - orientation of the EVA on exit x,y,z direction
Payload section:
All implemented, except for multiple meshes parsing.
The syntax is ambiguous there - normally ; denotes comments, but here it is a separator.
Should we implement the exception, or define better syntax?
How many add-ons there use multiple meshes per payload?
Animations:
Changed the saved animation tags to match the original - the SC3 scenarios should now load correctly out of the box.
-What to do about activation keys? The doc for SC3 says left shift+ number keys, nothing in there about numpad.
I think numpad use for such things is plain ugly, what about keeping the number keys?
-What about repeat animations not working?
How to reproduce?
What other animation-related issues are there?
"Dumping" work is not what a merge does IMHO. Let's say you are fixing the animation problems on your branch, all the while keeping my changes out. I can then merge them in, or simply graft some of your changesets to my branch. It is equally valid the other way around: you could e.g. pick my allocation fixes and apply them to your branch.
Ok, i commited the recent changes.
As you can see, i had my own plans for UMMU, and mix of yours and mine for payloads.
How could we possibly merge that without dumping someone's work?
As you can see, the refactoring turned out to be straight-forward.
Except that the code is no longer aesthetically pleasing, and so i'll have trouble working on it with efficiency.
One more unrelated stylistic issue - case sensitivity.
I seriously don't like variables with different case, like "Data" in case-sensitive languages.
It's just guaranteed to case troubles (besides me being lazy to press shift extra time each time).
Why do you think these classes are necessary?
while not having to keep global variables in mind all the time.
The only global variable i can see is the DLL link function - what else is there to keep in mind?
The structure received is the property of the vessel class, so everything is nicely encapsulated.
I really don't see OOP as unnecessary syntax sugar, but helping in keeping a clean design
OOP is good for clean design, but doing it with C++ syntax is unnecessary complexity. So, the classes you defined is syntactic sugar with no apparent advantage.
It all boils down to me not liking the syntax of C++, i guess. I'm used to working with natively high level languages, or natively low level languages, not a stop-gap in-between like C++.