Project Wideawake International: Ascension Ultra

[Arrowstar]

Looks great! I don't suppose there's working ATC?

 

[wehaveaproblem]

I was just wondering if the VTOL pads will be large enough to handle a Firefly class, also have you considered a hangar for VTOL that has a rooftop entry access that slides back to allow them to land via a rooftop hatch and a smaller main door in the side of the hangar that allows support equipment into the hangar.

At the moment the VTOL facility has not been worked on, it's inclusion is still in the balance tbh. I have the area marked out in the base, and it's big enough for the Arrow Freighter, but that is it so far. I intend to get some further feedback on whether people really think a VTOL facility is 'realistic' in such a dense, heavy g atmosphere like Earth. So watch this space...

Looks great! I don't suppose there's working ATC?

Working ATC... yes and no is the answer. There is an ATC section of the MFD, but at present you can only request landing clearance (triggering appropriate runway lights). But, we have plans for further ATC requests, including bearing and launch requests etc. In addition, and this is a bit of a secret feature at present, but we have been discussing a 'radio chatter' feature, which will 'text display' all communications with the Ascension Tower to the HUD. Kinda like how FSX does now. So you will be able to read the 2-way radio coms from vessel to tower. It's just a cosmetic/immersion thing, but I think it'll be quite cool tbh. But shhhh, it's secret.

 

[RisingFury]

To answer your question, in brief...
Control hangar doors, control roll out for vertical launch, strobing taxi routes,-cargo management crane, a bunch of other relevant beacon controls (runways etc), and other features that you will have to wait for.

This might be a question aimed at Face, but is it possible that other Orbiter plugins could interact with whatever AU has to offer?

For example, OBSP already has takeoff and landing autopilots and right now I'm working on taxi algorithms so planes can taxi to and from runways, landing pads and hangars.

Since I'm hoping the autopilots and AI in OBSP will become the standard in that area, will it be possible that the vessels could interact with features of AU?

 

[wehaveaproblem]

This might be a question aimed at Face

One for face definitely lol. Sounds like some interesting stuff you got going on there though, so let's hope so. However, I can say that such compatibility issues will likely come at the end of the dev process, as I'm sure you can appreciate.

 

[RisingFury]

One for face definitely lol. Sounds like some interesting stuff you got going on there though, so let's hope so. However, I can say that such compatibility issues will likely come at the end of the dev process, as I'm sure you can appreciate.

Compatibility issues can be avoided if we plan ahead and develop good standards that can interact with each other.

The worst thing that can happen, I guess, is that a plane enters the hangar through closed doors or takes off without permission from AU software, but only with permission of the OBSP AI. Of course, it'd just suck to see something like that happen with two highly detailed and developed add-ons.

 

[Face]

This might be a question aimed at Face, but is it possible that other Orbiter plugins could interact with whatever AU has to offer?

For example, OBSP already has takeoff and landing autopilots and right now I'm working on taxi algorithms so planes can taxi to and from runways, landing pads and hangars.

Since I'm hoping the autopilots and AI in OBSP will become the standard in that area, will it be possible that the vessels could interact with features of AU?

ATM there is no interface to other add-ons, and MFD<=>base-vessel interaction is via header inclusion. I can imagine a clbkGeneric based serializing interface, though, as the commands from MFD to base-vessel are rather generic, too.

Taxiways are stored pretty generically in an INI file, so maybe you can simply read-in that info to generate coordinate info for your taxi algorithm. We'd have to work details out, of course.

 

[wehaveaproblem]

Compatibility issues can be avoided if we plan ahead and develop good standards that can interact with each other.

The worst thing that can happen, I guess, is that a plane enters the hangar through closed doors or takes off without permission from AU software, but only with permission of the OBSP AI. Of course, it'd just suck to see something like that happen with two highly detailed and developed add-ons.

You make a very fair point there. let's see what face has to say on it, as I have no clue.

edit: well there ya go! sounds positive! cheers face

 

[Overlocker]

Where's the Beta Testing page, post, download link? I see a strange jump from 2nd July to August...

 

[Face]

Where's the Beta Testing page, post, download link? I see a strange jump from 2nd July to August...

Beta testing is only among a closed group of beta testers. PMs are used to inform this group about new releases.

Maybe this is contributing to your perception of a strange jump.

 

[RisingFury]

ATM there is no interface to other add-ons, and MFD<=>base-vessel interaction is via header inclusion. I can imagine a clbkGeneric based serializing interface, though, as the commands from MFD to base-vessel are rather generic, too.

Taxiways are stored pretty generically in an INI file, so maybe you can simply read-in that info to generate coordinate info for your taxi algorithm. We'd have to work details out, of course.

Communication via clbkGeneric sounds good. As long other modules can access stuff like opening and closing doors, activating taxi lights,... When it comes to the syntax of the messages sent, I'll leave that in your hands, as long as it's possible.

I've had a look through the INI. I'll have to learn how you define taxiways and if some are defined as one way streets or not.

OBSP's had taxiing for a few months now. Since Orbiter doesn't define any taxiways in its core, I created a system where the creator of the airfield can define taxi ways. I did that by placing navigational markers on areas like the ends of taxiways, corners, crossroads,... and then defined which of the navigational points are connected. Some taxiways can be one way streets to help avoid traffic problems...

Here's an example of the botpathing for Wideawake International:

The red dots indicate navigational markers, the blue lines between them mean connections that the AI can drive along. The lines that have an arrow at either end mean a one way street. The exits from runways in the middle of the runway are one way (so the AI doesn't drive onto the runway there) and the entrances and exits from hangars in some places are one way.

Some hangars aren't connected yet as I have yet to figure out how to make vessels exit in reverse. With the vessels that have retro thrusters that's easy... but those that don't leave me problems... Vessels enter the hangar nose first and also try to exit nose first, so in case where the hangar only has one entrance, the vessel drives through a wall...

I want to make sure that OBSP is compatible with the new AU technology. I don't want the user to have to open and close doors, activate taxi lights,... I want the OBSP's AI to be able to interface with the module and do everything automatically, so what I need is:
- A way to figure out which doors belong to which hangar - so I can open the right ones.
- A way to open and close doors.
- A way to tell which runway lights to activate and to activate them.
- A way to activate / deactivate any other features you might introduce in the future, like loading of cargo and fuel,...

If you can make that happen, it'll leave the doors open for modules to start interacting and addons can be written to support and complement each other...

 

[wehaveaproblem]

Where's the Beta Testing page, post, download link? I see a strange jump from 2nd July to August...

As face has already said, its a closed beta atm, check the beta thread for details if you're interested.


RisingFury, your work/plan sounds great, hopefully face can shine some light on all that jazz, I'm just a meshmonkey.

 

[Face]

Communication via clbkGeneric sounds good. As long other modules can access stuff like opening and closing doors, activating taxi lights,... When it comes to the syntax of the messages sent, I'll leave that in your hands, as long as it's possible.

I've had a look through the INI. I'll have to learn how you define taxiways and if some are defined as one way streets or not.

clbkGeneric() still seems to be the best alternative for open P2P (plugin to plugin) communication. If I go that route, I'll simply implement the object interface I already have in place. This already "serializes" MFD/Vessel interactions to a certain extent. With it, you'd be able to do everything you can do with the MFD via clbkGeneric().

As for the INI-file: there should be some comments in there explaining the different line formats. In principle, the various taxiway entries define the beacon segments first (BeaconArrayX), then the beacon paths (BeaconPathX), then what start-point to what end-point uses which path (BeaconRouteX).

Given this information, you should be able to work out a directed graph of the main taxiways. Of course your description also includes paths for AI controlled crafts entering and leaving hangars. There is currently no data for this, but it should be possible to put that into the INI-file, too.

regards,
Face

 

[Pale Hearse]

Someone a while back made a comment about capital ships and I thought I would just toss my 2 centavos in. I think that if one were to look at near future and even far future actual applications in this area.. the capital ship operations area would be one way..
.. up. These operations, funded by governments (and MicroSoft) would be engaged in the building of large interplanetary exploration and mining type vessels and large space stations such as 2001's space station V.

As such, I would love to see such a capital ship build and command area for assembling components for launch and plan/communicate with current missions.. but not a place to land them.

This is a HUGE step up for base development. Once released.. people will be chasing this for years.. as people still chase the XR-2. If I had 2 heads.. both hats would be off to you guys!

I can't wait till Tuesday.

 

[wehaveaproblem]

Someone a while back made a comment about capital ships and I thought I would just toss my 2 centavos in. I think that if one were to look at near future and even far future actual applications in this area.. the capital ship operations area would be one way..

Cheers for the kind words. As to capitol ship facility... I have a spot marked out, but I'm still undecided as to whether I want one or not.

 

[I00I]

Great additions to orbiter..I,m having trouble editing with the scenario with the positions of the planes..For example the xr-1 and its landing position..I wish to reverse it but it won,t take any suggestions..:facepalm:

 

[wehaveaproblem]

Great additions to orbiter..I,m having trouble editing with the scenario with the positions of the planes..For example the xr-1 and its landing position..I wish to reverse it but it won,t take any suggestions..:facepalm:

Thanks for the kind words...
Are you talking about AU beta, or the original WIN?
And when you say 'reverse it' what do you mean? change it's heading? If so, unfortunately orbiter does not pull the heading of landing pads when it pulls their positions from the cfg, so all vessels face the same way regardless of pad heading. You will have to use the scenario editor for manual tweaking.

 

[I00I]

I tried positioning with the scenario editor to turn XR 180 degrees from its position so its facing the runways approach but it wont save for some reason..Also I was wondering how can I add the volcano steam to the craters of your beautiful island? :tiphat:Any ideas how?:idea:
I,m still a noobie..As well as adding the docks..I,m having troubles adding that tooo..I,m a mess..I definetly enjoy ur project for low end systems..Nice and smooth..

 

[wehaveaproblem]

I tried positioning with the scenario editor to turn XR 180 degrees from its position so its facing the runways approach but it wont save for some reason..Also I was wondering how can I add the volcano steam to the craters of your beautiful island? :tiphat:Any ideas how?:idea:
I,m still a noobie..As well as adding the docks..I,m having troubles adding that tooo..I,m a mess..I definetly enjoy ur project for low end systems..Nice and smooth..

Ok, so you're talking about the existing WIN, this thread is for the new AU dev. But to avoid starting a new thread or rezposting in the original WIN thread, I'll answer here.
I'm not sure why the orientation change isn't saving in your scenario. I've never had issues with that before, that's an orbiter thing, not a WIN thng.
Regarding volcano gasses, you will have to look into basic vessel coding, specifically how to create rocket contrails/smoke from an engine with no power. I won't go into details here as this is covered in tutorials and other threads, but essentially you will have to create a vessel that shoots rocket exhaust upwards, and then load that vessel into the scenario in the required place on the island.

 

[paddy2]

Dear Mr We Have a Problem,

Please accept this post as a request for a reimbursement payment for the new graphics card I have had to buy myself for Christmas. Following the release of images of the new version of your add on scenery, a requirement existed to upgrade my old card to something which can show your forthcoming release in all it's shining glory. While we accept the fact that I am able to display your present release, this does not release you from any blame for the overwhelming desire I have to be able to be be able to do justice to the new version when realised. Indeed it is my intention to seek redress in a separate claim for the hours spent enjoying said add on, thinking “This is so much better than any thing I could do”.

This party acknowledges that you have released items from the aforesaid “WideAwake” to be used on self devised add ons but contends that this simply shows ones own “bits” up for the junk they are. This in turn simply fosters the dream that one would be able to humbly gaze on its newer improved manifestation.

To this end this party feels that we had no option but to make ready for your enhanced and eagerly awaited release. If you are to dangle such fine examples of great work in front of us, you have to pay the price.

It has been pointed out that one does not have to download it when its finished. Our counterpoint simply states that having seen and loved the existing version, not getting ready for the new one is just madness.

Please note that this party is also willing to wave compensation if this post is accepted in the spirit in which it is intended!

 

[wehaveaproblem]

Dear Mr Paddy,

Re: your pursuit of recompense for financial outlays made in the light of the WIN AU development.

Please be assured that why AIA is genuinely touched by your admiration of our work and pleased you are eagerly anticipating its availability to the public, we are concerned that said development could endanger the financial stability of its users. While we admire your desire to secure hardware capability sufficient to fully realise the functionality and aesthetic beauty of WIN AU, we would in no way expect end-users to undermine their financial security in pursuit of this. We would therefore like to point you towards our opening statements at the start of the AU development cycle in which we clearly laid down the requirement for higher end machines, by comparison to the requirements of the current WIN release.

The reality is is project has taken years of development to date and you have therefore had plenty of time in which to make financial preparations and allowances. Our legal team has advised us that your late discovery of the development is not our responsibility and we therefore cannot be held responsible for any financial woes you may incur at this stage.

However as a sign of good will we are willing to discuss the inclusion of a billboard or similar advertising space, on which you can display your concerns and opinions to the public. If you wish to take us up on this offer please send a private message to AIA directly.

Furthermore it is not the intention of AIA to highlight the crapitude of one's own addon endeavours, but rather to give them attractive and functional buildings in which at least to hide them!

Yours
AIA CEO

Ps. Paddy, your post really made me chuckle, thanks muchly for the convoluted compliments!