Moa

True. But you would have got the same result if ED had produced good documentation (and we know they can do this, the recent raft of flying and installation manuals are great) and well-tested and stable integration points. If ED had done that then the community would already have done a multitude of aircraft (there are already several Hornet and Viper projects hard up against the limitations against what is currently possible) and maps. I'm sure you've noticed that the community has been trying to add new aircraft and even terrain for ages. Why this hasn't happened on a large scale is twofold: first, there are some limits in the current design that made adding stuff hard. This seems to be getting addressed now (yay!). The second and far more significant limitation is the instability of the integration points (few docs, some howler bugs, changeability of the interfaces). This re-focus by ED on modability is excellent and coupled with the new EDGE terrain engine that I hope will make it easier for the community to add theaters - then ED may be on to a winner. Hopefully some of the mod teams that are slowly drifting from FSX to X-Plane (at least it seems that way to me) will also come this way for combat aircraft. However, a stable platform for modders is needed if ED want to see an ecosystem develop. This means interfaces change by extension (old stuff is kept working, just new features or new more efficient ways of doing the old thing are added). It also means that the interfaces need to be specified (documentation) and the implementation matches the specification. We have tried to tell ED about this in this thread, http://forums.eagle.ru/showthread.php?t=81721, but unfortunately it seems some of that detailed information isn't wanted :( If integration information is public the community will always help with reporting issues. I won't bang with specifics about the current integration points, but as a modder they pretty much don't work at the moment. They change too frequently (eg. debrief logs changing formats, accesibility, completeness or accuracy) or don't provide information that makes sense (eg. recording time in different units in different logs, different types of unit IDs and not reporting on the stuff that would actually be relevant to an integrator). Just this morning I was testing the event logs that 16th_Speed had made accessible via slmod and found that the information being logged in the event logs is probably ok for internal ED mission debriefings but falls short of what is needed by external parties - so we need to do a lot of workarounds to find information that should be simple for the system to provide. Just last night I was working on my moving map and found that fuel consumption and ground speeds reported by the export interface give incorrect values. It is this kind of stuff that will hamper EDs plans to get more modders on board and more importantly, keep them here instead of modding something else (BMS, X-Plane). To sort it out will take time, for sure, so I hope everyone gives ED the 'space' to get this done.

I jumped in the A-10A the other day and it was a simple joy. Even with the A-10C's flight model this will still be nice.

You can fire AGM-84A from the MiG-29G cockpit (that we use for the F/A-18 in VNAO, since that is the closest multirole). Then change the weapon data so that the AGM-84A data contains the AGM-88E parameters (mostly a copy and paste job). This means it is faster but with a smaller warhead. Then you can use the AGM-88E against a new target by: 1) going to air-to-ground mode 2) selecting a maverick 3) hitting O to bring up the maverick seeker 4) target designate to ground stabilize 5) target designate to lock (optically) 6) press I to engage your radar 7) switch weapon to AGM-88E 8 ) release! 9) press F6 to watch the carnage The default AGM-88E seeker head will only lock on radar emitters, so you have to guess which is which using the Maverick seeker. Given the high speed of the F/A-18, short range of the Maverick (compared to a HARM), and trouble identifying which is a radar emitter and which is not before reaching minimum launch range I decided to allow the HARM as used by VNAO to target anything (rather than radars only). I also adjusted the minimum launch range down (since your systems aren't locking automatically at long range like some of the HARM/supporting electronics modes do). Thanks to SVK_Sniper for showing me how to get going with this.

Good post. Shame I can't give you additional rep at the moment.

The hard part about multi-threaded programming is sharing the state. This means dealing with resources and memory. Who gets to write to what and in what order? Who gets to clean up? Making sure you avoid deadlocks (actually easy if you know how). Doing this in C++ (as LockOn/DCS is at the lower levels) is quite hard. This is one of the reasons why languages like Java (and the descendant, C#) were invented and have largely supplanted C++ for new development work. They have direct language support for synchronization and have garbage-collected environments, which allows for multi-threaded resource use without killing yourself trying to get it right. Aldega you are right. ED have made their single-thread core very efficient but they'll be struggling now since singe-core performance is not increasing as it used to (since the emphasis is now on many cores). The time required to make DCS run in multiple threads would not be very long - what takes forever is getting it to run properly without deadlocking or leaking resources. Doing that requires proper design and planning. I wouldn't be surprised if ED are working on this behind the scenes, but it'll take a fair while to come to fruition before it is both multi-threaded and works correctly. metalnwood: these days the per-thread context switching is so low (thanks to CPU hardware support) that programs can comfortably have hundreds if not thousands of threads and let the thread scheduler figure out what should run on what core when. The trick is to make sure that each thread does enough work that the overhead of the context switch becomes negligible compared to the benefit of the extra core. In the old days you are totally right, lots of threads were bad, but these days its ok if you don't have too many synchronization issues (which this problem doesn't have, each unit is nearly independent). 159th_Viper: actually you don't have to freeze rendering waiting for the CPU. Things like the skybox, clouds and sea can all be rendered before the foreground objects, and it is only the latter that is really dependent on the results of the current frame calculation (eg. you don't have to change the sky gradient every single frame, so can re-render with a guesstimate view transform).

The lua event callbacks say the aircraft, is dead but it is not dead and I've seen 'dead' aircraft later land and do more sorties. This is a bug because the aircraft is severely *damaged* (again, another bug where damage callback is never invoked) but is not actually *dead*. You are right that damaged aircraft can fight on. Dead aircraft should not be able to (especially dead client aircraft). While we're at it. Aircraft that are damaged on a sortie, land and repair and then later exit should not be reported as kills to the person that damaged them (this is currently happening). We live in fear of getting damaged, making it back but then sometimes getting reported as killed when we exit. Basically repairs at an airbase/FARP/vessel should clear out any damaged state.

While working on my (as yet unreleased) moving map/flight computer tool I noticed from the 'export.lua' functionality [LoGetEngineInfo()] that the fuel flow for aircraft seems to be off by a factor of 10. Once I adjusted for this factor (dunno where it comes from) then the flow matches observation. I noticed this on the MiG-29S, but I think it affects all aircraft.

Amen.

Thanks Nate. A) AGM-65 Maverick Lock Bug affects the A-10A pretty badly. I know some of this was by design but some times you were completely unable to lock a target even when you were close, with a clear uncluttered field of view. I guess the A-10C Maverick logic may sort it anyway. I'll try and update this post with the forum thread about this. B) Aircraft spawning over parked aircraft. Actually happens in DCS too. It is impossible ahead-of-time in the mission editor to know where AI aircraft will park themselves. If they choose to park in a ramp slot that you've allocated to a client then a player will spawn and die (and get a teamkill on the AI aircraft :(). An easy solution would be to not allow AI aircraft to spawn on a slot reserved for a client, but if there are many clients reserved but few slots used then this leaves little or no room for the AI aircraft to park. The best solution would be for a spawning player to be allocated their slot provided it is not occupied by any object (aircraft or moving vehicle) and get allocated to a different unoccupied slot if necessary. C) Modded aircraft to fly on the carrier (eg. MiG-29K) roll backwards without their brakes on. All aircraft on the carrier should 'stick'. D) Aircraft moving relative to the world but stationary relative to the carrier are logged as crashes on exit (sucks when computing pilot stats). E) Refueling boom not visible properly in multiplayer. F) Some functions in the 'net' environment (such as net.get_unit_property()) produce incorrect results for some parameter values. In particular, you can't get the initiator ID without doing dostring_in gymnastics. Since the default event logs describe all unit in terms of 'initiator ID' G) Some of the lua callbacks events in scripts/net/events.lua are not reliable: * They often report teamkills when a player simply exits. * Sometimes omit the takeoff airfield name. * The damage callback never gets called. * They also forget who fired what missile, and gun kills are not recorded probably. * (feature request, sorry) would be nice to get an event when a player spawns in-air, as this is the first time an initiator ID can be obtained for in-air starts. Again, DCS probably fixed this, but the downside of DCS is that the debrief.log is not written in real-time anymore (in FC2 it is), which is a problem if your server crashes (and a log doesn't get written, which is not a problem if you have progressive logging throughout a mission). H) BTR and BMP are completely lethal. BMPs may have laser ranging systems but the BTR is manually aimed. The radar-aimed Shilka is a total pussy in comparison. This probably needs to be addressed. I) When units cannot reach a waypoint due to their large turning radius they will orbit and behave unrealistically. Manifestations of this are: * AI tankers creating vapour trail 'donuts' in the sky as they attempt to get to a waypoint but can't * aircraft carriers circling as they attempt to get to a waypoint. Have to learn to land on a circling deck. * AI aircraft turning at last waypoint to approach, turning to wide so missing the approach, aborting the approach and climbing out to try again, but this continues again and again until they run out of gas. The workaround is to introduce gentle turns by making a lot of additional waypoints, but it would be better to have the AI able to handle this case. J) Mission editor often will not save settings properly in all cases. If you change a mission option and then re-load the mission it sometimes doesn't get saved. Also applies to DCS editors. K) AI aircraft seem to be able to see you through clouds. Would be nice if they lost sight.

Well, from the Lua we can see it seems that LockOn and DCS are well built using 'physical' units and principles. That was a good early design to take all those years ago (contrast some software companies that will do any hack to get a few percent speed improvement).

wess24m, as GGTharos said, ED are well aware of the issues and some of the ED team fly on last *weekend's* massive multiplayer Fly-In to see first hand the problems we were experiencing. While we had some flying with us already it was clear that within a very short time of us logging the first problems there were some ED guys coming in to see - that is, dropping other stuff and working on their *weekend* to help. Yeah, while we all get frustrated with the CTDs (eg. we all complain sometime, including me, and hope for reduced defects in the future) I have to say I was impressed by the team's commitment to sort it out. I've said this elsewhere but I'll say repeat it again here. The first massive multiplayer Fly-In had numerous server crashes. We gave the logs to ED and they did such a great fix-job that we only had very few server crashes during the second Fly-In event (two servers, 48 hours, with 50-60 players between the servers). It would nice for it to be a perfect record but it was a vast and welcome improvement. From the second Fly-In we obtained a lot of information about client-side issues - which appear at first blush to be mostly related to the large amount of new features (the old features/code seemed mostly ok). Again we've tried to supply useful information, and some of the ED team were present to get their own logs as well. So they are not only aware of the issues, they were very active in trying to monitor and diagnose them early. I fully expect additional patches to address these issues and will make the third Fly-In even better (as well as fixing routine single- and multi-player play). Hope that sheds some light on recent CTD work (as seen from 'outside the tent' on the community side). ED are making progress (although sometimes it appears Sisyphean).

Of course I'm not an expert grandsurf but I just noticed that with the latest patch is starting to rationalize the files already, a very pleasant surprise. Please have a look at the file in BlackShark 2 directory Mods/mod_plane_sample.lua Hopefully that is the start of work to remove the frustration of adding stuff (where it has to be added all over the place, and it is very easy to inadvertantly miss something).

Yes. But at some point you have finished the cockpits and vehicles and are spending money on improving the tree textures because you have artists on hand when instead you could release the artists (if they are contractors they will already have a queue of other work waiting for them to finish their current work) and get more developers or full-time testers (who test the boring nooks and crannies that volunteers don't want to touch) - or whichever resource is the critical bottleneck. This is what allows you to speed stuff up on the main effort without spending more money overall. So yes, some stuff can work in parallel but the converse is also true, some of the resources used when working in parallel (budget) could have instead be applied to the main effort to speed it up by getting more of the critical resource early. That's all I was trying to say - since I've seen it done both ways. Either way we all get cool stuff available to buy, just in a different order.

Hi Executioner. Nice to meet another professional developer on the forums. Please see my post at http://forums.eagle.ru/showpost.php?p=1329203&postcount=84 for an explanation of why I believe parallel development is unlikely to be the fastest way given a finite amount of cash - based on the information we have in public. I don't think it is an insult to point out what alternative possibilities there are - especially if you have some years of experience. I certainly try to keep an open mind on how development processes can be improved and the arguments for doing things certain ways - and have profited in the past for having done so. I know ED read these forums and I hope they also have an open mind, and receive what we're trying to say in the spirit of debate it was intended. Many years ago a concept called 'Ego less programming' was in vogue. While every developer has pride in their work (I do, you probably do, and I'm sure the ED team do to) we have to fight some aspects of this pride (ijtihad!) and own expertise on the product in question aside for a moment and listen for the merit in what someone else is trying to say. Like I said, I became a vastly better developer when I did so. This is not to say you or ED don't also do this, but to say that is it ok for other points of view to be made and actually listened to, and for things to be examined critically. Even if you disagree with my comments on resourcing at least you might agree that BMS is making great strides (visit their forums sometime) and will become a significant competitor for the mind-share (and modding talent and has kept FC/FC2 relevant for most of us) in this niche quite soon. Like I said, I conclude this given the numeric evidence I've seen in player flight hours. pax

Yeah, thanks to all Speed's work getting information out of Lua by various cunning means I hope to support stats for the A-10C and Ka-50 once more. You can see the pilot stats for multiple servers at: http://stallturn.com/104th/ Note: currently the free Java browser plugin is required, get it from http://www.java.com but I'm thinking of switching the stats back to a Google Web Toolkit app (it was originally) rather than the Java applet.

> So if I don't want any kiddies going A-10 hunting in their F-16 (blue-on-blue) or SU-27 (what the red forces would do in real life) just don't make them playable, right? True. The problem is that the game engine can't handle all the units that would be in theatre at once. So instead of having several squadrons flying about defending the Ka-50s or A-10Cs and dynamically reacting (scrambling) to the situation instead we get a few fighters on each side and a few attack aircraft. What that means is that quite often the strikers are operating without air cover (totally unrealistic, but what can one do?). So, it is a limitation of our host machines and the finite time of missions designers to create triggers for all scenarios and numbers of players makes this very hard to get right. Basically, there are usually not enough (or any) fighters to provide realistic air cover for the attackers - and in a full-blown war enemy fighters would struggle to get close to an attacker without being intercepted first (until air dominance is achieved). This makes flying an attacker quite sucky, so the general result is missions get contrived where the attack aircraft are geographically totally away from the fighters. So people avoid taking attack aircraft once fighters are about (especially once they get shot down a few times by fighters that avoid other fighters and lurk about waiting for strikers to arrive at the front after a slow 30 minute flight) :(

I know what you are saying. It is completely reasonable to ask whether the surveys are representative of the population of users or not. They are probably representative enough of the multi-player community. The bulk of the single player community doesn't even know about these forums - but those surveys are still the best estimate we have of what they are likely to want. In statistical terms there will be a frequency distribution for various aircraft. The mode of this distribution is probably a Hornet. Now the point is not that one or another aircraft is popular or not, the point is that it is likely that people would have preferred some kind of multirole/fighter aircraft to be built before all the other ED projects. Now ED have released their roadmap (a big thanks there, we know that FC2 will live on as FC3) the decisions about what to build when have been made. What I'm trying to do is not complain about the decisions that have already been made, but to say that maximum effort should be made to get the next main jet project out the door. Significant slippage would not be good.

I'm sure ED has a good reason that we are unaware of. What we are aware of is that everyone is hankering for a DCS-quality multirole aircraft. We have been waiting quite a while now. If this sounds petulant then it is not meant to. It is meant to put attention on what people have actually been asking for. We see every diversion and delay and are always pleased with what ED delivers, and support it with our wallets and voices on this forum. However this is missing the point. Most of the ED customers see all these neat things coming out but also wish ED would have chosen a laser-like focus on the thing we asked for (and have tried to make as clear as we can). We (the community) are a many-headed hydra for sure but anyone who has been paying attention of the surveys has seen a clear 2/3 majority asking for a Hornet on both the ED and 104th surveys (both of which had a lot of votes, so could be seen as reasonably representative of the online community). So all these cool things (A-10C, P-51, FC3) are indeed great, but not what we have been clamoring for since the DCS concept was first released. We have been trying to get this through to ED for the longest time but keep getting told, "ED knows best". Actually, the community knows best what it wants and has tried to make that clear. Basically, we're trying to say ED are building cool things but in the wrong order from the majority point of view. Resources: There has been debate about resources and whether or not working in parallel causes delays. * The naiive view is for finite resources working in parallel diverts effort from the main project (schwerpunkt, for those blitzkrieg fans) and causes delays. * The more nuanced view is that resources are not interchangeable and an art team cannot replace a development team so parallel work can be done, and may be more efficient since one team does not cause a bottleneck for another. * The business view is that the principal resource is money. With money you can get more of any other resource you need and even expand or compress delivery time depending on the acceptable cash burn rate. If you are finding that you are struggling with the number of bugs you deliver or the product is more difficult to complete than expected then get more developers and go easy on the contracts for the artists. Similarly you can ease back on new features and introduce new models if you need to. The point here is that given the fact that cashflows are finite and usually mostly-fixed for a project you can alter the structure of any team to deliver earlier if you really want. In this case, working in parallel diverts cash from the main project that could have been used to hire more developers and quality assurance folk - delivering the main project earlier and with better quality. When seen in this light the parallel work and delay in producing a modern Western multirole aircraft might actually be a strategic (although recoverable) business mistake (IMHO). Falcon 4 BMS is starting to deliver quality aircraft the community want (F-16 and upcoming F-18 ) and is improving at a rate at least as fast as DCS is improving (although the strengths are in different areas). On the FC2 servers I monitor (and compile flight statistics for) and through various forums I've concluded that a lot of regulars have switched focus to BMS and only dabble in A-10C (which is a shame, but that's what the numbers are saying to me). Once BMS gets momentum it will limit the ultimate growth of the DCS series, since BMS is free it will divert community effort (modders) and players/servers. Once the horse has bolted (not quite yet) and BMS becomes entrenched this will be hard to compete with (although ED has the advantage that because it charges for its products it has many more resources at the moment).

I found some of the stock payloads had be deselected in the Mission Editor (eg AFAC) in the switch from 1.1.0.9 to 1.1.1.0 and any custom mission payload needed to be re-assigned. I did this for the second day of the Fly-In thinking it might have been a cause of the problems. It seemed to reduce but not eliminate the CTDs (although the logged message was the same, so the same bug was not eliminated by doing this). You probably should go through and re-save all the payloads (especially as the most common ACCESS_VIOLATION clients encounter is in Weapons.dll - although I'm suspicious that may be related to the new CBU code, especially the 105). So it is worthwhile checking the payloads on your own missions. Hope that helps those hosting.

After the first Fly-In we (104th Sqn) collected a lot of data and gave that to ED. This enabled them (ED) to address a multitude of issues with the code when running in server-mode. They did a great job and now the server hardly crashes (only one server-side DCS crash on both servers over the 48 hours). In last weekend's fly-in the server stayed up and it was the clients that were crashing. This may be noticeable now because previously the server was more unstable and it would crash before the client ('masking' the defects in the client code). However, most of the client-side bugs seem to be new due to the large amount of new code added in the last upgrade/update. This is normal for development to have teething troubles with a lot of new code. We hope to give ED more data from this Fly-In which will help sorting the client-side out (although there are currently bigger defects at the moment, such as the non-connectivity of the Master server for multiplayer authentication and server browser functions). There was suspicion that a particular mission was simply too big (Operation Rampant Bear - disclaimer: I wrote it). However I was admin for both servers (104th & stallturn) for most of both days and the servers were actually relatively lightly loaded in both CPU and RAM (video RAM was not a factor, they were displaying the maps and not 3D). So I don't believe that mission was a cause of the problem, it just exposed the issue more than some other missions. There is is a very important distinction here, and I don't aim to defend the mission I wrote, just point out that more missions of that size should be used for regular testing - or the multiplayer bugs will slip past testing. The Operation Rampant Bear mission also used to run perfectly on patch v1.1.0.9 so to think assigning 'blame' that (or any) mission as the cause of the crashes would be misleading - and not helpful for resolving the actual issue (which is logged as an ACCESS_VIOLATION, which means a memory allocation failure, bad/dangling pointer in the code or bad array/hash index). It is important to note that other missions also caused the same client-side crashes (and, again, did not pull the server down) although with a slightly lower frequency since they had a lot less going on and therefore triggered the same bugs more slowly. Plus, as a professional consultant software developer I can also say that for properly written (and debugged and tested) code no client input (eg. mission data, configuration, or network packets) should crash the software. Ever. If the software runs out of resources then it should fail gracefully (eg. logging, "I'm out of memory" or "I got an unexpected value of x when doing y and can't continue" instead of just falling over). Using modern development practices such as Design by Contract, Defensive Programming, Test-Driven Development and Continuous Integeration (some of the more lightweight and worthwhile practices out there) would go a long way to improving the software quality. I have applied these myself to critical infrastructure real-time systems to produce robust systems so I know they would work within the runtime constraints of a game/simulation. Anyway I'd like to thank everyone for their patience during the Fly-In. We were doing our best to give you a good experience (although, sadly, I don't have access to fix bad pointers in the game code, as I have nearly two decades of experience doing such things in C++) and I decided to take the gamble of accepting the 1.1.1.0 version without testing it for more than a few hours (although given the timing of the release that is all I had, but was glad to have the patch in time for the event). In this case I weighed up the upgrade as so worthwhile with lovely graphics enhancements, working CBUs, and helo integration for rotorheads as a worthwhile risk. I guess I may have gambled a bit too much for some. The four things you ought to take away from this post is that: 1) The issues you experienced were not due to you or your own set-up. 2) The ED team were excellent after the last Fly-In in resolving the server-side bugs. There is every chance that as a result of this Fly-In ED will also address the client-side bugs experienced by the community. 3) Your participation in such events helps find issues in the game that are only seen with a large number of players, a very worthwhile contribution to make. 4) As a result, the next Fly-In is likely to be a significantly better (more stable) experience than the first two. Thanks to all of those who participated in the Fly-In, I hope the event on this scale (50-60 players at times) was something unique and enjoyable.

No in this instance with the server browser model used by ED (depending on a centralized server rather than a caching peer-to-peer system). Some of this may be due to the desire of using a central server for multiplayer authentication and authorization but actually that is a different concern and there is no real design need to build it this way, but that is how it is at the moment. Everyone is experiencing this problem at the moment. Just another one of the bugs in the latest releases that aren't seen on the small scale of individual developer and tester machines but are seen on the scale of large loads.

Patch 1.1.0.10 Thanks to ED and testers getting the patch out in time this Fly-In will include both A-10C and Ka-50. See you there!

Great stuff ED and testers - and thanks for getting it out on schedule (well, the public one at least). This means this weekend's massive DCS multiplayer can use both Hogs and Sharks!

Monnie, great to have another A-10C server about. In my experience running the stallturn server where clients are connecting at 256/128 kB/s (as they should be) then you will get 8 players per 1 MB/s up. This means your current connectivity should have good connections for around 32 players. When lightly loaded your server is likely to use 1-2 GB/day (60 GB/month). If your server is very popular then you can expect a multiple of that (100-200 GB/month, as Sleem pointed out). Hope that helps your planning.

The Vipers are going to be refurbished, but are really starting to show their age. Check out the following article for a summary of this: http://www.strategypage.com/htmw/htmurph/articles/20111108.aspx