Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

I agree with that. My concern is that the zip release will be missing a lot of files compared to the SVN 'release'.

For future development, I'd prefer to keep most of the changes in the trunk, and reserve branches for features which might disrupt other work done on SSU and bugfixes which need to be applied to the trunk and releases. The trunk is pretty stable already, and I don't see a need to maintain it as a 'tested complete version'; if we're going to create a tested complete version, we may as well release it.

I think it would be better to start developing every new feature for SSU in a branch and eventually integrate it into the trunk once it is not breaking it.

Also, we should include some stubs into SSUs source code for getting some fake constant data from subsystems that are not yet in use. When a new feature is done, we just replace the stub by the subsystem.

 

[Face]

Sorry for chiming in so uninvited, but I'd like to give you a warning from my experience with SVN's tags. In SVN, a tag is nothing more but a copy of the trunk at a given time into a separate directory in the tags folder of the root (although this could of course also be called "releases" or whatever). Now there is nothing wrong with this, but the trouble is that nothing stops you from committing into that folder, if you don't have some hooks installed that prevent it.

So if you rely on tags to get back to a certain code state (because you e.g. have no sources in a release zip), you should keep in mind that without additional blocks in place a checkout of a tag is not guaranteed to get you just that. Chances are that some commiter mistakenly committed into the tag folder, and perhaps did not even realize it.

It may sound like there have to be too much things going wrong to get this scenario, but in every SVN repo I have seen with more than one developer, this happened at least once.

Congrats on the upcoming release, BTW! That has been quite some work, folks!

 

[kuddel]

...Now there is nothing wrong with this, but the trouble is that nothing stops you from committing into that folder, if you don't have some hooks installed that prevent it.

Right! One should always prevent commiting to tags by instantiating protective hooks! This is one of the first things I do when creating a new SVN-repository.
And if you still feel you need some more security (or are unable to install hooks), add the revision number into the build process, that number is 'unique'! So "tag/1.2.3.4(r9976)" will always mark that specific revision even if someone commited afterwards.

/Kuddel

 

[Face]

And if you still feel you need some more security (or are unable to install hooks), add the revision number into the build process, that number is 'unique'! So "tag/1.2.3.4(r9976)" will always mark that specific revision even if someone commited afterwards.

Well, if you put the revision ID into the binaries, you can always get them without a tag at all. IMHO the purpose of a tag is to mark a certain revision ID with an easy remembered name. If this is not ensured, the tag failed and might be even misleading.

 

[Hlynkacg]

Not sure if this is the place to ask but...

I've been eyeing some of SSU's assets, code scraps, textures, etc... for use in my own addons and was wondering what your guy's "fair use" policy was if you had one.

For instance those chunky ol' CCTV monitors in SSU's VC would make great "Apollo-era" MFDs

 

[Urwumpe]

Not sure if this is the place to ask but...

I've been eyeing some of SSU's assets, code scraps, textures, etc... for use in my own addons and was wondering what your guy's "fair use" policy was if you had one.

For instance those chunky ol' CCTV monitors in SSU's VC would make great "Apollo-era" MFDs

Generally, the source code is GPL, so no problem reusing it, if you also release your add-on under a GPL license.

The rest of the stuff - well, thats a bit more complex since it is hard to apply GPL rules also to it. But I would leave this to the team. For example, the mid-deck is also used in SSM, despite it not being GPL software, but cleared for use by the artist.

If you for example want to use the crawler for your add-on, or have interest in a VAB collaboration, we can sure find a solution that works for you and us.

It is also possible, that we will one day finalize libUltra, a library of common classes in the SSU project, to be used in other add-ons.

 

[Hlynkacg]

Well then I suppose I should ask...

I'm working on re-building my Virtual cockpits for AAPO as well as generating new ones for some of the alternate history vehicles (Apollo-derived CRV, Lunar Hab Module, etc...). I currently have some bits in there that were "borrowed" from SSU, specifically your guys' COAS reticle and some material specs/textures.

Who do I talk to about permissions and proper credit?

And while I haven't gotten into it yet I will be looking at the Crawler/MLP and VAB some time in the future.

 

[Donamy]

I made the COAS stuff, and if no one else has any problems with it. Go ahead and use it.

 

[Hlynkacg]

Cool, than you :tiphat:

Credit will be included in documentation.

 

[Izack]

It is also possible, that we will one day finalize libUltra, a library of common classes in the SSU project, to be used in other add-ons.

That would be fantastic; I've been watching the source too, lately, and finding myself reinventing wheels here and there, at a much slower pace.

 

[SiameseCat]

Leaving aside the discussion of future work, I do think that the release should include everything in SVN, with the possible exception of the Orbitersdk folder and parts of the Doc folder. The main reason for this is so that, if a bug is reported a month from now, we can easily go back to the revision that was released and investigate. If we're leaving some files out of the released package, this could make debugging much harder.

Can someone take a look at this release zip: https://dl.dropboxusercontent.com/u/64239213/SSU Version 2.0.zip
I've included all files except the Doc/SSU/Technotes folder. I've also included a few last-minute changes which I checked in to sourceforge (preventing SSU from overwriting Orbiter's default bases) and ensuring that all scenarios use the correct config file.

I've added a readme file containing installation instructions; it would be nice if someone could take a look at this.

Has anyone had a chance to look at the release zip yet?

 

[DaveS]

Has anyone had a chance to look at the release zip yet?

I recommend changing the recommendation for hi-res KSC to this instead: [ame="http://www.orbithangar.com/searchid.php?ID=5583"]KSC hires tiles[/ame]

The package is good, no CTDs. I would still like to see tickets 33 and 26 included.

 

[SiameseCat]

I'd prefer to get this version released, then work on the other tickets. Ticket 33 in particular should wait until we add the new meshes.

 

[DaveS]

I'd prefer to get this version released, then work on the other tickets. Ticket 33 in particular should wait until we add the new meshes.

How are we going to handle the new meshes? As a patch to the release version or hold them for the next major version?

 

[Urwumpe]

How are we going to handle the new meshes? As a patch to the release version or hold them for the next major version?

Hold them for the next major or minor version and release them properly, I would say. Especially, no new features or tickets into this release. Better have two known bugs than adding 10 unknown ones.

 

[DaveS]

Hold them for the next major or minor version and release them properly, I would say. Especially, no new features or tickets into this release. Better have two known bugs than adding 10 unknown ones.

I agree. I just wanted to know so there wouldn't be any surprises.

 

[Urwumpe]

We could always push for a small release in a shorter time, we should just use the last days of 2013 for working out, which features we want to put into the next release and keep that number of new additions small.

The less we are going to add and the less we have to test, the faster we can do the next update. Small iterations are always better than big ones - but not everything can be done in small steps. Sooner or later, we might again need a huge leap for a small project team.

Just adding only the new meshes in the next release might be possible to do in a few weeks, not more than 2 months.

 

[SiameseCat]

Can someone upload the release zip to Orbithangar? My internet connection is too slow. The file is at https://dl.dropboxusercontent.com/u/64239213/SSU Version 2.0.zip. The readme file has been updated, so make sure you use the latest version.

 

[DaveS]

Can someone upload the release zip to Orbithangar? My internet connection is too slow. The file is at https://dl.dropboxusercontent.com/u/64239213/SSU Version 2.0.zip. The readme file has been updated, so make sure you use the latest version.

I tried but the OHM uploader always returns an error about that the description field was left empty. I have tried three times now with no luck. I sent an e-mail to Vash about this so hopefully it will be resolved soon.

 

[Xyon]

I tried but the OHM uploader always returns an error about that the description field was left empty. I have tried three times now with no luck. I sent an e-mail to Vash about this so hopefully it will be resolved soon.

For quick support, even with OHM bugs, you can file tickets under the Site Support section here on OF. We'll then assign staff as appropriate, and everyone involved will get lots of prodding to fix it (which includes me).