davidp57

Same here, keeps resetting.

Thanks Suntsag, will test this ! Any chance that you'll update the Persian Gulf Marsden x5 Airfields.stm template with AM2 ?

Hi backstab, Morpheus is right but his answer is incomplete. Let me get into more details. Players have to install the skins on their machine to be able to see the other players that selected the skin for their aircraft, on the server. If a player does not have the skin, he'll simply see the aircraft with a default skin (no big problem, no crash). But in order for players (with the skin installed locally) to see the skin on other players at all times the skin has to be installed on the server. If it is not, then only the players present when the other player selected his skin in the game will see it ; players connecting afterwards will see a default skin. If that's unclear, please comment, I'll clarify.

Hi Skypat, thanks for your time and efforts. If I may, why did you choose creating your own project vs contributing to the OvGME codebase ? And (linked question) what are the differences between ModManFX64 and OvGME (apart from the cool name, of course ^^) ?

Because...

Most definitively it is.

havok2, thanks, this looks wonderful !

Did you eat your 5 fruits a day ? Do you smoke ? Joking, of course ;) Integrity Check is an (optional) feature of a DCS server that checks if you modified your game files. This can mean editing a script, modifying a texture archive, adding commands to input files, etc. It's known as _modding_

Wait, I know this guy ;)

It's a but complex, you'd have to have at least a little bit of programming experience. Building from source requires : a development environement (Visual Studio Code is excellent and free) with all the tools and libraries in place and configured (this can take an experienced dev a few hours to set up) the source code ; easy peasy, git pull and voilà a lot of patience ; it won't work, you need to figure why (here experience is key) correct the problem, rinse and repeat. A thousand times All that to get a partially working prototype. Because if it wasn't released yet, it's because it's probably not release material... Long story short : unless you want to make the project progress (and I'd love that you would), stay clear from building from source ;)

He probably compiled a version from the source.

Great news Bignewy ! Tomorrow or two more weeks :smilewink:?

Excellent ! This most useful feature allowed me to measure the way we drove yesterday during the Rallye des Ailés : 311km in the mountains, from Beslan to Kutaisi. Merci Flappie for your outstanding work ! PS : I searched a bit but couldn't find a database with the navaids in the DCS files (although I found that all the cities are listed in Mods\terrains\Caucasus\Map\towns.lua, which I used in a script of my own ^^)

Thank you Bignewy. I think we all understand. Please transmit my thanks to the dev team, who's doing an incredible job keeping our passion fueled ! Also, I'm available for further testing if it can help. I'm a long-time programmer so I know my way around a bug report ;)

Looks nice, although I can't call code im my lua scripts (that are loaded via a trigger in the mission). Is this a known limitation ?

Interesting, thank you. I'll try this and report.

@Bignewy, I've got a question : what's in this 64k limit ? Is this the menu that is sent to a single client, meaning that this menu is tailored to his group only (when using the addCommandForGroup function) or is this the whole complete menu on the server (with all the commands for all the groups) ? Of course, this changes a lot... [edit] I've made changes in my code to record the size of the text, for all the submenus and commands, for each of the groups. I'm aware that the data that is stored in this packet is not limited to the text of the menus and commands, but I needed something to start measuring. After starting the mission, the maximum size of the menu (for all the groups) was 3491 (characters, so if LUA is unicode let's say 7 Kbytes). If I play the mission a few minutes, the maximum size gets up to 3700 characters.

Do you have wake turbulence activated ? If yes, it's "normal" that you loose fps in the vicinity of a tanker, specially if there is an escort or multiple fighters coming in for refueling. Lots of wakes and long-lasting effects to compute...

Pikes, Frank, you're welcome. As you said it's been a while, we've always dealt with it but now that we use the Moose:AIRBOSS feature the menu are even bigger and the problem is getting quite difficult to work around. Btw thanks for your work on Moose, both of you !

Thanks Bignewy ! Do you thing the feature request will be accepted ? I'm trying to keep the data under 64k but it's hard, considering it's a dynamic mission ;) I'm also surprised to be the first one reporting this problem.

Hello ! I just found out that there is a link between the infamous "NET: Max message size exceeded!", "NET: Failed assert capped_sz == sz at Projects\AsyncNet\src\DsbNet\DsbServer.cpp:1122" errors and the size and complexity of the radio menu. The last thing I could find in this forum about that was a reply from C0ff where he said that it had something to do with craters. That was probably true at the time, but since a few months we've had this problem with our (quite complex and dynamic) training mission and had to find work-arounds. In our mission, the radio menu is quite deep (4 levels) and often full (9-10 lines). Sometimes (less often if we prune the menu) pilots will be missing entries in some of the menus. I made a (very simple) demo mission that I attached to this bug report. It does nothing but open a Game Master slot and create a 4 level deep menu with 9 commands for each of the deepest submenus : local function message(text) trigger.action.outText("message "..text or "[nil]", 5) end local menu = missionCommands.addSubMenu("TEST RADIO MENU") for step_one = 1,9 do local menu_step_one = missionCommands.addSubMenu("TEST STEP ONE "..step_one, menu) for step_two = 1,9 do local menu_step_two = missionCommands.addSubMenu("TEST STEP TWO "..step_two, menu_step_one) for step_three = 1,9 do local menu_step_three = missionCommands.addSubMenu("TEST STEP THREE "..step_three, menu_step_two) for step_four = 1,9 do local menu_step_four = missionCommands.addSubMenu("TEST STEP FOUR "..step_four, menu_step_three) for commands = 1,9 do missionCommands.addCommand("TEST COMMAND ", menu_step_four, message, string.format("%d/%d/%d/%d/%d", step_one, step_two, step_three, step_four, commands)) end end end end end If you put this mission on a server (dedicated server on my side), connect to the server as a client and check the server log, you'll find these errors : 2020-04-27 08:31:16.700 INFO NET: client[2] is ready to start 2020-04-27 08:31:16.701 INFO NET: spawning client[2] 2020-04-27 08:31:16.874 WARNING NET: Max message size exceeded! 2020-04-27 08:31:16.874 ERROR NET: Failed assert `capped_sz == sz` at Projects\AsyncNet\src\DsbNet\DsbServer.cpp:1122 2020-04-27 08:31:16.874 ERROR NET: Message 34433 was truncated from 170958 bytes 2020-04-27 08:31:16.877 INFO NET: client[2] started 2020-04-27 08:31:47.308 INFO NET: remove: client 2 Could the team please have a look at this problem, it's becoming increasingly difficult to work around. Thanks ! Kind regards, Zip. testRadioMenu.miz

From what I infer (reading the code of some advanced weather scripts), there is a direct link between the wind gust speed in real life and the DCS ground turbulence value.

Hi there, I was trying to tune my helicopter's collective axis (mapped to my Warthog throttle's Z axis) so that 1/ it works as in a real helicopter (full aft = zero) and 2/ the full aft position corresponds to my throttle's afterburner detent (roughly 70% of the course). Doing this, I noticed a few inconsistencies that I'd like to report, for the community to decide if these are bugs or if simply I haven't used the options as I should have. TL;DR: I think there is a bug when combining the "Invert" and "Slider" checkboxes. First, the configuration that I had set up, regardless of my afterburner detent, and which works well. "Invert" checkbox ON "Slider" checkbox ON "Slider" is supposed to work in this way : if OFF, the axis values are considered centered around 0 (i.e. from -100 to +100, with 0 being at the middle of the physical axis course); if ON, the axis values will go from 0 to 100 (with 0 the start of the physical axis course, and 100 the end). According to the documentation, "Invert" simply reverses (mirrors) the axis values around. Now, the behavior of the curvature options. With "Slider" OFF, all the curvature options apply as mirrored around the center. With this ON, they apply linearily. Here are some pictures ; according to the documentation, the red point are the raw (physical) axis positions, and the black square is the actual axis position (computed, the one transmitted to the flight model). "Slider" OFF : "Slider" ON : This is correct imho. With "Invert" ON, the actual output value (the square in the graph) moves relatively to the inverse of the raw value (the red dot in the graph). Again, this seems correct imho. I did set a 70% "Saturation X" value to try and keep the actual value at 0 when the raw is greater than 70% (i.e. my throttle is beyond the afterburner detent) Again, this seems correct imho. At least on the graph... When going back in the game, the behavior is not at all the one shown on the graph. I cannot show this with screenshots, but it seems that the collective axis in the game behaves this way : from 100% raw axis to 30%, actual collective axis moves from 0% to 100% from 30% raw axis to 0%, actual collective stays at 100% This is where I think there is a bug when combining the "Invert" and "Slider" checkboxes. @Bignewy, what do you think about that ?

Great news Mirabelle ! Passe lui le bonjour de la part de la VEAF qui pense bien à lui ! Cheers, Zip.

Servers have run for decades before they introduced this relatively new feature. Their owner and their players never complained about it being "unrealistic". I think that realism is really what I'm after; but I like to do some concessions to the fact that : we're not real pilots - labels in the cockpit are not that outrageous we're not in the real workd - I fly with dot-labels over aircrafts that are 10-4 nm away, because I can't see one tiny pixel on my screen, where a real pilot can see a plane at 10nm we're playing a game - I use the external views, including the F6 view because it's fun we're playing a very badly optimised game - VR players, players with a small budget, do not have the processing power needed for shadows, turbulence, you-name-it we're playing a very buggy program - I have multiple mods that are there only to correct long-standing bugs in DCS ; this stops me from joining IC-enforcing servers (I don't complain) Long story short, I don't like being forced to do something in a game. Love, Zip.