Magirot

Is there any way to either disable PhysX collisions, or affect the damage caused by them? I've been having a lot of small problems with this, and related issues seem to pop up regularly for many people here. Just to bring up a few examples, other units can be knocked with attached objects, so attached briefcases, lanterns and such become very dangerous. The AI then panics whenever someone in the group takes damage from them. And my rescue boat pushing script became the deadliest element of a mission, because pushing boats even from behind will quickly kill you if you're too close. My first thought was to try using a HandleDamage event handler, but it seems that damage from PhysX isn't linked to the object causing it, so it's hard to confine. disableCollisionWith also says it doesn't apply to PhysX. Is there some trick here?

For the loading objects; unfortunally not. In one mission I used this in a trigger and it seemed to work: if isServer then { [box1, convoyZamak1] call CSE_fnc_loadObject_LOG; }; Are there some problems with it that I didn't notice?

The fields of Bornholm made me wonder if there even is a solution available for them. I mean, currently the AI won't spot a player unit that's prone in a field like this (so they should be configured?). However, since the rye doesn't block their line of sight, they will see anyone who's standing up, even if a player's vision in the same spot would be completely blocked by the rye. It seems like the same old Arma 2 problem that just hasn't been as pressing in A3, since there's much less long grass on Stratis and Altis. I really hope it could be fixed, though, given how awesome this map is.

Not reliably, see Killzone_Kid's comment: https://community.bistudio.com/wiki/setDir

I assumed that the player in that comment just referred to the client, but after testing I stand corrected: Loaded the mission on a dedicated server: 18:37:04 "init.sqf: tick: 642.903. player null: false. clientState: GAME LOADED." 18:37:04 "initPlayerLocal.sqf: tick: 642.965. player null: false. clientState: BRIEFING SHOWN." Quit and return as JIP: 18:37:43 "init.sqf: tick: 681.851. player null: true. clientState: GAME LOADED." 18:37:44 "initPlayerLocal.sqf: tick: 682.213. player null: false. clientState: BRIEFING READ." So player is null in init.sqf on JIP, but not in the new Arma 3 event scripts.

initFunctions.sqf only checks getClientState, which as far as I understand doesn't serve quite the same purpose as player == player or !isNull player. If it's enough or not depends on what you're doing with the script, I think. Also important to note that it's only responsible for executing the new Arma 3 init event scripts (initServer, initPlayerLocal and initPlayerServer), not init.sqf.

I just tested on a dedicated server and they show up fine for me, like they should after the fix half a year ago. Has anyone else had this still happen?

Yeah, that's how it still works. Group respawn still allows JIP with disabled AI (disabledAI=1 or turned off manually in the mission lobby) if there are slots left, we use it all the time. Side respawn, on the other hand, doesn't seem to work at all in Arma 3. JIP throws you in as a seagull even if spectator is enabled, and you don't switch to AI units on death even if they're present.

Even if seagull spectator isn't enabled, seagulls are still spawned above dead players in multiplayer. I'm confused that people don't seem to have made any note of this. Some months ago I found this ticket (which has a script to fix it), but that's been all. Is some common setting that I'm missing keeping them from spawning for the majority?

I've only ever set respawn to GROUP (to enable JIP). And actually now that I look at it, I guess this is the reason: It would make more sense if seagulls were only in if respawnTemplates had "Seagull" in it. Having it in the base respawn type like that feels outdated.

Maybe it works if you create the box locally for each player with createVehicleLocal?

The join group functionality doesn't seem to have worked for us since the addAction confirmation was added. Is anyone else having problems with it?

You can use post process effects to simulate it, though when players go to video settings, they can temporarily see things without the effect. ppColor = [url="https://community.bistudio.com/wiki/ppEffectCreate"]ppEffectCreate[/url] ["ColorCorrections", 2100]; ppColor [url="https://community.bistudio.com/wiki/ppEffectEnable"]ppEffectEnable[/url] TRUE; ppColor [url="https://community.bistudio.com/wiki/ppEffectAdjust"]ppEffectAdjust[/url] [0, 0, 0, [1, 1, 1, 0], [1, 1, 1, 0.0], [1, 1, 1, 1.0]]; ppColor [url="https://community.bistudio.com/wiki/ppEffectCommit"]ppEffectCommit[/url] 6; // how many seconds for the effect to be complete This would be completely dark. You can try adjusting the colorCorrections values for a less dark effect (or maybe someone else can give good suggestions), and use ppEffectDestroy ppColor; to restore normal vision.

It's not a map engine problem. The Stratis/Altis lighting is the default lighting, people change it for a reason.

You have to set which side independent is friends with from the intel menu (click the weather), like in vanilla Arma.

The mission-side TF_give_microdagr_to_soldier = TRUE/FALSE is currently missing from https://github.com/michail-nikolaev/task-force-arma-3-radio/wiki/API:-Variables

Thank you for the new version! Especially this part:

First of all, thank you for the new versions! We didn't manage to test all features yet, but I liked the ones we could see. There was one issue, though: when a mission ended, TeamSpeak didn't update player status and switch their channels before a new mission was loaded. Previously players would be moved and could all talk once the debriefing screen hit. Does anyone else have this & is the current behaviour intentional?

Does this mean that custom spectator scripts would allow spectators to hear alive units? What would it require of the script, generally? The night version of the radio interface looks really nice!

Is anyone else having problems with not all difficulty settings getting read? Other difficulty settings seem to work, but not the new AI accuracy setting, precisionAI. If anything the AI is even more accurate than on default.

You can't put an if statement in an init line (at least not without using spawn). The easiest way would probably be to create a file called initServer.sqf and put it there: Thanks for explaining how to use this with AI, KoffeinFlummi. I've been wonderin'.

Ohhh, that's very good to know.

Wait, doesn't !isServer already exclude headless clients, since they're not counted as servers? In this case it's to make sure that only one machine, the server, runs setHit, which doesn't require local executions. If you use "exit if !hasInterface", it should run for the dedicated server and headless clients, even though the latter aren't needed - also if it's hosted from the multiplayer menu with no headless clients, with the server being a player with an interface, it doesn't get run for anyone. I've usually seen hasInterface used together with an isServer check to avoid this possibility. ^ erm, I don't know what I was thinking/reading. The thread is just getting more and more of a mess. D: If Vostov's head hurts at this point, I still recommend simply copy-pasting this into a trigger activation.

This is really biting at the sidelines, but thisTrigger obviously doesn't work inside the script. :) I do agree that the trigger not requiring a script that you iterate first is the best way.