SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

Here's a nice 360° panorama of Discovery's flight deck in very high resolution: http://www.gigapan.com/gigapans/102753

... and a few more http://www.jonbrack360.com/shuttle/, including several of Endeavour's flight deck.

 

[Donamy]

Might be better talking to Thorsten and offer the SSU Orbiter in exchange for his Flight gear cockpit. :shifty:

 

[Urwumpe]

Might be better talking to Thorsten and offer the SSU Orbiter in exchange for his Flight gear cockpit. :shifty:

Would not be helpful. Completely different graphics engine, we hardly have the freedom in that department that Thorsten's team has there.

But can I consider your response as "I am currently not available?"

 

[GLS]

I just committed the last panels I could separate. IMO we should create a branch so the graphics department can finish the "gutting" of the vc and the panels (graphics and code) can be worked one at a time, without worries about having a revision with missing parts.

 

[Urwumpe]

I just committed the last panels I could separate. IMO we should create a branch so the graphics department can finish the "gutting" of the vc and the panels (graphics and code) can be worked one at a time, without worries about having a revision with missing parts.

I agree. What about making short-lived feature branches there?

Would we use git, we could be doing this with local branches or git flow feature branches.

 

[GLS]

I agree. What about making short-lived feature branches there?

Would we use git, we could be doing this with local branches or git flow feature branches.

No work is "short-lived" in SSU...:uhh:

 

[Urwumpe]

No work is "short-lived" in SSU...:uhh:

Sadly. It should be.

I'll think about this problem, maybe I can invent something. :idea:

I just try Visual Studio 2017 Community Edition for Orbiter add-on development, it looks like a good IDE as base for us.

 

[GLS]

Sadly. It should be.

I'll think about this problem, maybe I can invent something. :idea:

I just try Visual Studio 2017 Community Edition for Orbiter add-on development, it looks like a good IDE as base for us.

I think we need to invent more people...

 

[Urwumpe]

I think we need to invent more people...

Lets be realistic. We won't get them. The project is running now for nine years with about the same number of developers throughout history.

We need another idea there.

 

[GLS]

As we have a VC branch already, I'm updating it with the trunk and that should then be ready for work.

 

[Urwumpe]

As we have a VC branch already, I'm updating it with the trunk and that should then be ready for work.

Well, or that, if the branch is not too stale.

Any boring task known to you that could be made automatic?

What do you think about doing automatic component and integration tests with Lua?

 

[GLS]

Well, or that, if the branch is not too stale.

I'm updating it now.

Any boring task known to you that could be made automatic?

What do you think about doing automatic component and integration tests with Lua?

Nothing comes to mind... either the compiler complaints, or it CTDs, or it does something unexpected. (yes I'm at the level of your bosses when it comes to testing :lol: :facepalm

One thing that could probably help is to add sanity checks by the truck load to the "master classes" (subsystem director, bundle manager, etc), and put then inside "#ifdef SSUDEBUG" to only slow down the code during testing.

 

[mrozigor]

Didn't you think about migrating to git?

 

[GLS]

The VC branch is ready for work now!

---------- Post added at 02:26 PM ---------- Previous post was at 02:24 PM ----------

Didn't you think about migrating to git?

There was talk of that when SourceForge went belly up for 2 weeks, some 2 or 3 years ago. For now it's working... :shrug:

 

[Urwumpe]

There was talk of that when SourceForge went belly up for 2 weeks, some 2 or 3 years ago. For now it's working... :shrug:

Yes. Also migrating to git is no easy step, I would prefer it to take place when we can close all SVN branches and have everything solid on trunk.

But generally: It would make it easier to switch away from sourceforge on one hand, would make development easier, also the git integration into the newer Visual Studio versions is nearly perfect.

---------- Post added at 03:51 PM ---------- Previous post was at 03:43 PM ----------

One thing that could probably help is to add sanity checks by the truck load to the "master classes" (subsystem director, bundle manager, etc), and put then inside "#ifdef SSUDEBUG" to only slow down the code during testing.

Good idea. I also think about putting support for automatic integration tests there.

But I am slightly opposed to use conditional compilation for it. I think it would be better to test exactly the same binary as we give out to our players, and use just configuration file options to determine the level of debugging options.

If we use dependency injection properly, this shouldn't matter anyway since all run-time costs happen during the injection.

 

[GLS]

My idea was just to test we are not doing stuff like writing/reading from line 20 of a bundle (they are only 16)... this sort of "static" stuff.
BTW I've run SSU thru Cppcheck and nothing *big* jumps out, except a message that we're reading from index -1 in Common.cpp, which I've looked at and all seems fine there. :shrug: I can post a log if anyone wants to take a lot.

 

[Urwumpe]

My idea was just to test we are not doing stuff like writing/reading from line 20 of a bundle (they are only 16)... this sort of "static" stuff.
BTW I've run SSU thru Cppcheck and nothing *big* jumps out, except a message that we're reading from index -1 in Common.cpp, which I've looked at and all seems fine there. :shrug: I can post a log if anyone wants to take a lot.

I had done the same once, but I was pretty disappointed by Cppcheck in the process, because it tolerated too much IMHO... I am used to more complaints from FindBugs in Java.

What you mean with "static stuff" is done by assertions, which are a standard feature in C and C++.

http://www.cplusplus.com/reference/cassert/assert/

Boost++ contains some nicer extension there:

http://www.boost.org/doc/libs/1_61_0/libs/assert/assert.html

 

[GLS]

I had done the same once, but I was pretty disappointed by Cppcheck in the process, because it tolerated too much IMHO... I am used to more complaints from FindBugs in Java.

What you mean with "static stuff" is done by assertions, which are a standard feature in C and C++.

http://www.cplusplus.com/reference/cassert/assert/

Boost++ contains some nicer extension there:

http://www.boost.org/doc/libs/1_61_0/libs/assert/assert.html

Yeah, I've used the assert in several places. I was thinking we had to disable that "manually" with NDEBUG for release version (hence my limited use of it), but it looks like VS already does that for us. I'll add more asserts then.

 

[Urwumpe]

Yeah, I've used the assert in several places. I was thinking we had to disable that "manually" with NDEBUG for release version (hence my limited use of it), but it looks like VS already does that for us. I'll add more asserts then.

Feel free to do so. I suspect correctly that you are informed about the concept of pre-conditions, post-conditions and loop invariants?

 

[GLS]

Feel free to do so. I suspect correctly that you are informed about the concept of pre-conditions, post-conditions and loop invariants?

Maybe not formally... :uhh: I'll start with function arguments, and go from there.