Project WIN Ascension Ultra BETA test thread

[Face]

Regarding the runway lights....
You are correrct, increaing the hour spin box and the runway strobe lights behave normal.
BUT if you use the decrease hour spin box, the strobes become a static line.

I can reproduce it now, and to me it looks like an Orbiter bug with beacons.

Try a vanilla install with a stock Deltaglider scenario, switch on the navigation strobes, and try to decrease the time to a point BEFORE the scenario was started: you'll get frozen strobes.

I guess it is due to the way the core handles the strobing timings. Looks like Martin is saving the time-stamp at sim-start and comparing to it in order to determine whether or not to light the candle...

 

[NukeET]

WOW! Visually fantastic and highly functional! As much as I "hate" to say it, once the bugs are fixed, this will be the premier Orbiter base.

Having dispensed with the praises, now it is time for the critique.

My PC specifications for reference:

AMD Phenom II X4 955 3.2 GHz Quad Core 4GB RAM
ATI Radeon HD 6850 Sapphire 775 Mhz 1 GB RAM
Win 7x64 Home Premium
​

1. VLC MLP Roll Out timing: IMO, it seems too quick for realism sake considering the mass/weight of both the MLP and the launch vehicle. Both the open and close cycles last 50 seconds each. I know I struggled with deciding on the open/close times (60 sec one way) for Niven's dome shields after researching real world examples. Real world examples in this case are probably way too long for playability...I don't have any good suggestions.

Visually I found a bug with the MLP lights...they don't move with the structure. Perhaps it is just my h/w and/or s/w. See below:

2. Frame Rates: Generally saw good fps of 54. Lowest observed was 9 (external view with an ExtMFD running and ON...which jumped up to 49 OFF). With the default size of ExtMFD I observed 36...which dropped rapidly when it was resized larger. The frame rate hit resulting from ExtMFD is probably due to the Orbiter core...just a guess on my part. It is what it is.

3. ILSRange: IMO, 100km is better.

4. Airport Terminal Hall Control Room: This might be a z-buffer thing or clipping...the internal view shows what appears to be a pond surrounding the viewpoint. This is missing from the external view at the same LAT/LONG. See below:

5. TA and Lease Hangar mesh flicker: I observed this from inside the Main Tower Control room...but not seen from the same viewpoint in 3D space external to the room. Perhaps another z-buffer thing. Others may want to confirm this. Screenshots don't do this justice...I have video clips upon request. Apparently, Photobucket doesn't like *.avi files...at least today.

Available on YouTube. You will need the links below:


http://youtu.be/6KEUp3JvyLM

http://youtu.be/BK80GixFKEs


Finally, I have to agree with Episilon:

And oh, I wish I could code worth a damn. I'd just shut up and write it.

 

[Loru]

First thoughts:

Overall look is excellent. My only complain regarding looks is that grass is too dark and uniform.

Noticed that one:
looks like looking throug transparent surfaces is messing up Z buffer. However transparency in orbiter is very limited from my experience.

 

[Mojave]

I decided to see if spawning multiple bases would break the MFD.

Nope :thumbup:

JAKE1, (and Samuel Edwards) this one is for you...

Lunar Module "Spider" on approach to "UtraBace!" (instance #4)

"Tower, Spider, we have the field in sight, requesting clearance to land."

"Spider, Tower, Cleared to land runway 13R but for future reference we'll need yo to fly a proper approach, and stay north of the VOR till cleared" :facepalm:

"Roger tower, on Final, 10 seconds to touch down"

"Spider is safe on deck, but unable to taxi, can we get a cart for our bags?"

I ended up over-shooting a bit and landing in the "Grass" between the runways but over all a succesful test of two in developement addons :lol:.

It does bring something to mind though.

The mountains and surrounding terrain should be a seperate set of meshes spawned in the Wideawake base's config file, not associated with the actual "Ascension Vessel".

That's so bace

 

[Loru]

Hmm also towers are just enormous:

That stack is 45 meter high

 

[Face]

1. VLC MLP Roll Out timing: IMO, it seems too quick for realism sake considering the mass/weight of both the MLP and the launch vehicle. Both the open and close cycles last 50 seconds each. I know I struggled with deciding on the open/close times (60 sec one way) for Niven's dome shields after researching real world examples. Real world examples in this case are probably way too long for playability...I don't have any good suggestions.

Yes, this is certainly too fast. Actually this bug is due to me just guessing some times to make a first movable example. The VLC animation will be part of a wizard-style launch preparation mechanism and is only WIP now. I expect the experts to feed me some numbers for the speeds and timings involved .

Visually I found a bug with the MLP lights...they don't move with the structure.

That's what WHAP meant with "beacons not animated" in the documentation.

4. Airport Terminal Hall Control Room: This might be a z-buffer thing or clipping...the internal view shows what appears to be a pond surrounding the viewpoint. This is missing from the external view at the same LAT/LONG.

Yes, this is me being lazy and not working out a proper position for the view and spawn point of the Terminal Hall. I've just left it at _V(0,0,0), so you get that visual. Is on the TODO already...

5. TA and Lease Hangar mesh flicker: I observed this from inside the Main Tower Control room...but not seen from the same viewpoint in 3D space external to the room. Perhaps another z-buffer thing. Others may want to confirm this. Screenshots don't do this justice...I have video clips upon request. Apparently, Photobucket doesn't like *.avi files...at least today.

That's something new. Could you post a scenario so we can try to reproduce it?

Can other beta-testers please try to reproduce this behaviour, too?

Noticed that one:
looks like looking throug transparent surfaces is messing up Z buffer. However transparency in orbiter is very limited from my experience.

I'll chalk it up to the MESHVIS_EXTPASS thingy for now. Let's see if it goes away in the next round.

Thanks for reporting, all!

 

[NukeET]

That's what WHAP meant with "beacons not animated" in the documentation.

OOPS, my bad! And I did RTFM.

That's something new. Could you post a scenario so we can try to reproduce it?

Can other beta-testers please try to reproduce this behaviour, too?

I can if you still want it...but I used the scenario that came with the beta release. See my original post, as I added YouTube links showing the mesh flicker.

 

[wehaveaproblem]

WOW! Visually fantastic and highly functional! As much as I "hate" to say it, once the bugs are fixed, this will be the premier Orbiter base

Much obliged Nuke, let's hope so.

1. VLC MLP Roll Out timing: IMO, it seems too quick for realism sake considering the mass/weight of both the MLP and the launch vehicle.

yes, very much WIP on that stuff atm. I will give it a play to find that sweet spot between believability and yaaaawn.

Generally saw good fps of 54. Lowest observed was 9 (external view with an ExtMFD running and ON...which jumped up to 49 OFF). With the default size of ExtMFD I observed 36...which dropped rapidly when it was resized larger. The frame rate hit resulting from ExtMFD is probably due to the Orbiter core...just a guess on my part. It is what it is.

Thanks for that feedback, it's good to get at an idea of the fps numbers. Seems satisfactory so far.. agree?

4. Airport Terminal Hall Control Room:

It's just laziness on my part, I've only slapped in the airport so far, that end of the base has another round of love coming.

5. TA and Lease Hangar mesh flicker:

I have noticed this a coupla times myself actually. Just above the doors. And same for me it only happened through the Control tower window. That said. There was some similar flicker on the WIN hangar signs. I think it's when there are multiple mesh surfaces close together with similar normals. So in this case the door frame, the wall, and the door. It's probably lazy modelling of the door frames tbh. I'll take a look at it. I'll check out your vids to make sure I'm seeing the same thing. Thanks.

First thoughts:
Overall look is excellent. My only complain regarding looks is that grass is too dark and uniform.

Glad you like the overall aesthetics.. as to the grass... well lol.. last week or so it was much greener, and I didn't like it, so I olived it out a bit. And yes it is a bit uniform, it's a repeating texture square. I may look to replace it with one larger texture that is more natural looking, but I'll have to get the resolution high enough. It'll go on the list...

Hmm also towers are just enormous:
That stack is 45 meter high

This is very true... however, I wanted them to take stacks up to 100m comfortably. They were designed for super heavy lifters really, not shuttle stacks.
That said. I could have one larger and one smaller VLC perhaps?

OOPS, my bad! And I did RTFM.

Ha no worries, it was a little ambiguous tbh.

---------- Post added at 20:33 ---------- Previous post was at 20:30 ----------

Just watched those vids NukeET.

I've not seen it anywhere near that bad before, but it is what I've seen.

It is definitely the window frames, flickering because they are polys over polys. It's the engine that struggles with the slightly lazy modelling. I'll see if I can sort that out without having to tear the hangar to vertices...

Cheers for the vids, much obliged.

 

[Loru]

This is very true... however, I wanted them to take stacks up to 100m comfortably. They were designed for super heavy lifters really, not shuttle stacks.
That said. I could have one larger and one smaller VLC perhaps?

That would be great IMO

 

[Hlynkacg]

That would be great IMO

Agreed,

I have'n really gotten into the vertical LFs yet but I intend to

 

[wehaveaproblem]

Ok then gents, I had considered it before, so I will hit one pad and VAB with a shrinking ray.

 

[Screamer7]

Hi.

I don't know if this is a Orbiter "feature".
When looking down on the DG, and it is in a position that a shadow of the interior of the hanger are falling on it's body, there is no shadow on the vessel.
The same apply for the XR2.

 

[jgrillo2002]

The addon is pretty good so far, aside from the bugs that have been reported but I do have a criticism with the crane system. the snapping of the cranes is too unrealistic to me, I was hoping that you punch X, Y, and Z, and the crane will smoothly go to that position. on and all, its good so far, what types of cargo does the current grapple to?

 

[wehaveaproblem]

Hi.

I don't know if this is a Orbiter "feature".
When looking down on the DG, and it is in a position that a shadow of the interior of the hanger are falling on it's body, there is no shadow on the vessel.
The same apply for the XR2.

That's a limitation of the stock Orbiter gfxengine unfortunately. You can only cast a shadow on the earth or on a mesh loaded in the base cfg file.

The addon is pretty good so far, aside from the bugs that have been reported but I do have a criticism with the crane system. the snapping of the cranes is too unrealistic to me, I was hoping that you punch X, Y, and Z, and the crane will smoothly go to that position. on and all, its good so far, what types of cargo does the current grapple to?

Crane is very much WIP atm, effectively just very basic placeholder code atm. I'm not sure on the technicalities, but I know face has an effective cargo grapple system planned. He might be willing to tell you more, he may wish to keep it under wraps for now...

 

[Raven]

Simply beautiful.
Looks like the other bugs I've seen so far have been covered in other posts, with one exception. I used scenario editor, checked "set input focus", spawned a UCGO car for a ground-level tour, and got CTD immediately when trying to put it on the ground. Spawning and placing without input focus, then switching to the car does fine. This is on a clean 100830 install with only OrbiterSound, UCGO, XR1 v1.8, XR2 v1.3, XR5 v1.6, and AU installed.
My system is an elderly Pentium 1.8G with 1G RAM and an NVidia 512MB 7300SE/7200GS which still gets 20fps with all visual effects on while driving around the island.

 

[Face]

The addon is pretty good so far, aside from the bugs that have been reported but I do have a criticism with the crane system. the snapping of the cranes is too unrealistic to me, I was hoping that you punch X, Y, and Z, and the crane will smoothly go to that position. on and all, its good so far, what types of cargo does the current grapple to?

Do you talk about the incremental positioning mode, where you press buttons to immediately change the position? Yes, that is meant to be snappy.

There are 3 modes for the crane: manual positioning, direct positioning and automatic list processing.

If you go to the cargo page for a TA hangar, there is a button labeled "MOD". With this button you can cycle through the 3 sub-pages "Cargo", "Settings" and "List".
The first is where you can grapple and ungrapple as well as display information about cargo. There won't be a limitation on cargo types. The grappling and ungrappling is not implemented yet (well, technically it is, but deactivated).
The second is where you set the speeds and modes of the crane. ATM there is only a text display of the settings, but a graphical display is planned here. This is also the place where you have a "AUT" and "DIR" button to activate auto listprocessing and direct WASD-mode, respectively. The later is just a FPS-like keyboard control, where you can move the crane in all 3 directions with WASD and QE (with SHIFT as crawl modificator). This keyboard control will be active regardless of the vessel you currently focus. The "AUT" mode is processing a list that you can assemble in the last sub-page of the three: "List".
On the list page, you see a list of 100 entries, with all empty at start. Here you can enter commands via the "TEA" button (for "teach", not for the beverage). You'll get a input dialog with the current coordinates preset, so you can always just hit enter to make it a new position point. But you can overwrite this and also enter one of these commands:

• 's' for 'STOP' to make the processing stop there
• 's xxx yyy' for 'SPEED xxx yyy' to make the processing change speeds (cruise and crawl)
• 'j xxx' for 'JUMP xxx' to make the processing continue on the appropriate entry
• 'p xxx' for 'PAUSE xxx' to make the processing stop for the appropriate number of seconds
• 'g' for 'GRAPPLE' - not implemented
• 'r' for 'RELEASE' - not implemented

Once you've assembled the list, position the cursor on one entry and go to the settings page to start auto mode. The crane will then process the list and smoothly transfer between entries according to the speed settings.


This processing is independent for every crane instance (currently 3 in the TA hangars), and also stored in the scenario file.


The reason why we did not put documentation in for that is the unfinished grapple functionality and the unpolished MFD pages.

---------- Post added at 07:52 ---------- Previous post was at 07:50 ----------

Simply beautiful.
Looks like the other bugs I've seen so far have been covered in other posts, with one exception. I used scenario editor, checked "set input focus", spawned a UCGO car for a ground-level tour, and got CTD immediately when trying to put it on the ground. Spawning and placing without input focus, then switching to the car does fine. This is on a clean 100830 install with only OrbiterSound, UCGO, XR1 v1.8, XR2 v1.3, XR5 v1.6, and AU installed.
My system is an elderly Pentium 1.8G with 1G RAM and an NVidia 512MB 7300SE/7200GS which still gets 20fps with all visual effects on while driving around the island.

That sounds like a tracker problem to me, but I have yet to confirm it.

---------- Post added at 10:11 ---------- Previous post was at 07:52 ----------

I used scenario editor, checked "set input focus", spawned a UCGO car for a ground-level tour, and got CTD immediately when trying to put it on the ground. Spawning and placing without input focus, then switching to the car does fine. This is on a clean 100830 install with only OrbiterSound, UCGO, XR1 v1.8, XR2 v1.3, XR5 v1.6, and AU installed.

I've reproduced this and it has nothing to do with AU. It is the dreaded "don't come near a Deltaglider" UMMU bug.

Try it for yourself: vanilla Orbiter install with Dan's sound, UMMU, UCGO set. Start any scenario with a Deltaglider landed in it. Now repeat your car spawning with the ScnEditor, try to place it near the Deltaglider, and you'll get a CTD.

This is now the second time I've got this bug reported as AU problem. I wonder how many innocent addon-devs got blamed for that before .

I think we will have to put it into an FAQ section, like so:

WARNING:

There is a know UMMU/UCGO bug that crashes Orbiter whenever a UMMU/UCGO object moves near a Deltaglider object while focused. If you e.g. have a scenario with UMMU and Deltaglider nearby, and it states the UMMU as focused, you can't load this scenario. In a similar case, if you create a new UCGO with ScnEditor, and you want to place it near a Deltaglider, it will crash Orbiter if the focus is on the UCGO during placement.

To circumvent these troubles, just be sure to check (and unset) the focus before moving UMMU/UCGO.

Is anyone on Dan's beta team? Maybe you can report it there, if so.

 

[wehaveaproblem]

Do you talk about the incremental positioning mode.../snip/...
The reason why we did not put documentation in for that is the unfinished grapple functionality and the unpolished MFD pages.

Thanks for the detailed description there, even I learnt some things!

This is now the second time I've got this bug reported as AU problem. I wonder how many innocent addon-devs got blamed for that before .

I think we will have to put it into an FAQ section, like so:

#3 isn't it now? And aye, unfortunately seems a disclaimer will be required to cover a few such issues.

 

[Face]

#3 isn't it now? And aye, unfortunately seems a disclaimer will be required to cover a few such issues.

Just the second for that particular bug. The instant death one we fixed already, if you remember issue #11.

It just seems so obviously reproducible with vanilla installations that I wonder why it didn't show up earlier. Maybe we all missed a bug-fix patch or something from Dan?

 

[wehaveaproblem]

Maybe the use of the stock DG is so rare nowadays, that noone noticed...? I suspect most ummu users either use DGIV/XR Fleets or some other historical mods...

Stock DG is not ummu compatible afterall, right? so maybe testing understandably just slipped through the cracks...?

 

[orb]

Maybe the use of the stock DG is so rare nowadays, that noone noticed...?

I almost exclusively use the stock DG for different tests, but I don't test the Ascension Ultra.