EvilKipper
-
Posts
75 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by EvilKipper
-
-
You get a pop up from DCS, and I'm not sure I can detect correctly what's happening from lua when require fails. Also I kind of view this as the price you pay. If you need to reach for the big guns, then you're going to have to think about things like what lua dll you're linking to, and all sorts of other things too like is it safe to call this api function from my current threading context. It isn't something that can be entirely smoothed over, which is why we have lua.
The ps1 is 2 lines, you can just copy and paste them into your powershell if you don't want to run the script. I wrote them in a script so I didn't have to constantly do that.
-
You need to link to the same lua.dll that DCS is linking to, otherwise you will get the smoke of very bad news. You can do that by making sure that you set the correct environment variables. There is a script setup_build.ps1 for windows, and setup_build.sh for linux that you can run to accomplish this. If you are not linking to the correct dll then DCS will say it can't require your dll, and what that really means is that the dynamic linker saved you from much worse consequences because it could not find lua51.dll
As a general matter I would not recommend building native code mods for DCS unless you have a real need to do it. Fowl engine is very complex and thus benefits from strong static typing and compile time guarantees, some very specialized data structures, background threading and async for state saving, and vector optimized math libraries. Most scenarios don't need any of that and are better implemented as a couple of hundred lines of lua.
-
Currently the best example is https://github.com/estokes/bfnext, bflib is the core of fowl engine. It's sadly not a very simple example, but if you look at the Cargo.toml, and the bottom of lib.rs you can see what you need to do to build a server using dcso3.
-
you have to unsanitize your lua environment by editing Scripts/MissionScripting.lua
-
Two things to say about this.
1. Yes. Rust, C, or C++ are all better in that you have full control of the system and the full OS API available. As long as you are mindful of properly respecting API restrictions you can compute whatever you want on background threads. This is not news to anyone, people have been doing this for many years with DCS.
2. Lua is not "horrible", it is literally meant to be glue, it has an internal API that is very friendly to use from Rust, C, or C++. It is not hard at all to write a mixed application using Lua where Lua's strengths are advantageous, and Rust or C or C++ where those languages are advantageous. In fact if you study they way DCS in general is architected, you'll find this pattern over and over, lua as glue, loading various native dlls to do heavy work or complex logic.
Also, shameless plug, if you want to use rust with DCS I've written a complete binding of the lua api. The crate is called "dcso3".
-
On 9/14/2023 at 5:41 PM, Grimes said:
AFAIK they are unlimited for now. The warehouse info isn't saved in the mission file, its in the warehouse file within the miz. Thus there aren't any input parameters right now to define the warehouse functionality.
On 9/14/2023 at 12:00 PM, MarcosR said:Hi @Grimes i spawn a farp dynamically on my server.. I understand the payload can be send on creation is that the warehouse info? Or will spawned farps will always be unlimited weapons? Would be great been able to modify the stock of weapons and planes even if it’s unlimited…
It is possible to work around this. If you want to dynamically spawn a farp, you can pre create any number of empty farp pads somewhere on the map in the mission editor with their warehouses empty. Then when you know where you want your dynamic farp to be, you spawn the farp pad with the same name as one of your "template" farp pads. This will effectively move that airbase to wherever you want. You can do this multiple times with the same farp pad. If you are calling world.getAirbases, be sure to check isExist, the previous locations will be returned from world.getAirbases but isExist will be false. Airbase.getByName will always return the most recent one however.
Once you have created your "dynamic" farp you can get it's warehouse and use it normally just like any other airbase.
-
Event: 1v1
Squadron Name: REAPERS vFS
Teamspeak/Discord: EvilKipper#6211
Contact person: REAPER 32 | EvilKipper
Aircraft Selection. Mirage 2000C
Pilots: USA - REAPER 32 | EvilKipper
Event: 2v2
Squadron Name: REAPERS vFS
Teamspeak/Discord: EvilKipper#6211
Contact person: REAPER 32 | EvilKipper
Aircraft Selection. 2x Mirage 2000C
Pilots:
UK - REAPER 33 | Sting and
USA- REAPER 32 | EvilKipper
-
...
Won't be carriers for a while as you can't limit loadouts currently from a carrier but more ships incoming.
Sent from my ONEPLUS A3003 using Tapatalk
How about a DD on the lake by Tblisi :lol:
-
-
You beat me to it, LOL
-
After more testing, indeed the low speed model is terribly wrong.
With full AB 90' bank, full aft stick, I couldn't drop the speed below 163 kts.
This was with 50 % internal fuel. With 100 % fuel under the same conditions, speed drops only to 159 kts
If I perform the turn in a 20 deg. dive, the speed won't drop under 200kts!
Can you describe concretely why it is wrong? What should it do? There are several reasons I think it might not be wrong.
* The AoA is limited by the computer, meaning what you perceive is full deflection of the stick is actually changing as you move through the envelope.
* The thrust to weight clean at %50 fuel is >1, and still quite high in the clean full fuel case.
The first point is the most convincing. If the AoA was not limited, then of course you'd expect to depart eventually, given sufficient control authority. However with limited AoA, why wouldn't the forces balance out, and moreover, since the AoA limit is naturally below the AoA at which the aircraft would depart, then the speed where all the forces come into balance should naturally be above the stall speed, otherwise the AoA would be higher than the limit, and the computer would force you to turn more slowly by invisibly reducing the control surface deflection in spite of your fully deflected stick.
I'd like the thank Razbam for their hard work on this new FM, which I am enjoying immensely. Now I can do all the airshow maneuvers I've seen mirages do!
-
Thanks!
The mirage is my favorite plane in DCS, and I'm so happy the FM is being improved! Thanks for the hard work! Christmas is coming early!
-
My gut feeling is that we are not going to find anything very surprising about the mirage's engine. It's designed to be simple, reliable, and easy to maintain first, fuel efficiency and performance seem to have been lesser goals. It's quite amazing to me that Dassalt was able to build such a great fighter with such an unimpressive engine. I suspect it works basically the same as every other supersonic jet. I guess maybe due to its initially low compression ratio of 9.8:1, vs 30:1 on comparable engines, maybe it gains more efficiency from ram compression at high speeds than other engines, but I'd still expect more fuel flow at a higher Mach number (at a constant altitude).
-
Do you actually have a source for the data on fuel consumption at different speeds and altitudes? I found the below site, but I'm not sure how reliable it is, and it doesn't have data for different speeds at the same altitude.
-
At 40k fuel flow is about 132 on full burner, regardless of speed
That just seems odd, even if the engine control system is able to restrict airflow, or reduce fuel flow without risking a flame out. I'd expect some change in fuel flow at a constant altitude at m 0.8 vs m 2.2. I'd be quite surprised to learn that the actual plane exhibits no change at all in fuel flow between these vastly different speeds. If it's just not implemented yet, fine, it's early access, but if that's so here is my vote that it gets implemented properly in the final product!
-
Hi, question about the mirage. Normally at a given altitude, fuel flow will increase as mach number increases. If you think about it this makes perfect sense, the engine has to burn more fuel in order to keep the optimal air fuel mixture as more air is entering the engine. In the F-15C for example this effect is quite large. I notice that this never happens in the mirage, is it just not modeled yet, or does the real plane actually behave this way? I can imagine several ways this might happen, e.g. the intake ramps might restrict airflow, or additional air might be forced to bypass the hot section.
By the way, love the mirage, it's my favorite plane in DCS by far, thanks for all the hard work.
Scripting Usage
in Scripting Tips, Tricks & Issues
Posted
bflib does bind and use nearly all the events (see on_event). The run_timed_events and run_slow_timed_events are simply for doing mission housekeeping in the background. As for which is better for DCS, basically neither. Both of them will block the main thread for as long as they run, so they should all run as quickly as possible. bflib uses multiple strategies to make this happen,
- very long cpu intense operations that do not require calling DCS apis (e.g. saving the state, recording stats) are done on a background thread and do not ever block the main thread
- long operations that do require DCS apis (e.g. getting unit positions, synchronizing warehouses) are split into multiple chunks and are run over multiple calls to run_timed_events
How long everything takes is measured in an hdrhistogram and periodically reported in the logs. This is how I identify problems that I need to focus more development effort on.