kazereal

This looks more like buffer was not allocated after LAU_127 model was not found and feeding NULL-pointer to strchr() - might be same in both cases actually, depends on how things are implemented in lower-level.

This looks like there is lookup trying to find a character in the string and not having terminated the string correctly (null-character). According to call stack it is from Lua-scripting so it might be the script-file or Lua-runtime itself somehow contributing to this (bug might be in the Lua script parser actually). C++ style string-class usually knows to stop looking after end of string so that would be less prone to this problem, older C-style functions don't have input for maximum string size and this can happen when string isn't null-terminated for whatever reason.

I agree with you: if CPU isn't doing things fast enough you essentially stall the GPU (make it wait for CPU to give more tasks). PlayStation 4 uses different bus-architecture than PC called HSA-architecture: that essentially allows GPU and CPU share same data without copying between memories. If you had that on PC it could improve efficiency. Often GPU is more efficient in highly parallel tasks and offloading things from CPU to GPU makes more sense. There are other tasks that don't scale well on GPU and are better to be done on CPU threads: network code is one example of such. So offloading things GPU and threading the rest of CPU would be most useful approach. And simulation code does have plenty of things that can benefit from parallelism if it is done so that it can benefit from parallelism: this means data structures need to work well with this design.

Thanks for info! I have been anticipating for this to happen :)

Pretty good list of further reading: https://en.wikipedia.org/wiki/Vehicle_dynamics

Depends what you really mean by that. If you are asking about inertia and kinetic energy then that is part of the flight model/physics calculation and different aircraft may be using different flight model. For example, some use AFM, some use PFM and so on so level of implementation might be different. There is no one single answer to this. The ones that use PFM do simulate things to high degree though. SFM not so much. Kinetic energy calculations are the very basics of vehicle motion simulation so they do need to be calculated in some level. Amount of things causing drag and reduction of kinetic might have differences (for example, aircraft skin drag). Basics of what I am talking about found in every vehicle simulation is energy and loss of it. See wikipedia: https://en.wikipedia.org/wiki/Kinetic_energy

Adding to that: "plain" flight sims (no sea/ground units) also use procedural generation of things. This means things like towns and roads are generated by some template/algorithm combination. Towns might be roughly around the location where expected but nothing like the actual town. The addons for a single airfield in those can cost nearly as much as whole terrain module for DCS.. 70% of earth surface area is water, so that leaves ~149 million square kilometers of land, but that is still plenty.. Also Nevada map is not 600km2, it is 129600km2 (360*360) So.. 60 terabytes of data to download..

Really getting excited about this! :thumbup:

First one does not yet fire, just prepares guns for firing. Second command will actually fire guns. It makes more sense with a stick that has two "switches" in the trigger (like TM Warthog). In some WW2-aircraft you might have had machine guns and cannon to be used separately in slightly similar way. Edit: sorry, thought you were asking about F-5.. Can't remember what the first detend on F-86 does.

Getting stuck on grass, mud, sand etc. is not about friction. It is about uneven terrain and tyres sinking into unpaved ground (a lot of weight on small surface area of soft ground). The question is more about how terrain is modelled instead of tyre friction in those cases. Friction is actually *lower* in unprepared runways: grass and mud are slippery, sand acts like small ball-bearings changing static/glide frictions into rolling friction and so on. When tyre is sinking it is not about friction but closer comparison would be about soft-body collision with increasing resistance the more material there is in front (the deeper the tyre goes).

This should have everything you need: http://forums.eagle.ru/showthread.php?t=95985

Anyway, this tech demo might have some useful ideas: http://forums.eagle.ru/showthread.php?t=95985

Without ASM code, you'll might need to return values to DCS from FM like this: https://github.com/ipr/F-16Demo/blob/master/FlightModel/F_16Demo.cpp#L834 Likely some way to do those in lua too but I could never figure out those properly.

Have you tried 38 ? I can't remember exactly now, been a while since touching that code. https://github.com/ipr/F-16Demo/blob/master/FlightModel/F_16Demo.cpp#L780

Computer software will always have more or less glitches. Just learn to ignore it, that is very small glitch.

Or that work required would be enormous for a minor visual glitch. Or that it needs work that would be obsolete at one point. Or there are more immediate concerns to solve for any reason. There are numerous reasons why a bug is not reacted to, often simply it is about prioritizing developer time. Just because you have it as a pet does not mean everyone cares about it same way, end-users don't see the ton of things happening "behind the scenes", so to speak.

Early access usually means stuff like that is not ready and therefore not available, it being early and so forth, you know.. :music_whistling:

Except ED usually calls those "pre-sell" to add to the confusion.. Either way, I'll wait the usual friday evening news and update to see what it really will be..

That kind of speculation has many (implausible) ifs and buts in there about revenue, purchasing habits and so on and so on. Much simpler explanation is that it isn't ready yet. Usually the simple explanation is the correct one (at least according to Occam's razor..)

Monitor refresh rate does not matter: it is separate thing from rendering performance. Looking at direction X has some amount of objects and polygons to render, looking at direction Y might have more to render requiring more rendering time -> lower framerate. On something as complex as Nevada (or Vegas, actually) the variations in required rendering performance can be huge depending on location (height) and direction you are looking at. Modern games can do "port-hole" (portal) optimization where you are certain you will never see more than specified amount of geometry. These are database-driven optimizations where you are limited by design what you can see. In a true simulation like DCS you can hop in a helo, move to any position and look at any distance and orientation in any kind of weather and lighting: similar geometry reduction beforehand simply does not work same way. In addition to having level-of-detail objects (reduced complexity objects) in a far distance, games can render far objects in lower resolution which are then combined with higher resolution renders near the player viewpoint. Comparing to games is not appropriate.

C-101 does have second seat as well.

A and C are pilot-only, B and D are dual-seat trainers.

There hasn't been much competition in that market for a long time. Enthusiast-level devices like MFG Crosswind and Slaw device have higher price point and are not sold on every consumer store. So Saitek and CH have been about the only options in the lower-cost market for a long time. If there's no competition quality is poor and price as high as manufacturer will set it..

Sounds interesting, there's definitely room for more alternatives in the market (in my opinion).

Twice the amount of work: twice the people working on it four (!) times as much bugs. Even more when you need to synchronize some functionality between them: when you change one part you always need to verify anything interacting with it does not break. Amount of bugs increases exponentially with amount of code, not linearly.. And it would not really give any benefits at all: better approach is to give different parameters/data to render at different quality than change the code at all. It would be utterly stupid to repeat essentially same rendering code and same algorithms just to have different quality levels.