Project genericvessel - spacecraft3 and multistage2 replacement project

[Face]

This doesn't seem to read the animation positions at scenario start up. Also, the animations should continue to the end, when you release the lshift before the keypad2/8

In the SC3-stock "Animations" scenario, it does. But of course I did not change the situation with the SC3-incompatible animation support. The issues of this ticket still apply.

 

[Artlav]

To be honest, I'm not very happy with the strict parser/module separation, now that I got to know your code base better. I miss the concept of object encapsulation in it.

A concept that in this case i see as unnecessary extra complexity.
Instead of a clean and simple solution there is some OO syntax sugar that does the same thing no better, but is no longer obvious.

that's the beauty in DVCS: you can always clone it, or simply branch off and do whatever you see as better way to do it. We can always merge things in to whatever branch we work on later on. That's why I've put up the two bookmarks "Artlav/master" and "Face/master".

Now that i just don't understand - either it's a permanent branch and two different genericvessel projects out there from now on, or someone's work is getting dumped on merge.

So, would you be rewriting the whole parser to native Windows infrastructure, or should we keep the separation?
Part here, part there is just making a big mess.

Please don't see it as an affront

Don't worry about that, it's obvious that there would be some differences in approaches between us, and on a joint project they should be settled.

 

[Face]

A concept that in this case i see as unnecessary extra complexity.
Instead of a clean and simple solution there is some OO syntax sugar that does the same thing no better, but is no longer obvious.

I really don't see OOP as unnecessary syntax sugar, but helping in keeping a clean design. It also helps me focusing on certain code parts while not having to keep global variables in mind all the time.

But this really is a completely different discussion.

Now that i just don't understand - either it's a permanent branch and two different genericvessel projects out there from now on, or someone's work is getting dumped on merge.

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

As for the different projects due to 2 branches: that's true all the time in development, because as soon as 2 people work in parallel, there are 2 branches. With things like SVN, the integration point just HAD to be the commit, with DVCS not anymore. And I think this is a good thing, otherwise I'd have to fear to "break" something. And this feeling is utter nonsense in a free-time open-source project, if you ask me.

So, would you be rewriting the whole parser to native Windows infrastructure, or should we keep the separation?
Part here, part there is just making a big mess.

I'll try that, yes, all the time testing how complexity will differ between the two. Since the project started with your contribution to have at least some platform to start with, I don't see a big mess in a temporary combination. As you can see, the refactoring turned out to be straight-forward.

Don't worry about that, it's obvious that there would be some differences in approaches between us, and on a joint project they should be settled.

In the end, yes. But I don't like big design up front and refactor code very often, especially in the beginnings of a project. And in the end, the two approaches are not that different, after all.

Yours just uses an intermediate data-format for the whole definition, while mine is using the INI file per se. I can see where instead of the filename a pointer to your data structure is passed around in the e.g. UMmu or Payload classes. But I have to admit that I was too lazy to jump between Pascal and C++ to fully implement this approach, so I simply focused on content instead and made the Payload and UMmu features work.

It would be nice to hear different opinions on the code, BTW! So what are other interested coders (if there even are some) thinking about the 2 approaches? What is easier to understand, maintain, extend?

Nothing is set in stone, of course, so a third one would not be ruled out right from start.

 

[Artlav]

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

UMmu or Payload classes

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

 

[Arthur Dent]

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?

I view the genericvessel project as something that will be an improvement on- and also an alternative to SC3. So IMHO, you should define a better syntax for multiple meshes. In general, if you can make things better than SC3, you should. If it breaks legacy support, people could still resort back to the original SC3 if they are not going to port their work over to Genericvessel.

 

[Kendo]

Dream Chaser by Libor is invisible with the Spacecraft/genericvessel. Works fine with Spacecraft3/Spacecraft3. Dont need the other addons only for some scenarios. Here is the link
[ame="http://www.orbithangar.com/searchid.php?ID=5834"]Dream Chaser[/ame]

Also CTD with genericvessel with the docked to ISS scenario, but loads if you put a ; against the Docking info in the scenario file, but is still invisible.
I don,t know if its mesh related or not.

 

[Face]

Committed my take on the recent features - UMMU support and payloads, as well as some animation tweaks.
http://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?

First of all let me say thanks for your continued contributing. Whatever work you put in here, nothing will be "lost" in the sense of what you might mean with dumping work. At the very least, your code inspires ideas and/or demonstrates your thoughts clearly, making discussion about features easier.

For the UMMU section: I'm not sure if the deviation from Dan's original definition-style is a good idea. He documented the min/max corner definition in his docs, but not a position/size definition. In addition, the EVA setting also includes position besides rotation. Wouldn't it make sense to expose this to the users?

On the animations: I used the "Animations" scenario from the stock SC3 and compared it using SC3 and genericvessel. It works completely different. If you check the SC3-PDF, there is a description what the repeat and pause setting should actually do, and indeed it works so in the scenario with SC3 and numpad keys. In genericvessel, currently, it does not. I've documented this in the ticket.

On the payloads: SC3 supports the multiple meshes, so I implemented it. It doesn't really matter to me if it makes sense or not, given that the project's roadmap is to first create a replacement for SC3. It was also no big deal with the native INI parser, because that thing doesn't take inline-";" comments into account at all. I suspect vinka also used GetPrivateProfileString...

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?

Well, easy: take the parts and combine them.
At first, your approach with the variable holding the current payload number as well as the jettison function is just the same in mine. This can be merged. There is even the possibility to continue using the classes and just use the struct as parameter instead of the file name, changing the GetPrivateProfileString calls to simple assignments. I won't do that as long as the struct is not fully SC3 compatible in this regards, though.
The next thing is the header split: you did that too, so no problem in merging that.
Then the UMMU part: basically we use the same things, mine is having them stoved away in classes, though. The real difference is the definition, and there we really would have to "dump" work. But I see this as a minor issue.

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?

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.

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

I think all those statements are pretty much summed up in the last two: you don't like the syntax of C++ and OOP in C++. There is no point in discussing this here in detail. I guess we just have to agree to disagree on that.

Given that most development for Orbiter is using C++, I will stick with the later, and this means using classes, data encapsulating techniques and so forth for me.

But of course this doesn't mean that your style is rejected, just that I won't inherit it for my work on the project. Nitpicking about coding styles is something I will only do when I get paid for it, not in my hobby projects.

regards,
Face

---------- Post added at 13:20 ---------- Previous post was at 13:17 ----------

If it breaks legacy support, people could still resort back to the original SC3 if they are not going to port their work over to Genericvessel.

This is something I certainly won't do for a first step. Adding of features, maybe alternative ways to define something: OK. But removing a feature: no.

 

[Artlav]

Ok then, let's Rock'n'Roll.
I'll finish the SC3 part in my style and design, then Face would branch from there and refactor to his liking. Good?

Update #2 from today:
orbides.1gb.ru/orbf/genericvessel-130307-1.zip

Changes:
-Fixed DreamChaser (/ is also a valid directory separator on Windows)
-Fixed all known animation issues (pause, repeat, keys, save/load, initial state, etc)
-Remapped animation keys onto numpad, restricted the key set to [0..9, k, g] as per the original docs.
-Added parsing for multi-mesh payloads
-Added EVA exit position tag (eva_pos)

What other bugs are there?
What else behaves differently from SC3?
Which other vessels refuse to work?

For the UMMU section: I'm not sure if the deviation from Dan's original definition-style is a good idea. He documented the min/max corner definition in his docs, but not a position/size definition. In addition, the EVA setting also includes position besides rotation. Wouldn't it make sense to expose this to the users?

Disagree on the corners - the center+size is homomorphic to that, but makes much more sense.
Agree about eva_pos - it could add something.

I guess we just have to agree to disagree on that.

I guess so, but disagreement there means two projects, so let's do as i noted at the start of this post - i finish the SC3 related code in the style and framework of the code i already have, and after that all bets are off?

 

[Kendo]

Artlav, brilliant work. But the cockpit of the eagle1999-S3 is invisible again using the latest version. You corrected this in a couple of versions ago. Thank you, Ken

 

[Face]

Ok then, let's Rock'n'Roll.
I'll finish the SC3 part in my style and design, then Face would branch from there and refactor to his liking. Good?

I guess so, but disagreement there means two projects, so let's do as i noted at the start of this post - i finish the SC3 related code in the style and framework of the code i already have, and after that all bets are off?

Hehe. Yeah, sounds cool to me, let's rock :thumbup:. I'm already in the progress of merging your code in, it really is not that much of a problem.

Disagree on the corners - the center+size is homomorphic to that, but makes much more sense.

Indeed it is homomorphic, so no big deal, really. My point was just that users would need yet another transformation if they start with Dan's documentation. But we are really on new grounds here, so if folks are more happy with this way of defining it, I'm all for it, too.

Another thing I've stumbled upon during coding the UMMU section: air lock status. Does it make sense to have that setting ATM? Without a facility to open/close the air lock, I guess not. OTOH, it could be coupled to an animation, just like the touchdown points.

regards,
Face

---------- Post added at 16:25 ---------- Previous post was at 16:21 ----------

Artlav, brilliant work. But the cockpit of the eagle1999-S3 is invisible again using the latest version. You corrected this in a couple of versions ago. Thank you, Ken

If you've got the version from a Bitbucket archive, you'll get the binaries still checked in in the old version on Artlav's branch there. I did not check, but his ZIP archive in the post contains the binaries supposedly generated with his latest version.

 

[Artlav]

Artlav, brilliant work. But the cockpit of the eagle1999-S3 is invisible again using the latest version.

Oops, a typo.
Here is the fix:
http://orbides.1gb.ru/orbf/genericvessel-130307-2.zip

 

[BruceJohnJennerLawso]

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

Please accept a humble suggestion from one vastly less experienced in C++, but maybe airlocks could be done something like this?



Sorry for the awful quality of the pic, but what Im trying to show with it, is that maybe airlocks can have their boundaries automatically set by the location and direction of the docking port? If you add vectors out to the back end of the box, then to the far edge, maybe you can get coordinates from the vectors along the way.

That would work okay, but it might be necessary to have user defined ones for more flexibility.

 

[Artlav]

what Im trying to show with it, is that maybe airlocks can have their boundaries automatically set by the location and direction of the docking port?

The problem with this is that the airlock location would be restricted to the docking port location, which is not always desirable.

However, that makes a nice default - if no position is specified, use docking port 0 (or COG if no docking ports present).

 

[Kendo]

Artlav, Thanks, works great.

 

[Donamy]

How far away are working buttons in the VC. :lol:

Seriously though, Is adding more joints in the robotics possible ?

---------- Post added at 05:44 PM ---------- Previous post was at 05:07 PM ----------

three things I found

1. In my Jason voyager addon, I have a truss section that I use the robotics to translate the telescope from the bay, it doesn't work in this update.

2. Pressing "A" should show a list of attachments and the vessels attached to them, then pressing lshift numpad 4/6 toggles through the attachments.

3. In the robotics mode, you need to press spacebar to bring up the animation that is chosen and lshift numpad 4/6 selects between animations, while lshift numpad 2/8 perform the animation. I'm sure you know this, but what SC3 allowed was to be able to let go of the lshift key before the keypad 2/8, and the animation will continue on it's own. Very useful when performing a lengthy movement.

 

[Donamy]

Does anyone know what's causing this ? It happens often, when alot of animations have been used.

 

[Face]

That's a pretty generic error message and as such carries no information to what actually happened there. Do you only encounter this problem with genericvessel (what version?), or is it also happening in SC3?

 

[Donamy]

It happens in both, but not when converted to .dll

 

[Kendo]

Pardon my ignorance, but is there a manual or list of what the Genericvessel module is capable of, like any extra commands that SC3 doesn,t have?.

 

[Face]

Pardon my ignorance, but is there a manual or list of what the Genericvessel module is capable of, like any extra commands that SC3 doesn,t have?.

ATM there is just the Wiki: https://bitbucket.org/face/genericvessel/wiki/Home