Jump to content

Nicholas G - 1397820

Members
  • Posts

    368
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by Nicholas G - 1397820

  1. I haven't used it in a while, but I can replicate the same issue as above regardless of airports. Possible it's been like this since the update and no one has noticed?

    In the meantime, Flightaware's IFR Analyser (it's spelled with an 's' for goodness sake!) is your friend, at least for flights in Australia, New Zealand and North America.

  2. What's the reason that controllers log off with traffic? I assume people have their reasons?

    For myself, I tend to get on earlier because there's a short window of time for me on a Monday between getting home from work and having to be an adult and get other stuff done. There's usualy at least some pilots who are flying early for whatever reason (less in the last few weeks). But I don't think I've really controlled properly for a Milk Run for a few weeks anyway apart from yesterday, or if I have it's jumping in late in the piece to do a short stint stint when the ATC thins out but there's still traffic (I did this a few weeks ago as SY APP when tower and WOL weren't open. SNO was extending.). Certainly been a while since I've been able to do the whole thing.

    A booking system is a good idea and I think should be pursued regardless, but surely if ATC is logging off early, a system don't cange that? Presumably it then means others will jump on when the ATC dries up because they'll know in advance and won't be flying, but that also means there'll be fewer pilots flying?

  3. Really, afaik Tristan, the only major change you're proposing is the cct freq addition. Given VATSIM BK gets as many movements in multiple years as RL BK gets in a day, it's not strictly necessary. Even then, I'm not sure on procedure, but I think if ever by some miracle the traffic justified it, the cct tower could be opened as non standard by proper persons under our current policies. Everything else you would need for network ops is covered by LI and ERSA.

     

    Are there other specific changes you are talking about not addressed elsewhere in this thread?

    • Thanks 1
  4. Probably because you aren't ever going to procedurally separate anything. There's basically no time to do so. My understanding, IFR arrivals and departures into and out of BK are going to be separated by Approach as Jake outlined (most likely at BK visually, in which case there's no need for other procedural sep anyway), 1 in 1 out or depart OCTA visually with traffic from approach. Normally I expect in the latter case they would depart VFR anyway if BK was VMC. If BK was IMC they would depart on release from approach and there would be no VFR aircraft. VFR arrivals don't receive separation in the airspace, only for landing per standard aerodrome control.

     

    All that's really meant by procedural is no radar to the ground. That doesn't necessarily mean you are providing procedural approach services, which is the key difference between the Metro Ds and the published procedural towers. Bankstown does not clear or sequence instrument approaches or departures. Of they are VFR, they do not ordinarily require procedural Sep because a) class D only and b) they should always be VMC.

  5. 6 hours ago, Cam Tyson said:

    Tell me. Who clears an IFR aircraft for its approach at Bankstown?

    Me :D

    Quote

    On a side note, are there any recommendations you would like to include in the Sectors? I.e VFR Reporting Points, which display for the Tower Controller (Full name)

    I.e at Bankstown, all Reporting points are displayed as a Fix?

    Josh, afaik, all VRPs and basically any visual waypoint that is encoded in this list from ERSA already exists in our sector files. Most of the ones that Tristan has mentioned exist in there already. Some like the M7 M5 interchange aren't, but are just used for when you can't spot 2RN,  so are proxies for other waypoints.

    They don't get used online as often (if ever) compared to the published reporting points for BK, mostly because a) very few pilots fly VFR out of BK and b) BK TWR is rarely on and c) when there are both pilots and tower, the reports are usually limited to the published entry points and d) they're less frequently replicated in scenery compared to 2RN and PSP. Even RW you rarely hear those used, although they can be. I don't think I've personally ever heard anything other than PSP, 2RN plus the Choppers check points and Warwick Farm within CTR. The TWR just generally isn't too worried about aircraft reporting further away from the point of entry into their airspace. There's literally NEVER enough traffic online where the TWR would care about pilots reporting anywhere else. 

    BK already is treated as procedural on the network when it's active, but it's not super important in terms of applying procedural seperation as BK doesn't own enough airspace where it really makes a difference. You're not clearing IFR approaches and you're dealing with aircraft joining from a few miles away.. You're operating on tower view, you don't have transponder info or altitudes. You're also dealing with VFR mostly, so you're only providing traffic for the entry and seeing as they're in the circuit pretty soon after entering CTR, you're basically just sequencing in the circuit for landing. 

  6. Hm, appears I was wrong. I do remember I once had polygons for AS, but I just grepped my whole Euroscope dir  (including backups) and got nothing. Maybe I hallucinated that :P. Tindal and Darwin are both in there, but for AS it's only the free text taxiway labels.

    You'll just have to eyeball it, unless someone can find polygons somewhere else. AS is not difficult to taxi, so you should be fine anyway. 
     

  7. iirc from looking at it a while back, the alias file is actually already pretty close, if not precise. Most people just muck up the readback. But they do that over voice anyway :P 

    EDIT: Don't seem to have a copy of the original alias that iirc came with the VATPAC installer, but I definitely remember it being pretty close to what AIP spec is. I've fiddled a bit with it to generate this (mostly just adding kinda useless extra information like EOBT :D ), using a lot of the inbuilt variables in Euroscope.
     

    .pdc PDC $time ZULU $aircraft $type $dep $ftime(20), CLEARED TO $arr VIA RWY $deprwy $sid DEP: xxx ROUTE: $route, CLIMB VIA SID TO: $alt, DEP FREQ: $freq($1), SQUAWK: $asquawk, xxx CTC $UC($RADIONAME) ON $FREQ FOR READBACK OF DEP & SQ $2... xxx PDC END


    So, on typing ".pdc" and then space, the list should populate taking you to item $1. You would type the short code for that controller position (for instance, Sydney App 124.4 would be "sa", iirc), then tab, which would take you to the $2 variable where you could either type extra comments or just backspace then enter to send. The rest should all be populated automatically if their flight plan has been filled. I've assumed the readback will be on your freq, so the list will populate that last line with your callsign and frequency. The $ftime function is just to generate an EOBT of 20 minutes from "now" in UTC. You could also alter that '20' to another $n variable to allow the controller to specify the EOBT for each PDC individually.

    So for instance, this is the output running this after logging into Biggin Approach to test (EGKK GND was filling flightplans and london control with short code 'L' was online, so extra convenient :P). To get this, all I had to type was (.pdc [space] l [tab] LOL)

    PDC 11:04:00 ZULU EZY107 A320 EGKK 11:24:00, CLEARED TO EGCC VIA RWY 26L LAM2X DEP: xxx ROUTE: LAM N57 WELIN T420 TNT, CLIMB VIA SID TO: FL240, DEP FREQ: 123.900, SQUAWK: 3273, xxx CTC BIGGIN APPROACH ON 129.400 FOR READBACK OF DEP & SQ LOL... xxx PDC END

    Only bummer is no capacity for newline characters on the ES commandline to format it in lines like it would be IRL, so it's perhaps a tad difficult for the user to parse.

    • Like 1
  8. Might be nothing in MATS, but that's because PDC is not really relevant to most of the scope of MATS. There is a decent chunk in the AIP about PDC (ENR 1.1 - 6  2.2.25). I've picked out the most choice examples below:


    Screenshot_116.thumb.png.f8d92e9afe26003bed2a20b0d6bc149e.png

    Screenshot_117.png.730265a44fda93904ca7ff6640d8575c.png

    There's no real reason not to use them as much as you or pilots want, IMO. They're convenient.

    • Like 2
  9. Seems to me that if there is an intrinsic issue with a text based service, the issue is hardly with the nature of the technology (a mechanism for exchanging information is hardly in and of itself either 'good' or 'bad) but instead with the nature of the people who use it.

    If what we are discussing is anti-social and/or abusive behaviour on these services, the question then is not really what service we use, or even whether individuals may or may not use it, but really whether or not we are prepared to adequately police it. That may well apply to Teamspeak as much as Discord

    And, again, I don't think any step back to Discord need be an all at once re-implementation. Doesn't even need to to be an all or nothing one. There seems to be little disagreement with the utility of the training and coord text channels. Is there an in principle problem with those services as well?

  10. FWIW, there's no reason we couldn't open up every other text channel and leave the question of re-opening lounge chat unanswered until a future date. Either way, the unofficial Discords will be used for that purpose, so there's no biting imperative to re-open that channel. The channels that do actively aid the flight sim experience (screenshots, the text coords and the training chats) could be switched back on in the meantime. 

    • Like 2
  11. I am the controller in question. While also appearing over GEO, it also appeared that he was over the CTR boundary. However, I think the CTR boundary doesn't actually go out to water past the coastline in that section of the CTA.

    I can totally understand why a super high fidelity diagram in the scope would be a huge PITA, so don't read this as asking for one :P But if you were going to trust the GEO region or the CTA boundaries on the scope Richard, which one would you favour in terms of what better represents the exact and real position in the RL and/or high fidelity sceneries?

  12. Obviously there's not an easy way to get around the policing issue in real time, but I think given that everything apart from lounge chat was functional ((so the training text rooms, support channel and the screenshots lounge)), at the very least I would be in favour of turning those back on. I think we can bring back lounge chat, but I'd consider the following ideas be in the mix:

    1. Locking lounge chat for small periods of time if we get anything close to the meltdown as a tool available for use. Not sure if Discord perms allow you to cap the length of time you can allow Staff to lock a channel for (if you can, I'd consider giving all Staff that perm), but in lieu of that, those staff with the appropriate perms to consider locking chat to be a tool available for them to be used not merely in exceptional circumstances.

    2. A zero tolerance policy for anything that can be considered anti-social or anti-community. I think a 12/24 hour cool off period for most if not all such infractions would be a reasonable default disciplinary tool in real-time situations. Simply moderating content is only going to be useful for off-colour memes, etc. Warnings are probably not effective in getting people to back down. Removing people from the server and/or locking down text channels for a period of time are. Also, I think we can afford to be more hardline than strictly necessary to begin with. If everyone plays nice, we can relax enforcement a little, but we probably need to set the example by being zero tolerance on anything that remotely stinks, with some maximum time-limited ban being the default setting. The core objective must be to create a safe and peaceful environment for everyone, and everything else should serve that cause.

    3. Not sure if this is in the current discord/teamspeak policy, but I also tend to think that short kicks (24 hr or whatever) from the server should not be able to be appealed or rolled back by any staff member regardless of subject or grounds except where it's a clear and obvious abuse of power with no intention to foster a positive environment on the Discord. This would perhaps encourage staff to use their power without any of the previously mentioned concern about blowback or whatever. It is important I think that such small measures are implicitly supported top-down. A single 24 hour kick should subsequently not constitute 'bad standing' on behalf of a member, but repeated such infractions should be.

    4. Staff need to bind themselves to whatever policy we come up with as much as anyone else, if not more so.

    I would also recommend perhaps putting together a short guide for the folks less familiar with Discord. There are plenty of people who don't like the constant notifications from the text channels who probably should be shown how to mute those. It's not difficult to essentially turn Discord into Teamspeak with a better voice codec, but I feel people might need a bit of help.

  13. Yeah,  my understanding's the idea with choppers at Bankstown is that you report at the same reporting points as the fixed wing aircraft (2RN or Prospect Reservoir) and at the same altitude (1500 ft), but you will then get a track via one of the Choppers check points (West or North depending on active RWY from PSP, or South if via TWRN), and also a circuit join (W: Left base, N: Right base, S: overfly the field at 500 ft to downwind). The circuit is based on the Main pad (the one to the SE of the aerodrome). Once you're inside the CTR, it's 700 ft unless you get an altitude restriction from ATC.

    • Thanks 1
×
×
  • Create New...