Project WIN Ascension Ultra BETA test thread

[wehaveaproblem]

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.

That statement mainly refers to the lights around doorways and in hangars.
But hmm, what do you mean by 'the beacon lights strobe', which ones specifically please?

 

[Screamer7]

That statement mainly refers to the lights around doorways and in hangars.
But hmm, what do you mean by 'the beacon lights strobe', which ones specifically please?

Yes, the runway beacon light strobes.

 

[wehaveaproblem]

Another issue I noticed is that the exhaust and smoke of a vessel (XR2) went straight trough a closed door.

aye, we're stuck with that I'm afraid.. one day someone will code a working tug.

Anyway, so far so good. No major issues detected and no CTD at all.
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.

:tiphat: much obliged.


edit: "Yes, the runway beacon light strobes."
Sorry, one more clarification... do you mean the lead-in landing lights or taxiway guidance lights?

 

[Screamer7]

Yes, the lead-in landing lights towards the threshold of the runway.
At day they strobe towards the runway from the sea, but at night they are not strobing and are static.
Or am I missing something, and is meant to be this way.

 

[wehaveaproblem]

Yes, the lead-in landing lights towards the threshold of the runway.
At day they strobe towards the runway from the sea, but at night they are not strobing and are static.
Or am I missing something, and is meant to be this way.

It's not meant to be that way to my knowledge, and it's not something I've noticed before. I shall (get face to) take a look into it.
Cheers.

---------- Post added at 21:49 ---------- Previous post was at 21:44 ----------

Just had a play and it's not a bug I can reproduce, all lead-in lights work day and night on my end.

Anyone else getting this?

(I did notice they are not leading in far enough on 31L and R though.)

 

[Face]

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.

The note there is due to the beacons on the VLCs not moving with the cover/MLP. Also all those edge lights on hangar floors are meant to be switchable, not static. Again an artifact of lazy coding .

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

I can't reproduce this. Could you please give us a recipe how to get that effect?

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"

Yes, no chance deactivating that "feature" yet .

---------- Post added at 22:58 ---------- Previous post was at 22:55 ----------

(I did notice they are not leading in far enough on 31L and R though.)

First test for the INI file, I'd say. You should be able to hack that to get the proper result.

I have to admit that I've seen that for a long time now, but I just thought you knew what you were doing .

 

[wehaveaproblem]

T
First test for the INI file, I'd say. You should be able to hack that to get the proper result.

I have to admit that I've seen that for a long time now, but I just thought you
knew what you were doing .

Aye I'll get to it. You should know by now I get my numbers wrong at least twice before it's right lol.

 

[Screamer7]

That is odd.
Regarding the runway lights, if I used Orbiter editor function and alter the time to night, the strobes become static.
But when I use time acceleration, and it become, night they strobe.
To sum it up:
The editor causes the strobes to become static.
The time acceleration function let the strobes behave normally.
That is something I did not see in Orbiter for a while.

---------- Post added at 10:32 PM ---------- Previous post was at 10:07 PM ----------

Another issue.
Spawn a XR5 in one of the turn-around hangers.
Position the XR5 halfway out of the hanger with the door open.
Go to the control room and view the XR5.
The walls, billboards and opposite buildings now show inside the XR5!

 

[Hlynkacg]

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".

 

[wehaveaproblem]

To sum it up:
The editor causes the strobes to become static.
The time acceleration function let the strobes behave normally.

Spawn a XR5 in one of the turn-around hangers.
The walls, billboards and opposite buildings now show inside the XR5!

Thanks for the further report.
That's an interesting thing you've found there about time accel vs scn editor. I'm not sure if it's something face is aware of, or if there's anything we can do about that tbh. Have to wait for him to see this.

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

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".

wrt multiple bases. I know face has programmed that intentionally, as part of the base making tool functionality.

As to the island mesh(it is only one mesh, no surface tiles this time). The orbiter engine renders meshes differently if loaded via base.cfg or scn file. So the island looks noticeably nicer when loaded as a vessel, although this comes with the trade-off of no shadows. It also allows us to control its loading through the LoD options(to be coded). So it's a conscious choice after enough deliberation.

 

[Epsilon]

Initial impressions:
The base is beautiful. Plenty of little things to do with it, too. Kudos!

All the little functions of the Ascension MFD are cool, too. Sometimes, the commands are a bit obtuse (like the launch runway option, or even choosing which lease hangar you want to land at,) but for the most part, it's understandable once you've read the docs.

Winged Launch:
The winged launchway has very small clarances on the side when you're launching an XR5. I'd guess less than a meter or so. If any of the future XR vessels end up with a wider wingspan, they simply won't fit in the launchway. Ditto with the hangars.

The longer takeoff distance is a really nice touch, especially when you're launching an overloaded XR5.

Where is the "Tunnel Door" on the Launch hangar? I might be being dense, but I can't find it. If it's the door just to the left of the passenger terminal sign, it doesn't seem like it's animating.

Landing Pads:
First, this is an absolutely beautiful idea. Makes getting the craft to the right place a hell of a lot easier. With that said, the orientations on the pads are all screwed up. Here's what they should be, by my calculations:

Pad 1: 40 Degrees
Pad 2: 40 Degrees
Pad 3: 220 Degrees
Pad 4: 40 Degrees
Pad 5: 220 Degrees
Pad 6: 130 Degrees
Pad 7: 130 Degrees
Pad 8: 130 Degrees
Pad 9: 130 Degrees
Pad 10: 310 Degrees
Pad 11: 310 Degrees
Pad 12: 40 Degrees (Not sure which way you want to be pointing for this one - may be 220 Degrees)

Taxi Lights:
Again, wonderful idea. One suggestion for it, though - have them switch off after either a predetermined interval or once the craft comes within <x> meters of the target hangar. Not sure how easy the latter is, but the first certainly seems possible and relatively easy.

Tower MFD:
This is again a cool idea - would it be possible to have it in its own little window, though? Or have the option to have it in its own window? I imagine the interface could be made quicker to navigate if it were.

Also, I'm assuming certain functions (like getting the bearing to Wideawake) aren't functional yet. Otherwise, this is a bug. ^_^

Runways:
Is it possible to extend the ILS range for the runways? I think I've asked this before. <_< You're usually coming in faster and hotter than a typical airplane, so 20km really isn't a whole lot in the grand scheme of things.

Conclusion:
All this stuff being said, I love the base. It certainly feels more interactive and "alive" than the previous Wideawake. I'm looking forward to seeing how further development turns out. :thumbup:

 

[RisingFury]

Where is the "Tunnel Door" on the Launch hangar? I might be being dense, but I can't find it. If it's the door just to the left of the passenger terminal sign, it doesn't seem like it's animating.

Took me a while to find as well. It's inside the launch tunnel. When you retract the blast shield, you'll notice it's curved. You then open the tunnel door to "let the exhaust out". Next time you're in the launch tube look to the right, where the blast door is.

 

[Face]

That is odd.
Regarding the runway lights, if I used Orbiter editor function and alter the time to night, the strobes become static.
But when I use time acceleration, and it become, night they strobe.
To sum it up:
The editor causes the strobes to become static.
The time acceleration function let the strobes behave normally.
That is something I did not see in Orbiter for a while.

Indeed odd. I can't reproduce it with ScnEditor. Could you please tell us what you exactly do in ScnEditor (or if even a different function used). I used the "Date" button there and increased time with the spin boxes, even changed the propagation options. All the time a selected runway (the first in the list) strobed away happily.

Another issue.
Spawn a XR5 in one of the turn-around hangers.
Position the XR5 halfway out of the hanger with the door open.
Go to the control room and view the XR5.
The walls, billboards and opposite buildings now show inside the XR5!

I guess we can chalk that up to the transparency issue as well as the MESHVIS_EXTPASS flag. Please take a mental note of this situations and once the fix is out, try to reproduce it then to see if it is gone.

---------- Post added at 08:02 ---------- Previous post was at 07:40 ----------

Initial impressions:
The base is beautiful. Plenty of little things to do with it, too. Kudos!

All the little functions of the Ascension MFD are cool, too. Sometimes, the commands are a bit obtuse (like the launch runway option, or even choosing which lease hangar you want to land at,) but for the most part, it's understandable once you've read the docs.

Thanks for the kudos!

For the obtuse commands, do you have proposals what we should change it to instead?

Taxi Lights:
Again, wonderful idea. One suggestion for it, though - have them switch off after either a predetermined interval or once the craft comes within <x> meters of the target hangar. Not sure how easy the latter is, but the first certainly seems possible and relatively easy.

That sounds like a good idea. Actually we have a more immerse experience for that in mind: ATC chatter. That's why most options are prefixed with "Request...". It should actually trigger a simulated conversation between the vessel and the tower to do the things. In the case of the taxi request, it will of course have a start and an ending. The later will most probably be triggered by position.

Tower MFD:
This is again a cool idea - would it be possible to have it in its own little window, though? Or have the option to have it in its own window? I imagine the interface could be made quicker to navigate if it were.

Also, I'm assuming certain functions (like getting the bearing to Wideawake) aren't functional yet. Otherwise, this is a bug. ^_^

You mean a dialog window instead of an MFD mode, right? Well, this is what we pondered for a while before deciding for the mode, because the dialog felt somehow wrong. The reasons were that the idea of having wizard-like interfaces that simulate communication between vessel and base can reside in an MFD mode as well, and are actually easier to access than a "custom function" dialog box.

Having the functionality in a dialog box would be a rewrite of it, code-wise. Also the design would change naturally (no point in different pages there). TBH I won't implement it at this stage, as I don't see much gain in it wrt. the needed effort.

Is there a strong argument for it to be in a dialog box?

Or do I misunderstand it and you just want something like ExtMFD, with the thing displayed in a separate window to move out of the way?

About the certain functions like bearing: yes, this is not implemented ATM.

 

[Epsilon]

Thanks for the kudos!

For the obtuse commands, do you have proposals what we should change it to instead?

Nothing needs to be changed - more like... extended in detail. A good example is the report of "I thought Launch Facility was a header." I'd have had the same problem if I hadn't read through the thread while I was doing housekeeping on my Orbiter install.

I did get myself confused when looking at the various Lease Hangars - I was thinking the numbers were just part of a numbered list rather than being linked to the various facilities.

Perhaps instead of labelling the items "1. Blah Blah," tag them "Blah Blah #1." It's just a minor usability nitpick.

That sounds like a good idea. Actually we have a more immerse experience for that in mind: ATC chatter. That's why most options are prefixed with "Request...". It should actually trigger a simulated conversation between the vessel and the tower to do the things. In the case of the taxi request, it will of course have a start and an ending. The later will most probably be triggered by position.

All I ask is that you have the option to have it in text. I'm a wierd one in that I don't want sound when I'm playing Orbiter, unless it's me playing Queen with Winamp.

You mean a dialog window instead of an MFD mode, right? Well, this is what we pondered for a while before deciding for the mode, because the dialog felt somehow wrong. The reasons were that the idea of having wizard-like interfaces that simulate communication between vessel and base can reside in an MFD mode as well, and are actually easier to access than a "custom function" dialog box.

Having the functionality in a dialog box would be a rewrite of it, code-wise. Also the design would change naturally (no point in different pages there). TBH I won't implement it at this stage, as I don't see much gain in it wrt. the needed effort.

Is there a strong argument for it to be in a dialog box?

Or do I misunderstand it and you just want something like ExtMFD, with the thing displayed in a separate window to move out of the way?

Okay, so don't get me wrong - I see why you made this decision. It very well may be specifically because the functionality is "immature" (e.g. ATC) that I have this problem. I'm just thinking about how I fly when I'm in the atmosphere, though - I like to hae SurfaceMFD on the left side (or even Aerobrake,) and the HSI on the right. Another useful MFD during landing is MapMFD. Having the AU MFD open takes up a valuable MFD spot for me.

I could probably sort this by using the external MFD window, but once I've got it in an external window, it might as well be an easier-to-navigate dialog box, right? I'll withhold final judgment until we get some "real ATC chatter" to see if it becomes more useful/immersive/etc, but I'd almost rather see an interface like FSX's ATC window than an MFD for the whole thing.

It isn't a dealbreaker for me or anything, just usabillity opinions. I imagine you'd need a lot more complaints before you'd genuinely think of redoing all your work.

 

[Face]

Perhaps instead of labelling the items "1. Blah Blah," tag them "Blah Blah #1." It's just a minor usability nitpick.

Maybe minor, but valuable! That's actually a good idea.

All I ask is that you have the option to have it in text. I'm a wierd one in that I don't want sound when I'm playing Orbiter, unless it's me playing Queen with Winamp.

Of course. Sound might be an addition, but not necessary.

Okay, so don't get me wrong - I see why you made this decision. It very well may be specifically because the functionality is "immature" (e.g. ATC) that I have this problem. I'm just thinking about how I fly when I'm in the atmosphere, though - I like to hae SurfaceMFD on the left side (or even Aerobrake,) and the HSI on the right. Another useful MFD during landing is MapMFD. Having the AU MFD open takes up a valuable MFD spot for me.

I see where your point is here, and we actually had this discussion, too. But if you are flying a real spacecraft, you also have real instruments for voice comm, where you set frequency/intercom-mode and so on. This takes up space, too. The tower MFD is the idea to resemble this fact: a spacecraft-bound device to talk to the tower.

I could probably sort this by using the external MFD window, but once I've got it in an external window, it might as well be an easier-to-navigate dialog box, right? I'll withhold final judgment until we get some "real ATC chatter" to see if it becomes more useful/immersive/etc, but I'd almost rather see an interface like FSX's ATC window than an MFD for the whole thing.

The premise here is that the dialog box is really easier to navigate. I doubt this, especially in the situation of - say - approaching a runway. I must admit that I don't have much experience with FSX, and especially its ATC functionality, but I have logged many hours in Flight Unlimited III, and the ATC functionality there was a rather crude, but very practical, online text menu. Worked like a charm, and never made me feel like they are obstacles. FS2004's dialog menus always felt like clutter to me, OTOH.

It isn't a dealbreaker for me or anything, just usabillity opinions. I imagine you'd need a lot more complaints before you'd genuinely think of redoing all your work.

The amount of complaints is irrelevant to me, the quality of feedback is what matters . Of course I respect all opinions, but as I wrote before, I won't implement it yet only for the sake of having it as dialog.
Now if the MFD approach absolutely not works out in the sense of usability, it would be a reason to stop development of it completely and redesign.

That said, I would welcome everyone who wants to contribute a dialog interface to the project! That's the beauty of open source, after all: you can enhance things by yourself.

cheers,
Face

 

[Epsilon]

I see where your point is here, and we actually had this discussion, too. But if you are flying a real spacecraft, you also have real instruments for voice comm, where you set frequency/intercom-mode and so on. This takes up space, too. The tower MFD is the idea to resemble this fact: a spacecraft-bound device to talk to the tower.

The difference here is that in an airplane (or probably a spacecraft,) you've got these things in a separate panel from your main flight instrumentation. It'd be different if all vessels had a separate comm panel.

I still technically like the idea of talking to ATC in Orbiter - but as a non-integrated part of it, it's going to be strange in its implementation no matter what.

The premise here is that the dialog box is really easier to navigate. I doubt this, especially in the situation of - say - approaching a runway. I must admit that I don't have much experience with FSX, and especially its ATC functionality, but I have logged many hours in Flight Unlimited III, and the ATC functionality there was a rather crude, but very practical, online text menu. Worked like a charm, and never made me feel like they are obstacles. FS2004's dialog menus always felt like clutter to me, OTOH.

In FSX, it was a set of numbered menus. I guess the ideal would be to emulate the system - catch any numeric keystrokes that are input, and use those to contact WIA ATC*. That way, you're not fiddling with your mouse on approach. That said though, you'd probably be contacting ATC far enough out in the landing process that messing with menus wouldn't be a huge interference.

I'm not sure if capturing the keystrokes into an external dialogue without having the focus on it is even possible, of course - if it isn't, I agree with your assessment that it may end up being a clunkier interface than the MFD.

* I guess it might help if I learned Orbiter's shortcuts for hitting the MFD buttons, but you've still got the issue of many-levelled menus with pages you need to flip back and forth. I'll probably try flying with ExtMFD and seeing how well that works out for me.

The amount of complaints is irrelevant to me, the quality of feedback is what matters . Of course I respect all opinions, but as I wrote before, I won't implement it yet only for the sake of having it as dialog.
Now if the MFD approach absolutely not works out in the sense of usability, it would be a reason to stop development of it completely and redesign.

That said, I would welcome everyone who wants to contribute a dialog interface to the project! That's the beauty of open source, after all: you can enhance things by yourself.

Well, I figure that if people are complaining too much, there's probably something wrong with it from a usability standpoint.

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

---------- Post added at 01:30 ---------- Previous post was at 00:29 ----------

A separate set of issues.

The lease hangars are just a hair too short for XR2-class vessels, as shown here:

(by the way, the health and safety posters are a nice touch)

This is really a subissue of the thing I mentioned my other post - thin tolerances on some of the meshes when it comes to parking/using certain vessels.

-----------------

The second issue is with the ordering of Ascension in the base list. This has been a problem I've noticed since the first time I downloaded Wideawake. The base is named "Wideawake International," but the config file is called "Ascension Ultra.cfg". Renaming the config file to "Wideawake.cfg" puts it in the proper alphabetical order in the list.

The fix for this is either to rename the config file (which doesn't appear to have any ill effects at first glance,) or to rename the base to "Ascension Airfield - Wideawake International" or something of the sort so it looks like it's sorted correctly.

 

[Face]

The second issue is with the ordering of Ascension in the base list. This has been a problem I've noticed since the first time I downloaded Wideawake. The base is named "Wideawake International," but the config file is called "Ascension Ultra.cfg". Renaming the config file to "Wideawake.cfg" puts it in the proper alphabetical order in the list.

The fix for this is either to rename the config file (which doesn't appear to have any ill effects at first glance,) or to rename the base to "Ascension Airfield - Wideawake International" or something of the sort so it looks like it's sorted correctly.

I see what you mean. As for the technical side, renaming is no problem. As WHAP already stated, I don't have it with naming , so I'll let him decide what to do in the end.

 

[Screamer7]

Hi 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.

 

[Epsilon]

Landing Pads:
First, this is an absolutely beautiful idea. Makes getting the craft to the right place a hell of a lot easier. With that said, the orientations on the pads are all screwed up. Here's what they should be, by my calculations:

Pad 1: 40 Degrees
Pad 2: 40 Degrees
Pad 3: 220 Degrees
Pad 4: 40 Degrees
Pad 5: 220 Degrees
Pad 6: 130 Degrees
Pad 7: 130 Degrees
Pad 8: 130 Degrees
Pad 9: 130 Degrees
Pad 10: 310 Degrees
Pad 11: 310 Degrees
Pad 12: 40 Degrees (Not sure which way you want to be pointing for this one - may be 220 Degrees)

Heh. So I was digging in the .cfg file, and it looks like these values are already in there. This means that the problem is less with the landing pad orientations, and more how the scenario editor adds vessels on landing pads - the orientation appears to be whatever it was by default when the scenario was loaded or the vessel was added with the scenario editor.

I'll probably do some more testing, but I came to this conclusion by looking at the default DG that's already there - it's oriented at 220 degrees. Whenever I changed the vessel's position with the scenario editor, it stays at the same 220 degrees.

When I load up an XR in the scenario editor, it spawns in orbit with a heading of 67 degrees. It stays in this same heading whenever it's moved around by the scenario editor.

After even more fiddling (just now,) I realized that the window with the location also has a heading item in it. So this is why it's not using the landing pad's orientation. Looks like a limitation of the scenario editor, so I guess you can disregard the comments about this all around. h:

(The one thing I find odd is that if you orient yourself manually and then move again, the scenario editor doesn't appear to update with the movement. Makes sense when you think about it, but interesting all the same.)

 

[wehaveaproblem]

Initial impressions:
The base is beautiful. Plenty of little things to do with it, too. Kudos!

Thanks for the positives!

The winged launchway has very small clarances on the side when you're launching an XR5. I'd guess less than a meter or so. If any of the future XR vessels end up with a wider wingspan, they simply won't fit in the launchway. Ditto with the hangars.

The longer takeoff distance is a really nice touch, especially when you're launching an overloaded XR5.

WRT to clearances. Yes i am aware there are a few cloase calls and things are a little tight. This is the result of 2 things mainly. Firstly, Some of the original meshwork was done bloody ages ago, so was designed around the DG, not the XR2. I will increase clearances of the small lease hangars accordingly. As the the XR5... she's bloody huge! I decided on small clearances for her so that the hangars dwarfed every other vessel as little as possible, plus pilots like accuracy! That said, I do appreciate things are tight on the Launchway particularly, I will take a look at this.

Landing Pads:
First, this is an absolutely beautiful idea.

As your later post pointed out, the correct rotations are there but, like you, I recently discovered it unfortunately makes no difference wrt to scn editor, which doesn't seem to pull that info from the cfg. I doubt there is anything to be done about this. All I can do in the meantime is to add the relevant rots to the manual, so people at least know what they should be.

Taxi Lights:
Again, wonderful idea. One suggestion for it, though - have them switch off

Aye, agree with face, good suggestion, it'll go in.

Tower MFD:
This is again a cool idea - would it be possible to have it in its own little window, though?

face has answered this in detail, explaining the rationale, so it is likely to stay as is I would think.

Also, I'm assuming certain functions (like getting the bearing to Wideawake) aren't functional yet. Otherwise, this is a bug. ^_^

Aye, as face says, it's WIP. The manual should state that, apologies if it does not.

Runways:
Is it possible to extend the ILS range for the runways?

Noted, this was an oversight, the ILS beacons on recently went back in, so I will increase this. 100km enough?

All this stuff being said, I love the base. It certainly feels more interactive and "alive" than the previous Wideawake. I'm looking forward to seeing how further development turns out. :thumbup:

Thank you for your time and feedback, much appreciated. I'm keen to see how it all turns out too!

Took me a while to find as well. It's inside the launch tunnel. When you retract the blast shield, you'll notice it's curved. You then open the tunnel door to "let the exhaust out". Next time you're in the launch tube look to the right, where the blast door is.

Yeah, cheers for this. It is worth noting that atm all the launch doors are manually controlled, this is WIP. When the Launch wizard is in, the doors will operate automatically depending on what pre-launch/launch request you make.

The amount of complaints is irrelevant to me, the quality of feedback is what matters .

Indeed, you can't please everybody! But I have to say the level of feedback so far is very constructive and considered, so thank you all!

I'm not sure if capturing the keystrokes into an external dialogue without having the focus on it is even possible, of course - if it isn't, I agree with your assessment that it may end up being a clunkier interface than the MFD.

Face has done most of the talking on this issue, and I agree with his responses. I think the MFD route is the best one for orbiter, as it is the standard way to interact with things. Whilst the ATC will add another layer of feedback beyond the MFD per se, I do still believe it the best interactive tool to use.

The second issue is with the ordering of Ascension in the base list. This has been a problem I've noticed since the first time I downloaded Wideawake. The base is named "Wideawake International," but the config file is called "Ascension Ultra.cfg". Renaming the config file to "Wideawake.cfg" puts it in the proper alphabetical order in the list.

This is my doing. The base was titled "Ascension Ultra", but I changed it to "Wideawake Int" AU just before beta, withouyt telling face! I know this jumps it up the list and I will get this rectified. But it was a last minute change and I assume there will need to be a subsequent change in the loading code if we change the name of the base.cfg file, hence why I didn't do it before release. So we will get that straightened out.