Jump to content

kazereal

Members
  • Posts

    671
  • Joined

  • Last visited

Everything posted by kazereal

  1. 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.
  2. 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.
  3. 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.
  4. Thanks for info! I have been anticipating for this to happen :)
  5. Pretty good list of further reading: https://en.wikipedia.org/wiki/Vehicle_dynamics
  6. 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
  7. 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..
  8. Great news! :thumbup:
  9. Really getting excited about this! :thumbup:
  10. 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.
  11. 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.
  12. 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..
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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?).
  20. 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).
  21. 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 :)
  22. 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.
  23. Thanks, maybe not at this moment yet but later when progressing to coding other systems.
  24. 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.. 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.. 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.
×
×
  • Create New...