Moa

Here are some development notes about X-Plane 10 http://forums.x-plane.org/index.php?showtopic=47604

aaron886 you're very nearly right. The US Navy uses 800 feet on downwind until abeam and then 400 feet on final at 3/4 mile astern of the carrier. Final approach speed is 140-160 knots depending on aircraft and loaded weight (fuel and ammo left). of course, the Navy pilots are exceptionally good so they have a lower safety margin than other pilots are used to. This info comes from the carrier-qualified former commander of the US Navy undergraduate pilot squadron VT-2 (a member of VNAO and known to these forums as "Pop"). If I remember I'll also find the relevant page of the NATOPS manual that specifies these values. ps. as always, don't forget to trim your aircraft in the circuit.

Thanks Bucic.

1500 feet is not unusual for a 'circuit' altitude (used in the real world). Low enough that the descent doesn't have to be too steep, and high enough that there is some safety margin. If you start from this altitude at a reasonable speed (maybe 350 km/h or 200 knots) then you'll find landing much easier. Many new people try landing at 450 knots from 10000 feet while 5 km from the airbase since they don't know reasonable numbers. So, 1500 feet over head the base at 200 knots is good to start with. Just remember to extend a little before turning on your base leg to land, a good rule of thumb is that the runway end you will land on should be behind the trailing edge of the wing when you look toward the runway.

Thanks for re-posting the clip link sweinhart3. Readers please also note that a track is actually worse evidence than a video - at least for the issue being discussed. A video shows exactly what was seen by the user, provided it was recorded at the time of flight. A track does not necessarily show what the player saw during the mission. All sorts of weird things happen: the player can be killed early in replay, yet they survirved a whole mission, or vice versa. This was a well known bug in FC1 but seems to have gotten worse in FC2 - but this thread is not to discus this bug. All I'm trying to say is that a track gives some evidence but it is not as good in this case as a video recorded at the time of flight. @slug88: note that 159th_Viper posted that the Maverick seeker behaviour was 'tweaked' by ED to be more 'realistic' (that is, the changes are deliberate) http://forums.eagle.ru/showpost.php?p=912988&postcount=3 "Depends on the Vehicle you are attempting to gain a lock on. Values/Parameters tweaked to accord insofar as possible with behaviour in the RW - No 'Majik Mav' any more - gotta work a wee bit harder now And again from 159th_Viper, indicating that the tweak affects different vehicles (hence, I conclude that the degradation is not accidental, but affects SHORAD): http://forums.eagle.ru/showpost.php?p=913161&postcount=10 "Strela-1 does that. With the Strela-10 you will obtain lock timeously. As I said - as with RL, all depends on the vehicle's characteristics as to when the parameters will be satisfied to enable the Mav's seeker to obtain lock - nothing untoward" Perhaps I read these wrong, but given the paucity of information about the changes (are they mentioned in the official 1.2.1 patch changelog? I didn't see them) then I don't feel that the conclusions I drew were unsubstantiated. I'm not trying to rag on Viper, he's doing the best job he can as a volunteer (and I appreciate his contribution - which is committing a significant amount of his personal time to testing for no pecuniary gain), merely saying that these were posts from an ED Tester and that's all we had to go on since ED itself did communicate these changes or comment definitely on them (better communication would help a great deal). Actually, later in the thread Viper admits it was a guess on his part based on trial-and-error (thanks for venturing the guess), so I doubly don't want to seem like I'm blaming him. Please just watch the video and watch the seeker slew incorrectly and also jump to a wrong location when 'locked' :) No need to say anything and lose face, if you agree after watching the video then be silent and we're all cool. Otherwise, tell us where we are going wrong/what is happening and we'll listen.

The slew bug is a problem but what is driving the users nuts is the lock bug where it jumps to an incorrect target or location, even if there is only one target in the field of view. It is the lock bug we are trying to get some action on - since the slew bug has been already acknowledged. Let me be clear, I am not discussing the slew problem. slug88 please take a look at the video posted by ralfidude. I experience the same effect in a systematic manner. If you have a criticism of the video I would be interested to hear it - I do have an open mind. Until you look at that video there is nothing much we can discuss in a productive manner. Yes, a video is not a good as a track. Point taken. However the video cannot be dismissed as it is experienced by many users. Dismissing any evidence just because it is not in your preferred format is weak and the sign of an inexperienced tester I'm afraid. We can dance around who said what but I'm not interesting in playing forum lawyer. I urge you to please look at the video. Since it is not peculiar to a single user but, as I said, is widely experienced by many users it should be treated as some kind of evidence (despite not being a track). Again, the thread keeps getting deflected/derailed instead of critically examining the user's experience (eg. asking questions would help). > Vaguely written bug reports are useless without tracks to analyze. If you had listened, you would've realized that Viper was asking for evidence in the form of tracks, and until presented with such he had no reason to believe there was a bug, based on his own experience with the game's Maverick seeker. I'm calling BS on this one. Part of my consulting development job is to analyze faults in complex systems where you have restricted access and can't get all the logs you want. The world is not always ideal. You don't simply dismiss people's reports because they haven't given you what you exactly what you wanted but instead gave some other evidence. Instead you carefully examine the evidence to see whether it is a user fault or could actually be some fault in the system - even if you cannot see in your own development or test environment (it took some time in my own experience before I stopped being arrogant enough to realize this can happen quite often - I'm merely trying to impart the same wisdom I acquired the hard way). If you think about it hard, a track won't give evidence about the problem we're trying to report (except if you think that it could only be due to user error when they try to lock from too long range - which I assert is not the case). > Sorry to be so blunt, but if anyone was taking a piss at that point it was you. Wrong. It was obvious 159th_Viper was preparing to assert that we/I knew didn't know anything about seekers. I was trying to stop the thread getting derailed by that argument as I have a great deal of theoretical and practical experience in that area, including military grade IIR sensors from the era in question. In this case, the user's are trying to help each other and ED by reporting bugs to the best of their ability (in my case, I don't have more time to devote to chasing this down - since I spend a large amount of my spare time getting software going for LockOn, often working past FC1/FC2 bugs and bad design decisions, but I digress). You can chose to try and listen (watch the video, please!) or you can choose to only focus on perceived flaws in forum posts while completely ignoring the thrust of the discussion. All we are asking is that you watch the video with a mind open enough to consider what is shown may be occurring on other user's systems (even if it does not occur on your own).

Notes: 1) This is not a 'bug' per-se in the seeker code. It was deliberatly intorduced into the Maverick seeker model to make it more 'challenging' (although in effect, frustrating) to A-10A pilots since they otherwise dominate air-to-ground. Therefore, until ED decide differently this will not be fixed.This seems to be in addition to a more realistic Maverick seeker model where the seeker lock-on range was reduced (although the first effect applies even at very short ranges). 2) The Su-25T's Mercury pod does not appear to be affected by this (not that I can see, at least) despite being inferior technology to the Maverick seeker electronics. Yes, this sucks. No, there is nothing we can do about it.

Have a look at the =RvE= Yoda's leavu2 utility (search these forums). That streams in real-time. I extended it to get the same mechanical information you do, but I was after tail-hook status and Angle-of-Attack indicator for VNAO carrier landings. nb. leavu2 is written in Java (which means you can run it on your Mac, Linux/PC as I do - which is something C#/Mono can't do interoperably). Should be easy to port the bits you need to C# (since C# was designed from Java via an intermediate language called 'Cool').

You want a background storyline? well, what about some recent real history to get you in the mood? These might be handy for some historical perspective: http://en.wikipedia.org/wiki/Georgian_Civil_War http://en.wikipedia.org/wiki/2008_Georgian_spy_plane_shootdowns (buildup to next war, aerial only as Georgians watch Russian preparations, so good to model in LockOn) http://en.wikipedia.org/wiki/2008_South_Ossetia_war and for a fictitious one: http://en.wikipedia.org/wiki/Third_World_War http://en.wikipedia.org/wiki/Able_Archer_83

In addition: 11. Takeoffs and landings from aircraft carriers, cruisers (don't forget these, and oil rigs etc), and FARPS should be treated in the network scripts as any other runway takeoff. At the moment they are logged but the user-editable function in the network scripts is not invoked in all cases. 12. All events should include the 3D position (lat, long, alt) of the units involved. This allows things such as simulated probabilities for Search-and-Rescue and determination of A-pole and F-pole distances for launches. 13. Landings should include the side of the player and the side of the airbase/territory at the point of landing (since the airbase/FARP can change coalition due to a takeover). Landings reporting the closest airbase is ok, provided the 3D information suggested in #12 is included to distinguish 'landing close to an airbase' to 'landing at an airbase'; and 'taking off from a runway' from 'taking off from a taxiway' (antisocial! except in scramble situations). This is a regression from FC1 (which used to have such information). 14. It should be possible to correlate an initiator ID with a callsign. A function that could be called in the user-modifyable scripts would resolve this. 15. Chaff and flare release should be logged (if individual shells are, so should chaff and flare - for post-battle analysis). 16. Each event should have both UTC time (determined by the host's clock) for display purposes (in stats boards) and mission time-of-day (eg. to determine whether a carrier landing was in daylight, or at night [harder!] and can be also used to adjust flight durations to account for temporary admin-induced pauses in the game). 17. Both logs (network and debrief) should have common timestamps (with millisecond precision). At present one uses mission time-of-day and one uses time since the mission was loaded. Both logs should use have both UTC and mission time-of-day for every event (both to millisecond precision). 18. Every event should be self-contained (you shouldn't have to read any other events to determine everything you need to know about the current event). This means every event should include: timestamps, coalitions, callsigns, unit type, unique unit ID (needed for dynamic campaign), weapon names, 3D locations of all units, airbase/carrier/FARP name, event type identifier. Edit: This is useful so you don't have to maintain state between events for basic statistics - improving reliability of stats systems (if parser crashes and can't read one entry it can still read the others) and make them faster to process (real-time stats, which is the goal of the 104th stats system when released). 19. All information that is presently been added since FC1 should be preserved. For example, it is excellent to know the skill of an AI unit (with upcoming 104th stats uses this to adjust points for kills). 20. LockOn should never overwrite or delete any logs. Ever. For any reason. This means the 'cleanup' script should go or be configured off by default. The disk space used by logs is trivial in modern terms. Edit: Preserving all logs is important. We go through considerable effort to collect then logs so we don't want them deleted for any reason. Preserving the logs allows old data to be re-parsed in the case of a bug (which I have had to do in the past and allowed Case to do this in the last week or so) or a new feature that can make more use of existing logs. 21. A unique identifier should be placed in each network log and debrief log to tie them together. I recommend the same timestamp that appears on the mission file name, eg. 20100913-0845 22. Important: The debrief log should get a timestamp on the file name the same way that the network log does. That stops it getting overwritten on misison restart (which means an automated backup of the debrief log) and it is easy to see what debrief log goes with what network log. It is then easy to see what is the latest debrief log (using the timestamp in the filename), or even scan the directory for all the debrief logs that have not yet been processed. For the 104th stats it took me a while to do the same with a combination of LUA (by changing the network scripts, which is a maintenance hassle to integrate with each Servman version) and Java threads (my stats program that does the file renaming). Also note that I couldn't get the log file name/file name timestamp using LUA alone. 23. There should be a trigger action that allows writing to the debrief log. Oops, duplicate of Cases #10. Very useful, so repeated for emphasis. 24. Collisions should get their own event type, not appear as a generic 'hit' (you see this with aircraft collisions on taxiing and hard landings on carriers). 25. Better documentation/consistent naming of LUA functions and parameters. (I'm a professional developer, so I know I'm dreaming with this one). 26. The debrief log should include the mission name as an attribute of the mission start event (I got this slipped into the network log [thanks guys!] but it should also be in the debrief log header as well). 27. The user-editable scripts in the network scripts directory should be able to set and read (server-side) triggers in the mission at runtime. For the 104th stats I had to add much of this information myself (thank good the system is now flexible enough to do this), but some information is still out-of-reach for us 3rd-party integrators. It sucks having to write the LUA to fix these things since it is now a maintenance hassle to adapt to each new version of DCS/LockOn and ServMan. FC2 has made great strides in the logged information, but took some back-steps as well. I hope A-10C moves further ahead as well. In general it is better to log too much information rather than too little (as long as logs don't get above a few megs for each long-running mission, which they don't).

Thanks for making the video. I see similar behaviour with the Maverick D seeker (it seems worse in cities as you see). This doesn't seem realistic as it occurs even at close ranges (under 2 nm).

There is something to be said for developing a product in an evolutionary fashion as ED do, and this is one of the benefits.

Chicki, I'm still running Win XP 32-bit on one machine. Yes, I know your platform and problem are possibly different - but the solution I used for my problem just may help you. I had problems with TrackIR and the ATI drivers (since 10.3) and found that if I ran the TrackIR5 software in "Compatibility Mode" (for me, compatibility to Win 2000 worked) then my TrackIR worked fine with FC2. This was a known problem on this platform for ATI drivers past 10.3 but NaturalPoint have not yet fixed it.

IIRC wingtip missiles also have a dual purpose to prevent flutter resonance on some aircraft. Doesnt apply to the A-10 though.

Wonderful. Any chance of getting a trigger action that would let us write to the logs (debrief or network)? Would also be nice to add a waypoint or adjust waypoint coordinates. Sorry, don't want to start 'wishlist' but saw the Message action and thought a LogMessage action and waypoint modifications would be great.

You might also like to ensure that your anisotropic filtering (AF) is lowered to something sensible like 4x. If you have it at 16x it will make a noticeable difference in fps on the ground. I noticed that even my Radeon 5970 was brought to its knees in LockOn if I had AF up at max. Turning it down made things a lot smoother. I didn't notice this problem in Armed Assault: Operation Arrowhead (could run with AF on max) but I think that LockOn has far more polygons on screen in general (being mostly at ground level Arma gets to make some optmizations - and when it is in the air the visibility range is tiny compared to LockOn - plus it can use all four of your cores as well). Also check anti-aliasing (AA) is not too high either. You might have a faster machine but they never seem quite fast enough to run with all the LockOn settings on max as well as all the graphics card renderings on max too. Also make sure the number of frames being pre-rendered is not high. I set mine to zero, since when you really need the frames, during a furball, you are turning quickly and the pre-rendered frames are probably wasted effort. The difference between the multiplayer experience on the 104th and the single player experience may be because the multiplayer server may be reducing your visibility distance or world detail level (required to prevent a player with a bad computer introducing a lot of lag to all other players). I haven't checked with the 104th admins, but this is likely to be the case (and explain what you are seeing). You could confirm this by seeing if there is a frame rate increase if you decrease the view distance and world detail in a single player mission you create.

Yeah, the ability to write to both the network and debrief logs is awesome. Especially the ability to write to both simultaneously (which means you can synchronize events). Any idea on whether the Hog logs might change radically? or will they be more evolutionary? Edit: I tried to hook some of the position information from the export functions in, but wasn't successful. I'll give it another go soon though, and will let you know (on this thread) if I manage to get it going. Imagine your missile stats measurements if they also had altitude info, A-pole & F-pole as well.

I'm curious. How did you correlate the initiator ID with a callsign? I tried using net.get_unit_property(unitid, 1) but only seem to get: "!invalid property!" returned although this seems correct according to the (sparse) documentation at scripts\net\readme.txt. In the end I wrote custom LUA [nb: I don't like LUA :(] in the scripts\net\events.lua and scripts\net\server.lua to get stuff in the format I wanted (and to try avoid some of the anomalies that the default logs have). Here are some examples of the resulting logs if you are interested (taken from multi-player VNAO missions I've hosted). They are the same as the original logs with some extra 'dynamicscore' events inserted that have more 'stats-friendly' information in them: http://stallturn.com/wiki/upload/20100904/JAR_DEPOTS_RAIL_debrief-20100904-1302.log http://www.stallturn.com/wiki/upload/20100828/debrief-20100828-1228.log As always, I'm happy to send people these scripts if they want to use them, or wish to learn how I did it. They'll be released publically once I've finished by dynamicscore2 software (nearing completion), but could change if I find some problems. Also note that you have to adjust scripts\net\cleanup.lua or your logs will get wiped after seven days (horrific, logs should live forever as backups, in case the scoring software ever has bugs - doing this has saved my bacon a few times). Case, HiJack: if I figure out a way of differentiating jettisons from shots I'll post it here. Although even parsing the export.log wouldn't help in this situation I think.

As always, excellent work Case. What would also be worth knowing is launches vs hits & kills. There we'll see the spamming vs sniper effect - if there is such a thing. nb. In an earlier post someone mentioned milliseconds for radar. You are three orders of magnitude too high. Light moves 3 m per nanosecond in a vacuum (and essentially the same speed in the atmosphere). To travel 30 km and back is 2 microseconds. Of course there is additional processing time and integration time as multiple pulses are accumulated. But the timescale is short. So, next time prove by doing the math please instead of wildly speculating (which is largely what this thread is about). @GGT: Your 'wet dream' page can be done with the server exports just not with the debrief log that Case (and myself) are using. We just haven't got around to pulling that information out of the export logs yet.

mikoyan, the problem with the collaborative aspect is that sooner or later someone shows up wanting to fight others in air-to-air. Ground pounders know this all too well, they can be working together on a server and then someone pops into the server and starts shooting them down, stating, "Well its war, deal with it!". I conisder this is very bad manners for the person who does this but I realise I'm completely outnumbered by people who do think this is perfectly acceptable. To get colloboration you need two things: a) discipline: you need common objectives and everyone must work together to achieve them, and b) communications: everyone needs to talk (and listen!) as part of a team. Many servers provide this and channels open to all players (eg. the 104th Teamspeak 3 server). The problem is that many players are not interested in these things. As soon as you have more players that are impatient (won't wait for their teammates) and ego-centric (prefer a high personal score over a high team score or the thrill of being in a team) than team players then collaboration breaks down quickly. The problem is not the missions, it is the attitude and desires of the people that fly them. This is why slightly exclusive events such as RedFlag (note: open to squadrons and lone-wolves alike) produce superior collaboration, regardless of the mission scenario and set-up. I known the mission designers of the 104th would love to have fog and overcast and clouds and lots of units and all sorts of good things that you mention. Many people complain (loudly!) that their machines can't handle it. So the missions are made relatively conservative (all it takes is one player with a crap computer that can't keep up to induce lag in all players - which sucks for everyone). This is where other servers get to cater for more specialist needs (which is why it is a good thing that there are lots of servers out there trying all sorts of things out, as well as the popular and 'safe' 104th server).

Doesn't stall properly, no sharp wingdrop in stall (therefore no autorotation), doesn't recover well/at all from deep accelerated stall, tailslides/stallturns don't work right (looks like the mass distribution and resulting moments of inertia might not be right), etc, etc ... Of course, these are all outside the normal flight regime (how many people/developers think about negative airspeed!). However, this is a simple test of any aircraft simulator and the first one I apply to any sim (suprisingly Wings of Prey has an excellent feel in stalls and stall recovery, which is suprising since the rest of the game is certainly 'sim lite' or even 'sim zero' ). I have my fingers (and controls) crossed for the A-10C :) Note: I have not flown a real Su-25T so maybe it really is that much of a stall pig. But it certainly doesn't follow the way the aircraft I've flown feel in these maneuvers. Edit: Incidientally there was a post that Microsoft was the biggest software company. This is not true. It has fewer employees than several companies (eg. IBM, HP) and lower market capitalization than Apple. Just statin' the latest facts so people aren't behind the times any more.

That "freeware program" was of course Tileproxy: http://www.edtruthan.com/tileproxy/tutorial/ Google objected to Tileproxy obtaining texture tiles from the Google servers. Fortunately there are plenty of other mapping servers (Nasa, Microsoft) that did not object. The (open-source!) equivalent of Tileproxy for X-Plane is called G2XPL, although that is much harder to get going. Also, Joe Kerr experimented with integrating TacView data for display in Google Earth. This is fairly well documented by the Googlers - although the downside is their preferred integration route is using JavaScript (ugh!). See Joe Kerr's post, which has some great visuals: http://forums.eagle.ru/showthread.php?t=53517 Of course Google would like to do this. They would then own the servers on which this runs, and the resulting collected data. They they have you trapped and can decide how to monitize this later. It is bad for a single entity (commercial or otherwise) to hold access and control to *your* data. It may not be a problem now but it could be in the future. Don't exchange your freedom for convenience. It is good you got the DCS name under the noses of Google Oscar but we (as a community) ought to be wary of allowing others to control over our experience. Especially when talented folk like Joe Kerr have shown they're perfectly able to create their own solutions without handing over the 'keys to the kingdom'.

Yeah, I know just how much effort goes in to a stats system. Very well done Case and the 51st.