kazereal
-
Posts
671 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by kazereal
-
-
2018-08-16 03:33:16.748 INFO EDCORE: DABF10C3 0099E6F0 0000:00000000 C:\Windows\SYSTEM32\VCRUNTIME140.dll strchr()+33
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.
-
Doing that would actually be a rather bad idea because of the comparatively low bandwidth of the connection between RAM and GPU. To render a frame you need to work on big amounts of data to generate even more data and ultimately that data needs to end up on the graphics card anyway. Offloading things to the CPU would most likely cost you huge amounts of performance while the GPU waits for stuff from RAM to be loaded. More cores is mostly beneficial if your CPU isn't able to fully saturate the GPU (and the application properly uses a modern graphics API) or if you're doing lots of stuff that is not well suited to be run on the GPU on the side.
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.
-
Base programming and testing should be finished next month. We'll then work on transferring our shaders to the new API. This is a very new technology for us, and it is quite possible that we will run into unforeseen issues during that phase. DCS World uses many complicated shaders that may not necessarily play nice with the Vulkan API.
Thanks!
Thanks for info! I have been anticipating for this to happen :)
-
Pretty good list of further reading:
-
~3 years of experience and accumulated anecdotal evidence seems to suggest that it's pretty close, but I'd like to know what someone with good physics/math knowledge has to say. Mainly I'm interested in kinematic ranging through either altitude or speed, but anything else is cool too.
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:
-
Sure. It is probably possible from a technical point of view. If you have an array of REALLY large SSD's that is...
The Caucasus map is approx 500 km2 in size and NTTR approx 600 km2. Together with the currently available modules that requires roughly 60GB of SSD storage space. The surface of the world is approx 500 million km2 so do the math...
On a more serious note, FSX, P3D, XP10 and all the flight sims using the entire world as a playground work very differently than DCS.
1. The scenario is built around landclass and terrain mesh and if you want it to look good you will have to add high-res textures which also would require an insane amount of storage space if you did it for the entire world.
2. In those sims the only interaction with the ground is during takeoffs and landings. In DCS you are supposed to fight in a combat environment. Find ground units hiding etc. That requires a highly detailed scenery.
3. In DCS you need working roads and bridges etc. In the sims you mention that is purely cosmetic and made to look good flying at a bit of altitude. In DCS it should look good at ground level as well. And collision detection is required to work with ground objects in DCS which isn't the case on FSX and other sims.
So a combat flight sim can't really be compared to FSX, XP10 or P3D. But I agree, it would be awesome to fly around the world in a DCS level aircraft and in DCS level scenery. But I'm afraid that it isn't quite possible any time soon.
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..
-
Great news! :thumbup:
-
Really getting excited about this! :thumbup:
-
Hi, just a little info. In NASA TP-1538, Cl Cn CY coefficients are already accounted for differential deflection of horizontal stabilizers, since they uses a simplified (fixed) control schedule of 0.25 times aileron deflection. (In GD's control law, however, it has a dynamic schedule based on Qc/Ps, which can be found in http://i.imgur.com/nLkcuTR.png.) So it may be a little tricky to decide to what degree a reduction of the original value is appropriate for aero calculation on ailerons only.
Thanks for that info.
I'll have to get back to it bit later, currently busy with another thing.
Also got info on couple of good books for CFD analysis since that has other things to consider comparing to "usual" aerodynamics.
I'm looking at more in-depth information at this point, learning more about aerodynamics and other things.
One source (free textbook):
http://web.mit.edu/lienhard/www/ahtt.html
Edit: values from windtunnel are different from experiments in real flight too, but calculations can be used to compensate some of that.
Supersonic flight changes things a lot: if subsonic flight can be considered mostly through a "solid", in supersonic flight you need to consider plenty more of the flow types involved.
-
the version I have is a few months old but I dont have that Issue.
is this a new issue?
Well, there has been plenty of changes..
Anyway, looks like bug was in throttle input handling where there's new and old code in progress.
Fixing that seems to have fixed the problem I was seeing too.
So, disregard previous post..
Edit: seems like problem is not entirely gone yet, sometimes you "fall out of sky" or "explode on runway" when spawning to aircraft.
Usually helps if throttle is somewhere above halfway when spawning but not all the time.
There's likely some division by zero somewhere in those situations but it seems to be harder to track down than I assumed.
In the meanwhile, you should now use "engine start" and "engine stop" shortcuts instead of just throttle: as part of tracking down a bug I made that to use explicit command now.
-
A friend noticed that mod does not work when using mission editor to place the aircraft.
It looks like AI is fighting for control of the aircraft even when set to human control (client).
Any ideas?
Looking at the problem now but low on ideas what might be causing this..
-
Very simple inertia calculation added.
Basically, when object is moving it wants to continue moving so changes in direction need to overcome that. The more speed and mass you have -> higher the force to overcome.
It should consider mass of aircraft and fuel and velocity, which is a vector (direction and magnitude). I'll need to double-check the way to integrate with DCS and that calculations match etc.
But should be another step in looong way.
-
It is in the usual place for download:
https://github.com/ipr/F-16Demo/
Download that as-is to DCS mods/aircraft/ and should have it working with no extra steps needed.
Note that there are bugs and things that are in progress of being fixed, can't say timetable..
You can get older version(s) from the version control too if there's a reason to.
-
Time for a short update..
I'm looking at implementing aircraft skin friction effect to the flight model.
That would need either friction coefficient (Cf) at various parts in the surface, or Reynolds number (Re): Cf = Re*M*a (where M is mach number and a alpha).
There seems to be way to calculate Reynolds number for various parts of surface according to airfoil shape, but that seems quite complicated and I'm not sure I can do that. For one reason, I don't have that detailed measurements of the aircraft body and airfoil shape.
So good sources of reliable public information is welcome as usual.
Edit: never mind, I think I've figure out (most of) the equations needed..
I'll be adding some code to test soon.
-
Guys this is really amazing...but I have to ask...what's it good for? Since nobody will confirm or deny a Falcon in the works and from what I've gotten from others, the only falcon currently in the wild is a private build for the virtual thunderbirds...what's the purpose of this.
As said before a couple of times:
1) demonstration of how to implement external flight model in DCS
2) to learn how to make simulations
So the "demonstrator" part has been there quite some time, personally I'm interested in the second part now.
If it is useful for someone else too, all the better.
There is also: 3) share ideas and information, but that is not too large part.
One thing is that this is based on public information and so there is no problem in sharing the source code or the implementation.
Edit: as such, this is more oriented towards people who are interested in making a simulation module of some kind
Edit2: if you do enjoy flying some other mod more, go ahead. Approach might be different, results may vary and so on.
I am mostly trying to keep with A model information, that is actually easier to find and less guess-work about certain things.
If the more modern/advanced models are more interesting then some other mod might be more suitable.
-
For what is worth, thank you for all your hard work
Thanks :)
There's still a lot to do and I'm waiting for a couple of books to arrive learn more about stuff that is waiting.
-
Center of lift is now calculated as function of mach number.
Unlike traditional aircraft designs, F-16 has "relaxed static stability" which mean center of lift is a bit forward from aircraft reference center. Also the lift position moves backward as speed increases. This gives better agility but has downsides as more complexity in flight control system.
Reference point is 0.35 percent from mean chord length and actual position can change from 0.30 to 0.39 (0.35 at mach 1).
The change in lift position must be counteracted by trimming or by flight control system automatically (working on changes there still..)
Try it out. Other changes still in progress as mentioned before..
Edit: old code had a constant difference there which was for low speeds (max. front) and did not change it for higher speeds.
-
1
-
-
Simple oxygen pressure added so pilot stays alive in high altitudes.
No big changes now, looking at documents and planning for next set of changes.
I was testing some flight conditions, cases where it is near stall and close to losing control can be managed by use of airbrakes and flaps (with the alternate flaps switch). The documents mention this to be helpful so I thought of checking that.
Interesting to see what it will be like when planned changes to code are complete..
Edit: fixed a bug in LEF handling on takeoff, should give smooth transition from takeoff position now. 3D model animation does not handle -2(deg) upwards angle for both sides so that is a known thing..
Also found a forum post saying that TEF come down below some speed even if wheels are up.
Need to find another source to verify that and more details about speed and if there's other conditions (is it really automatic or just manual with the alternate flaps switch?).
-
Some changes to leading edge flaps schedule (and more to do).
Should handle cases where they are locked in place (not in automatic mode), weight on wheels, transonic speed adjustment (needs improvement still).
-
Actually, I found that the aircraft rolling speeds are dead on with the real aircraft without adding differential elevon affects. There is no PID in the roll axis, so you won't get any instability by adding additional rolling power, but I don't think it is really necessary. I'm thinking the NASA data just accounted for the affect in the aileron rolling moments, but did so with the current flaperon to elevon ratio at the subsonic speed they chose. Anyway, the thing already has such a quick roll rate acceleration and deceleration that it almost always looks horrible over multiplayer. When viewing the aircraft from external view (not over multiplayer), it looks very crisp like the real thing.
I don't know about roll rate, that might be accounted for in the data already like you said.
I'm thinking mainly of things like near-stall or other rare cases where it might make a difference. I don't know how much of effect that might be in things like recovering from some situations. But we'll see..
There's part of the changes uploaded now, of course I'll need to revisit the changes and recheck everything afterwards but it is in progress.
Anyway, good to know that it compares well so there's way to check effects :)
-
Yes, the NASA aerodynamic data does not account for differential elevon in the rolling moments, so I also don't have that affect in my model. However, I do visually animate the elevon mixing and do use their differential positions for affecting pitching moments and drag.
Either way, that is something that needs to be handled at some point to make it fly correctly..
I'm not at that point yet but I'm reading more about it when I have a chance.
Before then I'm making other changes in splitting fcs command logic from actuator code and aero code so the mixer (blending) of commands can be easier to add.
Likely changes to aero code need changes into equations of motion too since they are no longer symmetric effects around center of gravity. I'll need to look into that too at some point.
-
This is what I got on the flaperons subsystem, I don't know if the information is useful at all.
Thanks, maybe not at this moment yet but later when progressing to coding other systems.
-
Yes, it is. I used a combination of FLCS diagrams, operators manual descriptions, photos, videos, and some educated guesses to write the trailing edge flap logic.
No, the trailing edge flaps only change for 3 reasons.
* Gear down and speed below 370 kts.
* Alt Flaps switch activated and speed below 370 kts.
* Transonic speeds actually make flaps go up (max 2 degrees)
Technically, the digital backup mode has different logic, but you can get into that if you ever model it. (I did)
Thanks for information :)
That is what I though as well but it is better to check assumptions.
There's still plenty of ways to go so we'll see how far I'll progress..
You should also probably switch to using dynamic pressure ratio instead of knots, as the FLCS on the real aircraft does. qc_ps = qc_psf / Ps_psf; Where qc_psf is the dynamic pressure in psf, and Ps_psf is the atmospheric pressure in psf.Yep, that is in plans but like many things might have to wait a bit, there's always so much to do..
Yes, I've been looking at that pretty much lately :)
Thanks for that :)
I do like to work off from information than direct source code. Maybe slower progress but anyway..
I like the coding, learning and figuring out stuff, so without that there would be no point at all in doing this..
What this actually looks like when the flaps are down (gear down, speed at 240 kts) and a full deflection roll is initiated, is that one side's flaperon will not change and will stay fully down, while the other will go all the way back to neutral so that the difference between the flaperons is 21.5 degrees. A normal aileron command will have a difference of 43.0 degrees (21.5 deg up on one side and 21.5 deg down on the other side).
Yep, I've found that information too but haven't gotten to implementing it yet.
I've been looking at mixing flaperon and elevon (stabilizer) control for roll command: since the stabilizer can work both symmetrically (elevator) and differentially (aileron) mixing that for both flaperons and elevons can be tricky.
It is essential to have but means changes to both flight control and aerodynamics: old aero code assumes always symmetrical deflection for flaperons and elevators and does not calculate separate lift and drag for different sides of aircraft.
-
I've added better information about license meaning limitations to use:
no changes, just clearer to find the information.
Have a look and leave a comment:
https://github.com/ipr/F-16Demo/blob/master/README.md
Video of current status:
2.5.2.20601@openbeta:MP:Server Crash:C:\Windows\SYSTEM32\VCRUNTIME140.dll strchr()+33
in Game Crash
Posted
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.