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.