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

[DaveS]

So any suggestion on how I can repair my SSU?

Just do an SVN update. I've checked in fixed files that will work with VS2017 Community.

 

[Urwumpe]

Just do an SVN update. I've checked in fixed files that will work with VS2017 Community.

And won't work with VS2019 Community.





I am going to build my own Space Shuttle with Blackjack and Hookers. :facepalm:

 

[DaveS]

And won't work with VS2019 Community.

That's why I told you to create VS2019 specific files and check those in. Then nothing would be broken, either for VS2017 or VS2019.

 

[Urwumpe]

That's why I told you to create VS2019 specific files and check those in. Then nothing would be broken, either for VS2017 or VS2019.

Until we add a new source file in 2019 and everybody is wondering again, why 2013 is no longer building. Or why 2017 can't handle the source code of the new source files.



I have better things to do with my time than maintaining a second build system.

 

[DaveS]

I have better things to do with my time than maintaining a second build system.

I'm surprised that a seasoned developer such as yourself doesn't seem to recognize this, but there's no maintenance of them. You create them once and then forget about them. They're not source files, they don't change daily or how often you open them. The VS2017 *.vcxproj files had been untouched for years until you changed them. I've no problem you change them locally to work for you in VS2019 Community, but where you erred was checking those changed files in, breaking them for the rest of with out telling us that we needed to switch over to VS2019.


The files did have the suffix _2017 after all.

 

[Wolf]

Just do an SVN update. I've checked in fixed files that will work with VS2017 Community.

Unfortunately it doesn't seem to work for me. Recompile not completed (2 items failed)

 

[Urwumpe]

I'm surprised that a seasoned developer such as yourself doesn't seem to recognize this, .....

That's it.



I am getting too old for this .

 

[DaveS]

Unfortunately it doesn't seem to work for me. Recompile not completed (2 items failed)

View attachment 17160

Seems like you have a broken set up there. It's complaining about something not being declared properly both in SSU and the general Orbiter SDK. As we haven't even touched the OSDK files, something bigger than SSU is at fault here. The only advice I can really give you is to re-install Orbiter and SSU.


On a related note, VS2019 appropriate project files have been checked in and verified to working. Atlantis_VS2019 is the solution for those that want to use VS2019 instead.

---------- Post added at 01:37 AM ---------- Previous post was at 12:32 AM ----------

That's it.



I am getting too old for this .

You are out too? I guess that's it for SSU then. I'll close this thread upon confirmation.

 

[Urwumpe]

You are out too? I guess that's it for SSU then. I'll close this thread upon confirmation.

Why? You are doing the C++ development now. Feel free to keep on ignoring the complaints from us dinosaurs and do as you please. I obviously lack a lot of skills needed for the project, especially the one for being able to swallow a lot of .



Now you can do everything your way, it is your one-man-show SSU. If you want to kill it, it is your decision. I was already out of the project and did not contribute much in the past years, I am sure not going to overstay my welcome.

 

[STS]

Guys, I don´t understand anything. What happened here? As I read, I understand that whatever the problem is, it is present for years. How can this be?

 

[Urwumpe]

Guys, I don´t understand anything. What happened here? As I read, I understand that whatever the problem is, it is present for years. How can this be?

From my point of view:

1. Who does not develop the C++ part of SSU should not tell those who do, which version of the compiler they must use.
2. We had big problems in the past ten years with people needing to use some obsolete Visual Studio and requiring maintaining two build systems.
3. Instead of learning from the past trouble we had with VC 2008 to VC 2015, some non-developers is insisting on keeping the old build files.
4. We could now use CMake now, like Microsoft also does for their C++ projects and which Visual Studio even supports natively, to get out of the version dependency of the MS project files.
5. And CMake has no problems with Orbiter projects, as I can tell after testing it in other projects.
6. Still #1 should apply there.
7. Since VCPkg has a very good CMake integration, we could also use this as package manager for installing the C++ dependencies of SSU.
8. And in this special case, I am especially disappointed of DaveS messing around with the project without even caring about the development. He treats it as a one-man show, fine, he has a one-man show.

 

[Wolf]

So in case I wanted to fix my issue with a fresh new install using "SSU_nightly_v5.0r3253"
after downloading and launching VS2019 which repository URL should I use for the SVN to compile SSU?

 

[Urwumpe]

So in case I wanted to fix my issue with a fresh new install using "SSU_nightly_v5.0r3253"
after downloading and launching VS2019 which repository URL should I use for the SVN to compile SSU?

Try "svn://svn.orbithangar.com/shuttleultra/trunk"

 

[DaveS]

From my point of view:

1. Who does not develop the C++ part of SSU should not tell those who do, which version of the compiler they must use.
2. We had big problems in the past ten years with people needing to use some obsolete Visual Studio and requiring maintaining two build systems.
3. Instead of learning from the past trouble we had with VC 2008 to VC 2015, some non-developers is insisting on keeping the old build files.
4. We could now use CMake now, like Microsoft also does for their C++ projects and which Visual Studio even supports natively, to get out of the version dependency of the MS project files.
5. And CMake has no problems with Orbiter projects, as I can tell after testing it in other projects.
6. Still #1 should apply there.
7. Since VCPkg has a very good CMake integration, we could also use this as package manager for installing the C++ dependencies of SSU.
8. And in this special case, I am especially disappointed of DaveS messing around with the project without even caring about the development. He treats it as a one-man show, fine, he has a one-man show.

1)OK, I'll own this one completely for missing the note about VS2019 in the commit log.
2)Did we? I can't remember this.
3)See 3). Addendum: I'm all for getting rid of unused stuff, be it code, meshes or textures. Just a heads up first before comitting that will break something, like the build process.
4)Why haven't we made use of CMake? What has been the hold back?
5)See 4).
6)See 1)
7)No comment due no prior experience with it.
8)I did ask before hand: https://www.orbiter-forum.com/showthread.php?p=607296&postcount=2997
And I took your "If you are planning to do the development...." statement to be about the project files, nothing else. I think everyone needs to be clearer as to what exactly they mean as while we're using a common language (English) we're still translating our original thoughts from our native languages to English, so the saying "it looses something in the translation" applies. Something that's also lost due to the text-based medium we're using is the tone. So what was originally intended in a friendly way could very easily be mistaken for being the opposite due to the two above mentioned factors. And me not caring about the development? I really do. I spend a lot of time working on the 3D models and textures, would I do that if I didn't care? Again, I feel I'm still wrong here, and the statement is about the code part. I do care about it, I just don't know how to show that being a non-coder.

There must be room for disagreements about things with everything blowing up every time, any ideas how we can these things better? I'm all ears.

This post was written to be as well-meaning as possible so please don't take anything the wrong way.

 

[Urwumpe]

For 4) The answer is quite simple: It wasn't available for Windows and Visual Studio.

It was a Linux tool, a replacement for the classic autobuild tool. AFAIR, the first version supporting Visual Studio appeared around 2012. The native Visual Studio support appeared first around 2016, for the 3.10 version. VcPkg was first released in 2016.

So far, only few people here in the Orbiter world experimented with CMake, despite it already being industry standard for C++.

 

[DaveS]

For 4) The answer is quite simple: It wasn't available for Windows and Visual Studio.

It was a Linux tool, a replacement for the classic autobuild tool. AFAIR, the first version supporting Visual Studio appeared around 2012. The native Visual Studio support appeared first around 2016, for the 3.10 version. VcPkg was first released in 2016.

So far, only few people here in the Orbiter world experimented with CMake, despite it already being industry standard for C++.

OK, so the reason why didn't go the route of using CMake was that no version supporting Windows/VS was available until 2016? That explains that and why there's no widespread CMake usage in the Orbiter community, Orbiter is of course a Windows-native application. And it has been my feeling that most programmers around here are more familiar with code development in Windows.

 

[Urwumpe]

That explains that and why there's no widespread CMake usage in the Orbiter community, Orbiter is of course a Windows-native application. And it has been my feeling that most programmers around here are more familiar with code development in Windows.

It is what Microsoft calls Windows Development in C++ today. Technology progresses. And it is not too bad to save some extra work with proper automatisation. Its not like we need to reinvent the wheel again today.

https://github.com/Microsoft/vcpkg/

https://cmake.org/


Also, we have quite many Linux veterans here, that sure know CMake and its alternatives in the Linux world.



In theory, we could even separate the development workspace from the Orbiter installation and no longer need to install Orbiter into the SSU working copy. Would have the advantage that its easier to catch missing files, since everything that is not on the list for CMake would not be copied into the testing installation of Orbiter then - and old files automatically removed.


I had a test project on my old Notebook, I will try recovering it for some examples. Its no black magic, automatically producing a NSIS Installer package from an Orbiter project is quite easy.

---------- Post added at 13:41 ---------- Previous post was at 10:03 ----------

About the "There must be room for disagreements about things with everything blowing up every time":

I don't see that the project is in any state for allowing careless handling without everything blowing up. We have tons of bugs, lots of historic ballast and our processes are at best at CMMI Level 0. It had been bad in the past, but never THIS bad. From a pure engineering point of view, the project has a near-death experience.

Next, there is the social interaction. Not respecting responsibilities and maintaining transparence is one aspect.

I admit that I should have been communicating clearer in advance, that I consider using the currently available compiler toolchain is standard, not some past version, unless there is a good reason for that.

But that is no excuse to be disrespectful towards others for defending the old compiler version. That is not about language barriers, but about getting uncomfortably personal for discussing technical problems.

Its a freetime project. Nobody HAS to be here. We all should have a commitment to the project, but that is not infinite or essential. Especially, I don't think anybody should commit himself more than really needed.

So, how to get out of this?

The technical problems can easily be solved by technical solutions, as explained.

Its harder with the human problems. We have to do some basic tasks, that we managed to avoid in the past years.

We should define some social project rules (or project constitution) for project members and contributors. Not just some netiquette, but also a definition, which project roles we have, which responsibilities they have and what will be decided.

Some things that I would suggest there, not really structured:

• A short Project Goal to start, with a link to a more detailled project vision.
• No personal attacks, no strong words, no secret agenda.
• The license decision should be repeated there.
• Who does not contribute, does not decide.
• This includes video tutorials and mods, which are not part of the project, but part of the SSU community.
• A project moderator should be available to moderate disputes and deescalate
• Problems should be mentioned when they appear, not when somebody else notices them as well.
• There should be a regular discussion thread about the features for the next milestone. It should get closed after the discussion is over and the decision for the mile stone be written into the wiki.
• No changes to the repository without a ticket that requires it.
• Commit messages should refer to the ticket
• A commit should be for a single ticket, not multiples
• C++ code should conform to the coding standards of SSU
• It should be possible to test SSU by just installing its package into Orbiter.
• We have an product owner, who is responsible for the tickets, the milestones and the quality of both.
• The product owner represents the whole team. He does not decide features or bugfixes himself, but makes sure that those decisions of the team will be implemented.

 

[Wolf]

Try "svn://svn.orbithangar.com/shuttleultra/trunk"

Sorry if I am derailing from the main (hot) topic here, just one final question: Unfortunately the VS2019 compile did not work.



I will give it a last try and if it still fails amen: bye bye SSU

So if I revert to VS2017 (fresh new SSU and Orbiter install) what is the URL to use for the VSN to compile?

 

[DaveS]

It should be svn://orbiter-radio.co.uk/shuttleultra/trunk.

And the VS2019 files should be good, no issues with them here.

 

[DaveS]

Just checking in here, how is the JSON work coming along?