Just tested and this still occurs in 1.24

Way to be a child. Why did you even open this issue when you have an existing issue in which a dev has already given you a response?

http://feedback.arma3.com/view.php?id=18803

Mission makers already have the tools to allow zeus to edit pre-placed objects so I don't really see what you're asking for here.

Use alt+right-click

Duplicate of 0019390

Yeah, voted up. Though not sure how easy this would be to fix really.

I think this is just the bullet penetration system at work

Console availability can be set by mission maker. It shouldn't be available to all as that would break missions where zeus is not suppose to have total control

This can probably be closed as resolved

Would it be worth it though? As there's already the parameter to handle all editor-placed units. The only non-scripted thing not handled by that parameter (that I can think of) would be zeus.

(I mean non-scripted as in it can be set up purely through the editor)

Yeah, just other objects which can be destroyed in general. I think it would be nice if the system could handle them when added by the new commands, but personally see no reason for them to be supported by default.

Edit: These kind of things are what I mean https://community.bistudio.com/wiki/Arma_3_CfgVehicles_EMPTY

@KK, nothing specific in mind right now. It would just be handy in more dynamic cases where perhaps you want spawned objects to be cleaned up without hassle. It's certainly a more of an edge case usage, but it never hurts to have less limitation so long as it's not at the cost of something else.

That said, I'm extremely content with the current improvements and see no reason to add support for objects if the devs' time could be better spent! :)

That sounds perfect to me. Thanks for working on expanding this system, makes things a lot more convenient for mission creators.

If I were to use one of the new commands on a building I had placed down or some other destructible object that isn't a unit, how would the system handle that? Would the command simply be ignored or would it also clean those after death?

Awesome :)

Would also be useful to have the ability to set the system to include all units by default, but even if that's not possible/planned then the new commands sound great on their own!

Alternatively:

obj allowDisposal bool

Latest dev branch changelog includes:

"Added: UnitRemoveManager for SP and MP"

This sounds interesting.

Thanks for the response! Will patiently wait and see what the outcome is. That combat behavior thing is useful to know, will keep that in mind.

Edit:
"Also note that the distance a WP completion is checked by the AI differs according to the type of vehicle used."

Would be interested to know if this applies to cargo units also. The reason I noticed this behavior was because I'm trying to get a waypoint to trigger for a group in a helicopter's cargo space in order to trigger a paradrop.

Noticed this weird jittering as well but was unsure what specifically was causing it, definitely visible in combat pace.

Confirming this. Noticed it the other day.

On a somewhat related note, it'd be interesting to have a similar test for the dead body cleanup settings. I tried using them to reduce the time bodies stay around and they just seemed to stay regardless.

See my posts and attached image here:

http://feedback.arma3.com/view.php?id=19016

Player is meant to be given U_B_survival_uniform, which has fins on it. However, the image clearly shows there are no fins on whichever uniform I was given.

Couldn't you use the setVariable command when changing the damage allowance in the provided example?

The time bodies will remain can be defined in description.ext of your mission, but I could see such a module being handy

This ticket is extremely vague. Do you have a picture or something?

There are currently 2 possible sitting animations I can think of. One can be toggled by pressing # and the other can be reached via ctrl+s

Setting it to careless doesn't resolve this?

Can't say I've experienced what you mentioned. The behavior you describe definitely shouldn't happen because the renegade unit should become part of sideEnemy:

https://community.bistudio.com/wiki/sideEnemy

Yeah, you'll become a renegade if you kill friendlies. It's not an issue at all as you shouldn't be killing friendly units.

I wonder if it might be a multiplayer related issue as I can also get the original snippet working in the SP editor. Whereas I was testing in a MP environment before. Will try and get a consistent repro up.

Figured it out, simply a case of the command being called at mission start causing it to have no effect because the curator objects presumably aren't yet assigned.

Tested using this in init of appropriate unit:

systemChat format ["AssignedCurator is %1",getAssignedCuratorLogic this];

Returns:

"AssignedCurator is <NULL-object>"

Issue can be closed unless this is unexpected behavior.

To whoever voted against the issue:

Could you explain why? Are you able to get this command working?

Seems the problem might be a bit more specific, this works:

this addAction ["Unassign Curator Module",{unassignCurator (getAssignedCuratorLogic (_this select 0))}];

You're kidding me, right? Is this really an issue to ask for free DLC?

The whole point of the messages is to allow you to access the DLC for free with a drawback, so as to not divide the player base.

How did you buy ARMA if you are unable to buy the DLC? If you can't add funds to steam, buy it through the BI Store.

Ah, great point. Voted up!

Isn't that kind of the point of auto weather simulation though?

If you were scripting the simulation instead then surely you'd simply turn off the auto simulation.

Strange actually. Now that I look at it the same uniform is being given to other AI units in your squad and they have flippers. However, the player character doesn't get the flippers even though they're wearing the same uniform.

Seems like something is acting up behind the scenes. Could explain your missing rebreather.

This is from the wet work description.ext:

add[] =
{
{"uniform", "U_B_survival_uniform"},
{"vest", "V_RebreatherB"},
{"goggles", "G_Diving"},
{"backpack", "B_AssaultPack_blk"},
{"magazine", "SmokeShell", 1}
};

I haven't had a problem with a missing rebreather but it seems strange not to give you a diving uniform. It means the player is unable to keep up with the AI units who can swim faster because of their uniforms.

Should a new ticket be opened for the uniform or is it closely related enough to just report it here?

I thought that got fixed a while back? I definitely haven't experienced that problem in months

Edit: It's also not directly related to this really. That sounds as if the module isn't doing what it's supposed to, this is simply a failure to account for waypoints in the scripting.

Still an issue in the latest dev branch

Attached image shows the issue in action. You can't see my cursor but the waypoint is near the bottom of the image

What backwards compatibility is being broken? Nothing has changed, a new command has been added to offer more functionality.

Added a repro mission. Could not reproduce.

Wait, really? That's hilarious! I have to test this out now.

This isn't a bug.

edit: I should clarify, this is the current state of zeus and it is already known. This feature is already a priority last I heard. Here's a link:

http://www.reddit.com/r/arma/comments/1yjqjy/you_can_now_control_ai_units_with_zeus/cflqi59?context=3

There's probably a more official one somewhere.

Related/duplicate: http://feedback.arma3.com/view.php?id=17686

It's not a major issue. Major issues are crashes and game breaking bugs. It's a significant issue, but the sad fact is game development takes time. I trust BI will fix this in time.

I won't argue with you, but look at it from a developer standpoint. It's not game breaking, just a bug in a feature. However I agree with you that it is a large issue from a player's perspective. Just trying to raise awareness to the fact that issue priority is very different for developers than it is for us.

I've uploaded a mission to repro what I think he means, you'll see it best in 3rd person. However, I don't believe it's a bug.

The smoke is grey on the surface if the grenade is underwater, this is seen more clearly if you swim down and watch the smoke produced at the top of the bubble stream.

Resolved in latest dev branch

Working for me in 1.20

Experienced the same issue here

Wouldn't it make more sense to switch the unit which is respawned and leave the dead body as is? (Perhaps I've misunderstood the current system)

Yup, can confirm that flares still don't illuminate anything unless they're fired directly at the ground.

Trick isn't possible for something like the zeus flare modules though. Which is the problem I'm running into.

Agreed, I remember encountering red flares in the night showcase and they were lighting up the whole area with red and it was great.

Now I literally cannot tell if a flare is nearby until it goes out, because the lighting is so weak that it's unnoticeable until there's a sudden change.

Good suggestion, currently the group I play with rely on a curator extension addon I made to allow us to easily enable/disable this feature (as well as a few others like the eagle, the wind noise and the notifications that pop up when someone becomes zeus). Having it as part of the curator by default would be convenient.

Um, I hate to break it to you, but there is wind in ARMA 3.

Huh? Shift is most definitely the default thrust key. Q and E both control the rudder by default.

You guys might want to check this out:

http://feedback.arma3.com/view.php?id=19377

Well...I expected a rational response, but okay then. I'm not here to argue, I've already voted the issue up and made it clear that I understand the frustration. Just trying to promote actual constructive discussion instead of blatantly over-dramatic reactions.

If you want to continue wasting energy then fine by me.

I understand the frustration, but yes, overreacting is never the answer. At the end of the day it is a game and it's not worth getting upset over.

If you are a game developer yourself (as you claim) then I'd expect you to understand the developers point of view in this whole process. You're jumping to multiple conclusions that you have no evidence to support and it's not helping anyone. (In fact, the evidence is against you on the Zeus DLC taking up development time. That's being managed by a very small portion of the team that you can count on one hand).

Also, look up psychological projection because you've just exhibited a classic case of it.

1. Calm down, nobody will take you serious if you overreact to everything.
2. It could very well be the array that goes off by one, but you don't know that so stop assuming this is a simple fix. Games are made up of many components and it could easily be the case that there's more to account for here.
3. Yes, core functionality like this should be fixed but it seems like you guys have no idea how the process of game development goes.
4. Lux0r, get your information correct before making a fool of yourself talking about it. Go read up on the DLC.
5. This bug is in no way similar to a visual bug like that. Do you really believe those bugs are taking attention away from this?

If you want to be constructive in regards to this issue then go and bring it up somewhere where it is more likely to be seen by a developer to refresh their memory on it. Just because it's assigned doesn't mean it's being actively checked and the issue tracker is full of issues which means it's easy for each individual one to be overlooked in the sea of the rest.

I can't reproduce this on stable with no mods.

So this is what had me very confused the other day. Yeah, can also confirm it still happens.

I've had very strange experiences with this command in general, in one of my missions it works perfectly almost every time and in another they always move their gun and move it back without firing. However I'm not too sure what to report as I can't get consistent results.

Voted up as I can actually reproduce this consistently.

"It's also the only way to scale over small obstacles. You're better served with a improved anti-clipping system to stop the glitching."

What about all the stances in between though?

This can also happen using the findEmptyPosition command to place units, as well as when placing units with zeus.

Have experienced this issue, attached two more images.

As far as I know ARMA has always only allowed int values as parameter values.

I ran into this too, rocks seem to be the main problem for me. As long as they're big enough for the unit to fit inside without touching the actual mesh then the command thinks it's empty.

This issue also means there's no environmental when in a steerable parachute.

Duplicate issue: 11446