Jump to content

bmaik

Members
  • Content Count

    114
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

6 Neutral

About bmaik

  • Rank
    Member

Profile Information

  • Gender
    Male

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

2,005 profile views
  1. I'am asking this question since I would like the FSGlobal 2020 Next Generation mesh which was recently released for P3Dv4/5 also in FSX. The developers told me that the product is not compatible with the 32bit sims since they allegedly use another file format, but somehow I doubt that this is true. Is there something like a "64 bit mesh"? I guess you guys here in this forum should know the answer whether there is a difference and more importantly whether I can install or transform the P3Dv4/5 mesh to FSX. I think of a reverse engineering process like decompiling the FSGlobal mesh BGL files for P3dv47v5 to a format (possibly some image format?) such that I can recompile them using programs like resample.exe to a bgl-format that FSX (and also P3Dv3) understands.
  2. I have used FSFlightkeeper for more than 20 years now via network in FSX with a valid license and no problems. Since beginning of 2020 I am suddenly having a strange problem. After initialisation of the ACARS device, it says "Trial Period ended" and can't be started although my license is still valid. Setting back the system time to an earlier date in 2019 resolves the problem, but as you can imagine, changing the system time is not really the workaround that I would like to use. Can anybody confirm this problem? Or even better: Did anybody already find another solution than mine? Any help greatly appreciated. Regards, draci
  3. I can confirm thatt VADriver was right: For the last 5 flights Vox always used the first frequency in the runways.txt file if an airport had multiple frequencies for the same station, so this can be considered solved. Thx vadriver, once again.
  4. Thank you vadriver for the excellent hint, strange that I've never tried this before, I'm going to check this out on my next few flights and report back.
  5. Thank you vadriver once again for the hint, I'm going to check this out on my next few flights and report back.
  6. Hi to all, Does anybody know how VoxATC decides which frequency to use if there are multiple options? For example, in reality many aiports have multiple approach frequencies and depending on the sector an aircraft approaches from, one of these will be assigned. I don't think that the sims (FSX, P3D, Xplane) support different frequencies in different sectors of the same airport, so I assume that Vox simply reads the frequencies in the order they are listed in the airport.bgl file, but so far, I didn't manage to find out the logic according to which a frequency is picked. It's neither always the lowest nor the highest one. Does anybody know how Vox prioritises the frequencies? I assume Vox simply takes the first frequency that it listed in the bgl. but how can I see the order of frequencies in the airport.bgl file? Is there an external program (ADE,AFX) that shows the frequencies in the right order such that for example the prioritised frequency always shows on top in the frequency list? Best regards draci
  7. This happens if your aircraft enters a region for which Vox ATC doesn't find a matching FIR entry in its bglcenters.dat file. It then defaults to "Anchorage Oceanic Center". If you use fsaerodata by any chance, the problem is that they use incomplete and inaccurate FIR boundaries (which default FSX does at well) and still haven't fixed this (although it's payware!). My workaround was to define my own FIR regions with correct frequencies over the whole world which is, of course, a lot of tedious work. I did it gradually, flight by flight during the last year and by now I have about 90% of the global FIR's covered. I wrote my own little program to match the bglcenters.dat structure, and used a combination of Google earth and internet resources to define the FIR polygons to match the FIR boundaries correctly. I can confirm that after indexing VoxATC uses my FIRData correctly. draci
  8. thank you, vadriver, honestly, I've already thought about decompiling the code, compare the v6.52 and v7.42 .dll files and fix the thing myself... although illegal, it should be at least possible with a little .net-programming experience, if I invest a little bit of my precious time, and since we all don't get any support at all, probably the last resort...However, I'm still waiting for Tegwyn to reply.
  9. I've transited from Vox 6.52 to Vox 7.42 recently because of the latter's ability to read the flightplan.bgl files which I generate from AILiveTraffic. This allows me to have realistic traffic controlled by VoxATC. However, I still don't get VoxAtc 7.42 to give me a correct arrival ATIS at TOD (or more roughly some 100 nm from destination) withoit restarting it. In Version 6.52 this worked perfectly, since Vox updated destination weather at TOD and the ATIS always designated the runway in the wind to be the landing runway. Vox 7.42. ATIS on the other hand always report winds calm or the weather at the departure airport in the arrival ATIS ALTHOUGH approach will later assign the correct in-the-wind runway for landing. The same problem occurs with STAR assignments which are often wrong and are not available for the runway that will be assigned later because of a missing or wrong weather update at TOD. Even if I manually close some runways in the AFCAD Vox 7.42 ATIS ignores this and reports the manually closed runways as active. Since Vox 6.52 did all this perfectly, but I don't want to miss the new Vox 7.42 flightplan features, I'm still trying everything to get the best of both versions, but now I'm at my wits end. I even tried to combine the 7.42 indexer with the 6.52 VoxATC.dll with not much luck. Since I can't get through to the developer (ignoring my emails and pleads for years) I ask whether anybody has found a solution for the ATIS problem or can get through to the developer to ask him to fix in v 7.42 what was already correct in v 6.52.? That shouldn't be a big issue. Best regards draci
  10. Yes, that was me, sorry to respond to such an old post, but perhaps you can help me once more, see my latest post.
  11. Sorry, of course, I meant SID instead of STAR. Does anybody have experience with mixing versions, eg. using the indexer of version 7 with version 6 or using the voxatc.dll from version 6 in version 7? For example I use the networking abilities of version 7 without any problems in version 6, the success of such mixing depends, of course, on the crucial question which parts of the Vox Code have been updated between versions, but - as we all know- the developer doesn't talk to us (anymore), I rely on your experience. Did anybody make such experiments already?
  12. Hi there, I love that Vox 7.42 respects all my AI flightplans and schedules now, but there are a few issues that are even worse with version 7 than they were with version 6. I've just done a single flight in 7.42 so far and found the following: 1. For clearance, Vox 7.42 does not give me a cleared flight level and initial altitude, but only a star and a transponder code. Can anybody confirm that this is a general flaw of version 7 or was it something special with my flightplan (EGLC to LIPZ)? However, in version 6 the clearance was more detailed. 2. The arrival ATIS stays wrong for the whole duration of the flight and is not read at TOD. Winds were calm on the testing day for the whole short flight (EGLC to LIPZ), so I expected arrival runway 04R (04L is mainly a taxiway at LIPZ), but the arrival atis reported wrong winds from 220 degrees unitl touchdown, hence resulting in the wrong star and runway assignment (I was eventually cleared for 22R). Did anybody find a solution to this? Or can anybody confirm that it can't be fixed? Version 6.52's arrival ATIS was read at TOD and I got the correct runway assignment 100% of times. Can anybody confirm having the same problem or did somebody even find a workaround (of course without restarting Vox) 3. The above facts made me think a little... Why not use the best of both worlds? So I tried to compile the traffic.bgl files and scenery files with the Vox 7 indexer, such that I get the correct AI-traffic and copied the database into the Vox 6.52 folder, but somehow this doesn't work. Vox 6.52 gives me a fatal error, so most probably the sturucture of the database has changed. But perhaps there's somebody out there who had this idea before me and was a little more successful? Any help is greatly appreciated. Best regards M.Berchtold
  13. @vadriver: Thanks also to you. I suppress vectors anyway in the "Flight Plan Extras", so I don't care too much about this. What matters more for me, is the 30 nm! In version 6.52. the weather update happens at TOD (some 100 nm out), so I might possibly get the wrong star, but approach finally clears me to the correct runway. I guess if the update only happens 30 nm before destination, you should already be on approach frequency by then, and approach will have assigned the wrong runway. Of course, I could request a different runway, but all AI Traffic would land opposite. Unrealistic, and a real deal breaker for me! Can you confirm that the update really happens so late?
  14. Thank you, LecLightning56, this was really helpful. Can't wait to try this when I get home tonight.
  15. That is great news! Thank you so much! I'm going to try this tomorrow too, for sure. I've already written batch code to change weekdays, convert weekly flightplans into daily ones, convert AI Live Traffic plans into AIG-like ones etc, but all this effort now seems to be in vain if the solution is really that easy! I'm eager to learn whether your conjectures can be confirmed tomorrow, I stay tuned. By the way: I totally agree with you as far as live traffic add-ons (PSXseecon and similar) are concerned. They spoil the realism if you use them on the ground. If we get AI Live Traffic to work with Vox, I will probably use a mix of AI Live Traffic and PSXseecon: the AI Live traffic origin.bgl and departure.bgl files on the ground (while swiching off the PSXseecon ground traffic), but inflight I prefer the PSXseecon Live Traffic to a randomly made selection by the AI Live traffic SAT.bgl. So I will probably use both options simultaneously inflight (the SAT.bgl traffic mainly to keep VOX controllers talking...)
×
×
  • Create New...