ChaosRifle

Issue still present after latest patch. Namely, event world.event.S_EVNT_DEAD is still returning units that do not exist. My guess is its due to them being a different model, and thus probably different Id, but it is still making that event basically useless unless. if event.id == world.event.S_EVENT_DEAD then -- Event = { -- id = 8, -- time = Time, -- initiator = Object, -- } local playerName = Unit.getPlayerName(event.initiator) in the snippit of code, unit.getPlayerName should return nil if ai, or a player if a player. it crashes the code saying unit doesnt exist, still. was not the case before 2.9.6. Same for any other Unit class functions run on this.

sure isn't, but to be good data on how the community feels about unofficial modules we can't just remove options we don't like. Let me be clear, I was a modder for DCS before I even owned my first module, I am very pro-mods - but the data should still represent a possibly large portion of players if the intent is community representation and not just popularity contest. we all know 2.9.6 broke a ton of critical systems, it needs fixing. (heck even events don't work right, in several different ways)

because it has a radar for ranging. your RWR might not understand the frequencies being used and may think the ranging is a spike, when its just range info the radar is getting, but its used to check if you are in engagement range. some RWR may detect it, some may not. Not sure if this case is a bug, but it absolutely has a ranging radar.

should have had 'none' as an option too then.

They also need to fix the patio, as ai from there do the exact same thing. secondly, they need to fix the detection of live units as well, as its not always working. I have definitely been run over by AI on the boat, several times. Currently, the spawn system is not recognizing any statics, for players or ai. people are spawning inside statics on the patio, the corral, and the elevators. This is meaning the only place we can decorate on the carrier safely is the junkyard, and everything else is busted in some way be it for AI, or players. (usually AI). Hopefully the flight directors update will fix AI vision of statics, as well as spawn-slots respecting statics in their way.

latest hotfix at time of writing has fixed a few, in some cases, but not all, of these instances. Namely, event exit unit is still giving a bad unit object. (dynamic spawn unit, untested if slot units still break too)

correct. I have the popups disabled on mine and tend to just look at the log file, but yes.

Issue: SlotID does not allow us to get a Unit Object back due to a lack of any function I know of existing for it. Previously, this was not a huge issue because the user could create a hashmap of all known client or player skill aircraft - however with dynamic slots now, this is not possible to pre-bake a hashmap on mission start, and must be done every single time to get the single dynamicspawn that just appeared.. This is very bad performance (and just bad code in general), but not doing so results in being unable to slotblock for individual users if dynamic spawns are enabled on a server. Reason its useful: one valid reason for wanting to slot-block specific users for a dynamic spawn would be a lives system and running out of lives for the playername in question but airframes still existing for other players. Solution: Hooks for onPlayerChangeSlot and onPlayerTryChangeSlot should return a unit object in addition to slotid (as not to break any existing code, retaining backwards compatibility for normal slot actions) Current possible workarounds: 1: using event birth - Issue would be crashing a players client by unloading them during their load in. Very bad for stability. 2: using event enginestart/takeoff - Issue is wasting players time starting before being kicked back to slot menu due to not meeting requirements. 3: disable dynamic slots for any aircraft you would ever slotblock for (most). - issue is dynamic spawns cant be leveraged then. 4: regernerate a hashmap of unit objects and unitID's every time a player tries to slot in to get the object to run our code. - issue is bad performance, and unclear if this would even work with dynamic slots as its unlcear if the object even exists yet at the time of hook tryChangeSlot.

events are returning objects that don't exist, either because they are cleaned up or just broken returns. They should be returning data on the object in question, or, at least returning nil (though that would defeat the point of the events) if an object does not exist. instead, it crashes the script entirely. IE: Event.id = 1 returns event.weapon, which if you use event.weapon:getTarget() you are given a unit object that often does not exist - the object appears valid in a logging function, but if you use Unit.getTypeName(event.weapon:getTarget()) or any other Unit.getdata() function on the unit object, it errors out saying "Unit doesn't exist". similarly, event.id = 30 returns event.initiator, where you can log the data and see a seemingly normal unit object. however, again, if we use Unit.getPlayerName(event.initiator) (yes nonplayers return nil, i know, this is an error, not nil.) or Unit.getTypeName(event.initiator) it errors the script, again with "Unit doesn't exist". This happens with all Unit class functions operated on the returned event.initiator. similarly, event.id = 8 returns event.initiator, just like event.id = 30, doing any Unit class functions is totally broken. Error is "Unit doesn't exist" if you try to use them on it. I also believe (its been a few days of trying various things, so I am only 99% sure here) that event.id = 21 also has this issue. The initiator passed will not be able to be operated on with Unit class functions. Again, error is "Unit doesn't exist" All of these issues started with 2.9.6, and worked fine before. My theory right now is it is passing wrong data, or the backend of DCS is cleaning things up and removing them before our event callbacks run, resulting in code not working.

Disable the launcher in the menu options, and launch it like normal (as we have before). it will work as before.

port and bow semaphore work fine, but the aft mounted ones do not work at all, on any boats tested. (72, 74) tested on MP server

neutrals are not allies, nor enemy, and should not be shown as allies. The only alternative option is to disable the map from showing units entirely, or enable fog of war.

I think this is all aircraft? For sure hornets, i want to say one guy had a tomcat do it too. I was having this issue the other night doing some trap practice with friends and we found that the 2.9.6 new spawn slot locations for players(using dynamic slots, previously ai only) are quite happy to throw people inside of carrier decorations that previously were 100% safe due to not allowing players to spawn there at all.

I had this happen on my very small Sinai server mission last night (2.9.6). Its basically only got some carriers, a carrier group(the one it got stuck on), some tankers and a few dynamic spawns. no track to share (i run with them disabled), but I can +1 that this is an issue.

for some reason mine was the same, the mouse input mode defaulted to LAlt+C is actually on double middle mouse button (no, ive never bound MMB for anything, and not rebound/unbound anythings default LAlt+C no clue why.

AFAIK not possible.. you can however place them under a neutral team and use a script to despawn and respawn them on the spot under a different coalition. This has issues with waypoints however without some extensive work, because you cant detect what waypoint is currently active before the switch. Done right, on waypoint0 (or with some very extensive work guessing based on all positions and where the unit is relative to them) you can get a very convincing effect.

As for the government accountability office numbers on the F-18C, assuming the numbers published are in fact correct - they state their test conditions as 2x aim9, 2x amraam, and no bags. they do not mention pylons.. @nikoel's EM chart shows a clean F-18 with presumably no stores, weighing in at only 14176kg. A hornet, as tested by the claimed accountability numbers, actually weighs at least 15022.98kg without pylons, and with all pylons, would be 15648.94kg... thats ~847kg - ~1473kg... You are saying that the numbers should match for a jet that is 850-1500kg heavier than your data from DCS. The lighter jet SHOULD be better performing than that data, because it is lighter. Substantially lighter. I am not ruling out that it may deviate from real numbers, but given the deviation here is only 1.7 (using the 20.9 of contacts chart) degrees per second, for a jet that is substantially lighter weight, I am going to call this pretty much correct for being bang on the numbers of the GAO. That sounds pretty much perfect to me, given the huge weight discrepancy of the comparison. I would like to see an EM diagram for a hornet tested at the same weight as the GAO data, with the same barometric pressure and same drag. Anyone got a script floating around for generating them easily? This provided data is *NOT* apples to apples.

I want less launchers running in background taking up overhead or extra mouse clicks, not more. I want to run DCS as it is right now without a launcher at all.

will we have the option to not use the launcher if undesired? (as is now)

I would also like to point out it is using ~5-8% cpu usage (5600x) in many mission files, even when the ui is closed, no manual is opened, no youtube has been played, etc etc. That's pretty insane considering DCS itself is only using 47-60% and somehow a UI layer is doing ~10-12% of the games load.

can confirm, is an issue PDI mode on the hornet does indeed use aspect of bandit instead of closure/separation rate to see if you should get hits, and thus if fox1 guidance should work. best way to see this: have bandit fly mach 0.5 away from you, have you fly mach 1.0+ towards them. closure of over mach 0.5 but you will never get hits. as a consequence of this issue, afaik, the doppler radar should also be able to see separation rate, on top of closure rate as well, which is currently impossible due to the implementation of it using aspect instead of closure/separation rate.

Spawns at El Arish, parking stall 1-10, will have the AI taxi up the primary runway, across the linkage between the two runways, up runway 34R, and then alllll the way back down the taxiway adjacent to 16L, to runway 16R again where it started, and THEN takes off on 16R. The entire time AI wingman/other AI will also not taxi while one ai is taxiing, resulting in horrible traffic jams VERY quickly. This whole process takes some ~25 minutes for one aircraft to finish a taxi process, to get to the runway end they spawned at.

where? its not in the list on the mission editor beacons list at all, which means its not in there at all.

AI will pass over small streams (water) and get stuck in the middle of the stream, over much of the irrigation around the nile. similarly, unsure if same issue, but AI pathing also breaks going under many of the bridges. going over them is fine, but crossing under them, many bridges see the AI just stop moving entirely, like they hit a wall.

yes. particularly 71X is problematic. I have also noticed basically all stations drift as you fly (only about 100m usually, only visible if you enable map underlay), but the 71X freq will drift up to like 50nm off target.