Project WIN Ascension Ultra BETA test thread

[wehaveaproblem]

WIN Ascension Ultra OPEN BETA test thread

UPDATE: Tuesday 8th July 2014 - BETA 0.4 has been released and now the BETA has been classed as OPEN to all. Latest info in post no.191


:tiphat:

So as mentioned in the WIN AU dev thread, it is now time for beta testing! Therefore, this is a shout out for anyone who would like to get involved with this process.

Now, despite the protracted development period, this project has not actually taken years to create, and it is still VERY MUCH BETA, with lots of work still to do.

Therefore, you will not just be testing “WHAP's new WIN”, but perhaps more importantly testing the tools Face is developing, which provide the base's functionality. Ascension Ultra is the test bed for these tools. Ultimately AU will become the flagship base, not only being the most advanced Orbiter base to date, but showcasing the tools which will be made open source, so that others can use them to create their own bases.

Therefore we are asking you to not only test the aesthetics and usability of AU as a spaceport, but also the coded functionality, to identify bugs and suggest improvements/features. This process will only work if you can provide us with constructive feedback and proper bug reports. If you want to just 'play' with AU, then I suggest you wait for the full release, once beta is complete. If you are willing to help us test it, then I give you my thanks in advance for your time and effort.

So, if you have read this far, you may be the kind of person we need! The first beta release will not be made available until next week, but I wanted a few days to attract attention before then.

If you are interested in joining the beta team, then please PM me accordingly. Next week, I will reply to all successful applicants with the relevant download link.

The beta test will take as long as it takes, and we plan to release a new version at least once a month, with each release having whatever new features and fixes have been developed since the last. This thread will become the place for all discussion and feedback of the beta releases.


Thanks,

WHAP & Face

 

[Mojave]

I'll do it!

But I can't really do any kind of testing until next week. :tiphat:

 

[RisingFury]

Well, for those of you who, in your infinite excitement, only bothered to read the title, but not the main text of the body:
- If you wanna test the add-on, send wehaveaproblem a PM.
- wehaveaproblem will only give out the link for the add-on next week.

 

[Mojave]

Who's to say I didn't?

 

[RisingFury]

I do have a few questions about the testing process that I've worked up during the last few days:
- Are we allowed to post publicly the features, screenshots / video and bug reports, or should we do any of those over a PM?
- Are we allowed to post reviews of the work in progress?
- The beta is closed, so no redistribution of this add-on. Correct?

 

[wehaveaproblem]

Yo RisingFury, cheers for the questions.

You have pre-empted me posting here, essentially with the answers to your questions... All this info, and more, has been included in a fairly comprehensive docu, which you will get as part of the download, but let me answer your questions here, now.

This applies for the whole Beta Team (you know who you are).

- Are we allowed to post publicly the features, screenshots / video and bug reports, or should we do any of those over a PM?
Yes, I ask that all feedback be shared here in this thread for all to see. Any bugs reported, that are recognised as bugs, will also then be added to our repo as an issue. We will ask your help with this, if you are comfortable doing so.

- Are we allowed to post reviews of the work in progress?
Do you mean here, or on a 3rd party blog for example? I'd prefer stuff to stay on OF or our repo for now, but all advertising is good advertising after-all! So let me know what you plan and I'll give you a more concrete answer.

- The beta is closed, so no redistribution of this add-on. Correct?
The beta is technically closed, but not kept behind closed doors per se. The reason it is as closed as it is, is merely because we want a smaller, focused team at this stage, rather than a roomful of orbinauts all shouting at once. Also, I have tried to select a range of users to cover a range of feedbacks so to speak. So yes, please don't redistribute at this time, so I know who has what. As we get closer to a release version I will open it up for anyone to play with.


Lastly, Face and I will be making all the final preparations tonight, so all testers will receive a PM from me later some time today with all the info you need to get cracking.

Any more questions, feel free to fire away, although hopefully my PM and the docu will answer them for you.

 

[csanders]

Done with some preliminary tests.

All I have to say is.. Wow! Excellent work!

I love the taxi lights directing you where to go.

So far I haven't experienced any crashing, or wonky behavior by the MFD. Seems solid so far. The only issues I've experienced have to do with 3D rendering, and I'm not sure how much you can do about them.

The first issues is that when looking onto the base from an "internal" view. In this case it's from the control tower.

The problem is if a craft is flying in front of a mesh that is part of the base. Orbiter seems to render the base meshes last (when viewed from an "internal" view), so even though this DGIV is in front of those shacks, the shacks get rendered over the DGIV.

DGIV with experimental cloaking device...

This problem doesn't exist in the "external" view though.

---------- Post added at 02:27 PM ---------- Previous post was at 02:12 PM ----------

It might be related to this.

View on DG, from inside hangar:

Looking through hangar glass:

This problem gets weirder:

On startup, the default DG renders fine:

After adding a second one, they both disappear behind glass:

But in front of the glass they're fine:

Now I exit Orbiter and the launchpad. Restart the launchpad and select "current state," and the original DG reappears:

---------- Post added at 02:35 PM ---------- Previous post was at 02:27 PM ----------

Interesting Observation: In the "current state" scenario file from above, the vessels were listed as:

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Landed Earth
  POS -14.4097270 -7.9467280
...stuff
END

AU-Main:AscensionUltra
  STATUS Landed Earth
  POS -14.4050000 -7.9550000
  HEADING 220.00
...stuff
END

dg-02:Deltaglider
  STATUS Landed Earth
  BASE Wideawake Intl(AU):2
  POS -14.4098470 -7.9466480
...stuff
END

When I changed it to:

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Landed Earth
  POS -14.4097270 -7.9467280
...stuff
END

dg-02:Deltaglider
  STATUS Landed Earth
  BASE Wideawake Intl(AU):2
  POS -14.4098470 -7.9466480
...stuff
END

AU-Main:AscensionUltra
  STATUS Landed Earth
  POS -14.4050000 -7.9550000
  HEADING 220.00
...stuff
END

This happened:

 

[jgrillo2002]

I can confirm the Interior bugs when looking at vessels too.

 

[Face]

Thanks for the detailed report, guys. I must admit, thought, that we already know this. It is a problem with the transparency rendering in Orbiter.

There is not much we can do about it ATM, although I've experimented with a dynamic "glass-reloader" that simply deletes and adds the transparency sections again after a vessel gets added. Unfortunately it did not yield the expected results. Seems like the exact vessel order is important, so it would be necessary to add a second "glass-vessel" to the stack that gets deleted and re-spawn with every vessel add.

I think this is worth to be added as issue to the tracker, so I can re-visit it later in development. Anyone willing to do that, or should I add it myself?

 

[wehaveaproblem]

Thanks for the first feedback gents. Glad she seems to be holding together!

As to the issues you are describing, they are due to the transparent vessels and the way they are rendered by the graphics engine. Basically, the order the vessels are loaded effects whether they can be seen through transparencies. This is unavoidable to a certain degree. We have split the buildings and their windows into separate meshes, and all windows are loaded after all buildings, which means all buildings are visible through all windows. Whilst this resolves some of the problem, it does not fix the issue directly. The problem comes when you add vessels to the scn after the base vessels. This is illustrated well in your pics and logs csanders.

As you saw, if the ships are rendered first, the problem goes away. In the short term, only editing the scn file manually will work around this, but I will talk to face about the possibility of the module doing something fancy with the scn file on load up, if AU is not the last vessel in the list... but I'm not sure how doable this is. It will also make no difference to when you add a vessel via the scn editor. But I don't believe anything can be done about the scn editor issue.

Does that all make sense?
face will let me know if I'm wrong!


edit: damn too late! What face said!

 

[RisingFury]

First impression:
Wow!!!

Though we'll see how she handles my computer.

It really is a heavy hitter when it comes to performance. I have a 7 year old computer that I'm testing AU on, specs:
AMD Athlon 3000
GeForce 6600 GT
1.75 GB of RAM

When this base is loaded, Orbiter runs at about 25 FPS. Though hopefully by now my computer is pretty much the worst thing around, except for laptops and people with integrated graphics cards, so hopefully there won't be any issues.


Bugs / suggestions / derp:

Minor suggestion:
AscensionTower module, listed under Miscellaneous in Modules has no description, if you click on it.

Minor suggestion:
If you select a hangar door and set it to open / close, then hit stop, the animation stops, but the MFD still says "Moving". Not sure if this is intentional or not, but it might be a good idea to have it display "Stopped" or something like that.

Minor suggestion:
When zooming out of the island to a distance of about 2400 km, Orbiter replaces the AU bug with a red sprite. That's normal Orbiter functionality - but I do suggest that the color of the sprite be changed to brown, or whatever the average color of AU is when seen from far away.

Minor bug (intentional?):
Roster -> Add new person -> Function only shows first 4 letters of whatever you write. I'm not sure if that's a bug or intentional...

Minor bug (not your fault?):
When a UMMU enters AU, it creates a debug text line. Yuck! Though I'm not sure if that's in your code or if UMMU functionality. If you have the ability to remove the line, I suggest you do...

Minor suggestion:
The MFD should have a button to instantly stop the taxi lights, instead of having to un-select the start or end point of the taxi lights. Also, I suggest that the moment you select the taxi lights and they start working, you instantly jump back to the taxi lights screen instead of having to press Back twice...

Minor suggestion (WIP?):
There is a Crane online / Crane offline debug string when playing around with the crane. It should be gone in the final release, but documentation states this is a work in progress...

Minor bug / suggestion:
If you select AU in the F3 screen and press F1 to go to internal view, you go into a little observation room. If you look left or right, you see the two walls on the side are smudged.
That entire room is kind of dull as well and I didn't even see a door for people to enter, so might wanna work on it a bit.

Major suggestion:
Performance is a big thing and AU is about as low as add-ons get when it comes to performance. As I said, my computer gets 25 fps. But that's only with AU and a single DG loaded. I don't even dare bring an XR2 into the mix, or even think about multiple vessels. AU isn't the only add-on people will run at one time and there are several add-ons that require high FPS in order to function properly - mainly autopilots. Orbiter's aerodynamics also gets a bit... jittery at low FPS and vessels tend to violently rotate.

So here's a suggestion:
If you go far enough from the base, the mesh gets unloaded. Orbiter does that when it determines that the mesh can no longer be visible. If I remember correctly, the vessel's Size parameter determines how far away from the vessel you have to be, in order for its mesh to unload.

I suggest you manipulate the Size in real time to load and unload the base when it is in sight of the camera - for example: If the camera is facing away from the base and no part of the base can be seen inside the FOV of the camera, the Size parameter can be reduced a lot, so the base's mesh unloads.
Another condition where the base can be unloaded is if the base is within the FOV of the camera, but the base is below the horizon from the camera's perspective.

Currently the base turns into a sprite at about 2400 km distance and unloads at about 12 000 km distance. That means that if you're anywhere on Earth, the base is loaded and draining lots of FPS, even if you can't see it.


I think that concludes the first testing session for the day. I went mostly through the MFD, played around with doors and other animations...

I must say that both visually and interactively, this base is already by far the best base Orbiter has seen, despite the fact that it's a work in progress. I think that not only does this base and the underlying technology have the potential to dominate the top range of Orbiter bases, but I would strongly suggest that the features we see here get implemented into Orbiter in a future release.

 

[Hlynkacg]

The only issues I've experienced have to do with 3D rendering, and I'm not sure how much you can do about them.

The first issues is that when looking onto the base from an "internal" view. In this case it's from the control tower.

The problem is if a craft is flying in front of a mesh that is part of the base. Orbiter seems to render the base meshes last (when viewed from an "internal" view), so even though this DGIV is in front of those shacks, the shacks get rendered over the DGIV.

I've encountered this issue in my own addons (pay load bay rendering OVER the payload) and there is a solution. You need to set the mesh's visibility flag to "MESHVIS_EXTPASS" when in cockpit view. :thumbup:

 

[Screamer7]

This is just awesome.
The taxi lights puzzle me.
They show the "green follow lights to runway 13 left and right thresholds from runway 31 along the whole length of the taxi way.
But when I select runway 31 from the AU tower MFD, the lights does not show all the way from runway 13 to runway 31 along the taxi way.

Only the last part of the taxiway to runway 31 show the green follow taxi lights.

Although I tested AU with a clean install of Orbiter 2010P1, I also try it out with a "crowded" installation.
I know there will be many who will install it on top of their existing Orbiter installation.
There are no conflicts what so ever.
The night lights also look very good.
No problems as far as I can see.

Edit:
Taxi Lights not go all the way to Runway 31 L and R
http://www.orbiter-forum.com/attachment.php?attachmentid=10398&stc=1&d=1343176334

Taxi Lights go all the way to Runway 13 L and R
http://www.orbiter-forum.com/attachment.php?attachmentid=10399&stc=1&d=1343176334

 

[csanders]

One minor aesthetics thing:

When choosing a roll-in/roll-out facility, a list comes up as:

Launch Facility
 1. Vertical Launch Facility
 2. Vertical Launch Facility

At first I thought the "Launch Facility" line was just a header, and not a choice. Perhaps number it even though there is only one? Of course that might look silly.

 1. Runway Launch Facility
 1. Vertical Launch Facility
 2. Vertical Launch Facility

That said, I thought the MFD was pretty easy to figure out. I can't wait for the crane to become operational.

 

[Hlynkacg]

Minor Suggestion: Label the doors on the meshes them selves.

I spent a good 3 minutes parked in the hangar opening random doors before I figured out which one I was actually parked in front of :lol:

 

[csanders]

Minor suggestion:
The MFD should have a button to instantly stop the taxi lights, instead of having to un-select the start or end point of the taxi lights. Also, I suggest that the moment you select the taxi lights and they start working, you instantly jump back to the taxi lights screen instead of having to press Back twice...

Good suggestion.

Anyway, when I request a taxi "From runway" to "Storage Hangar," the taxi lights in front of the storage hangars are going backwards.

Some more very minor aesthetics - the list for taxi from airport to runway is:
1. 13L
2. 31R
3. 31L
4. 13R

Perhaps group the two sides together like so?
1. 13L
2. 13R
3. 31L
4. 31R

 

[Face]

• AscensionTower module, listed under Miscellaneous in Modules has no description, if you click on it.
• When zooming out of the island to a distance of about 2400 km, Orbiter replaces the AU bug with a red sprite. That's normal Orbiter functionality - but I do suggest that the color of the sprite be changed to brown, or whatever the average color of AU is when seen from far away.
• Roster -> Add new person -> Function only shows first 4 letters of whatever you write. I'm not sure if that's a bug or intentional...
• When a UMMU enters AU, it creates a debug text line. Yuck! Though I'm not sure if that's in your code or if UMMU functionality. If you have the ability to remove the line, I suggest you do...
• Also, I suggest that the moment you select the taxi lights and they start working, you instantly jump back to the taxi lights screen instead of having to press Back twice...

Thanks for the reports, those could be marked as issues for implementation in the next round.

If you select a hangar door and set it to open / close, then hit stop, the animation stops, but the MFD still says "Moving". Not sure if this is intentional or not, but it might be a good idea to have it display "Stopped" or something like that.

The door page is really only a stub ATM. It will be replaced with a graphical display showing the percentage of movement eventually, so I'd like to postpone this suggestion.

The MFD should have a button to instantly stop the taxi lights, instead of having to un-select the start or end point of the taxi lights.

The idea here is to have the reset button doing the work of switching off lights instantly.

There is a Crane online / Crane offline debug string when playing around with the crane. It should be gone in the final release, but documentation states this is a work in progress...

Yes, it is due to WIP. I guess I'll report the WASP-mode keys/states with Orbiter's note display system eventually.

If you select AU in the F3 screen and press F1 to go to internal view, you go into a little observation room. If you look left or right, you see the two walls on the side are smudged.
That entire room is kind of dull as well and I didn't even see a door for people to enter, so might wanna work on it a bit.

That room is the tower in the LFMC. I'll happily forward the design suggestions to WHAP.

Performance is a big thing and AU is about as low as add-ons get when it comes to performance.

Yes, we know that. Actually the plan for LOD features was in right from the beginning, I was just to lazy to actually code them. The idea here is to not only change details with distance of observer, but also based on settings in the configuration. I.e.: low-spec machines could e.g. disable beacons or certain building types.

I've encountered this issue in my own addons (pay load bay rendering OVER the payload) and there is a solution. You need to set the mesh's visibility flag to "MESHVIS_EXTPASS" when in cockpit view. :thumbup:

That's a good idea, although maybe not helping in the external view case. I'll try it, thanks for the hint!

This is just awesome.
The taxi lights puzzle me.
They show the "green follow lights to runway 13 left and right thresholds from runway 31 along the whole length of the taxi way.
But when I select runway 31 from the AU tower MFD, the lights does not show all the way from runway 13 to runway 31 along the taxi way.

Only the last part of the taxiway to runway 31 show the green follow taxi lights.

Well, here I'd like to hear WHAP's comment on whether this is intentional or just me messing up the INI file...

When choosing a roll-in/roll-out facility, a list comes up as:

Launch Facility
 1. Vertical Launch Facility
 2. Vertical Launch Facility

At first I thought the "Launch Facility" line was just a header, and not a choice. Perhaps number it even though there is only one? Of course that might look silly.

 1. Runway Launch Facility
 1. Vertical Launch Facility
 2. Vertical Launch Facility

What about indention? Maybe it is just the missing spaces in front of the string that made you think it's a header. "Runway Launch Facility" sounds good, I'll see how it looks.

That said, I thought the MFD was pretty easy to figure out. I can't wait for the crane to become operational.

Thanks for that feedback. It is really important for us to know whether or not the MFD approach works out. As you all know, MFD pages for that kind operations are rather frowned upon. In this case, though, the idea of having it as dialog felt also wrong somehow.

Minor Suggestion: Label the doors on the meshes them selves.

I spent a good 3 minutes parked in the hangar opening random doors before I figured out which one I was actually parked in front of :lol:

Certainly a good idea. I'd also forward that to WHAP...
Could a small visual hint in the MFD help here, too? Maybe just placing the cursor onto the hangar your vessel is nearby currently? Or a little text note at the bottom with e.g. "Location: 2. Turnaround Hangar"...


Many thanks for the feedback, guys!

 

[csanders]

What about indention? Maybe it is just the missing spaces in front of the string that made you think it's a header. "Runway Launch Facility" sounds good, I'll see how it looks.

I think that would work. "Runway Launch Facility" also gives it a mental separation from the "Vertical Launch Facility" - so it won't seem like a header.

 

[wehaveaproblem]

Great feedback chaps, thank you!

I shall attempt to comb through it all and answer things. Face has answered some, we me double up, I may miss some stuff.. So if I miss a question/suggestion, please point to it again.

When this base is loaded, Orbiter runs at about 25 FPS. Though hopefully by now my computer is pretty much the worst thing around, except for laptops and people with integrated graphics cards, so hopefully there won't be any issues.

TBH that's better than I expected! I know some people may struggle with AU, hence why we plan the LoD features Face has already mentioned, but that will come after all 'physical' content is in.

RisingFury, thanks for the detailed post. Face has answered many technical things, so that leaves me with:

Minor bug / suggestion:
That entire room is kind of dull as well and I didn't even see a door for people to enter, so might wanna work on it a bit.

You are correct it is very dull, I just haven't got around to texturing the guts there. There is more detailed planned for the whole of the LFMC insides, so it will come.

I must say that both visually and interactively, this base is already by far the best base Orbiter has seen, despite the fact that it's a work in progress. I think that not only does this base and the underlying technology have the potential to dominate the top range of Orbiter bases, but I would strongly suggest that the features we see here get implemented into Orbiter in a future release.

That's a very kind compliment, thank you. I think face an I make a good team. We just need to get to release now!

This is just awesome.
The taxi lights puzzle me.
There are no conflicts what so ever.

Cheers for the compliment.
Anything with the taxi lights is probably just my fault with the numbers. I shall take a look at them at get that corrected. good spot.
Good to know you have experienced no conflicts too.

One minor aesthetics thing:
When choosing a roll-in/roll-out facility, a list comes up as: etc...
That said, I thought the MFD was pretty easy to figure out. I can't wait for the crane to become operational.

I need to sort out a few naming conventions with Face. He has a habit of calling things 'the tall building thing' and such like, so occasionally names get lost in translation!
I will get this finalised and hopefully make it clearer.

Minor Suggestion: Label the doors on the meshes them selves.
I spent a good 3 minutes parked in the hangar opening random doors before I figured out which one I was actually parked in front of :lol:

Ha ha sorry about that. I shall do something in that regard, but I also like face's mfd suggestion, so that's in too.

Anyway, when I request a taxi "From runway" to "Storage Hangar," the taxi lights in front of the storage hangars are going backwards.

Again this is prob my error. When face says 'maybe I messed up the ini', he means 'maybe Tom gave me the wrong numbers... again'. :rofl:
I'll get it sorted!

I think that would work. "Runway Launch Facility" also gives it a mental separation from the "Vertical Launch Facility" - so it won't seem like a header.

So I mentioned naming conventions above.

I'll clear a few things up now:
The Launch Facility and Mission Control(LFMC) handles all winged launches. The pre-launch and shielded Launchway section is thus called the "Winged Launch Facility". As opposed to "Vertical Launch Complex 1 & 2" which comprise the "Vertical Launch Facility". So I shall get these clarified in the MFD.

 

[Screamer7]

I noticed the following statement in the manual:

Beacons: Please be aware that many of the beacons you see in the above facilities are not yet
functioning as intended. Many have a purpose connected to an animation that has not yet been coded.

I am just curious why the beacon lights strobe towards the selected runway at day, but at night they are static.

Another issue I noticed is that the exhaust and smoke of a vessel (XR2) went straight trough a closed door.
But I think it is an Orbiter "feature"
Anyway, so far so good. No major issues detected and no CTD at all.
I see now what you meant by the D3D 9 client.
The tower's window suddenly become a wall.
I echo RisingFury statements.
This work will be the bench mark for all base making development in the future.
You are going to spoil the Orbiter community with this add on.