Even inside an SDV?

SDV are not water proof AFAIK.

Just like ACE did? although they made the backpack slot a place to put another gun

I added the newer info on the original post for better review. I hope that is ok

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

<i>I still would put this as user error and move to close this post :)</i>

I disagree. If there is a conflict it should be clearly indicated.

The problem seems to arise when the key assigned for "Change Gunner weapon" is also the key assigned for "next weapon". Once they are separated the problem disappears. Usually a key that is assigned somewhere else shows in red but not in this case.

I still would put this as user error and move to close this post :)

@Killzone_Kid :
I had two different needs about the invulnerability :

• Be invulnerable when a condition NOT depending of the future damage events is true -> I succeed easily with allowDamage
• Compute a condition depending of the damage event context to know if the current Damage Event has to be ignored -> I succeed hardly with HandleDamage EH.

The two needs have been fullfilled. So I'm personnaly OK :)
The first need is not perfect because doing "allowDamage true" at the end may do vulnerable an object which has been set invulnerable by another script or by the mission maker.
The second need was hard due to the getHit missing but never mind.
I used some tricks and it is not 100% perfect.

@SilentSpike :

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

Of course if there is only my script running on Arma. But we need the command to ensure compatibility between other scripts and with the mission maker choices in the initialization line (if he adds "allowDamage false" on specific objects).

Note :
Using (then removing) the event handler HandleDamage to return 0 is not a viable solution.
Because returning 0 doesn't only make it invulnerable, but also do a "setDamage 0".
In addition, the missing of the "getHit" command makes difficult/impossible to keep the health status properly.

Thanks for your comments. I'm agree for the command name, isDamageAllowed is clearer.

Although I personally don't see the need for such command

What do you suggest ? :) You have a better solution to make temporary an object indestructible (without "corrupting" its current damage state) ?

Although I personally don't see the need for such command, if added, the name should be

isDamageAllowed

to keep with Arma SQF commands names convention.

Also allowdamage takes local argument, this means isDamageAllowed would query only local instance of the object. This would be pretty awkward.

I need an example of practical problem to answer that. Not sure if the example you provided makes a compelling case for such command, well at least I'm not sure why do you need to use it there.

Well fine, there might be a case when you might want to know if after changing locality the object is allowed to take damage on particular client, maybe. I'm not against new commands, was just curious about the usefulness of this particular one.

Fixed in 1.32 version

Hmmmm, I'm stumped then. I don't experience this issue and I can't think why the osd text would be particularly demanding. Anyone else got any ideas?

Thanks Cenwulf, very helpful!

The OnScreen Display (OSD) function, which is frequently used in the campaign, and appears at the bottom right-hand corner of the screen, with digitally typed text that then disperses, appears to be taking a huge amount of energy to perform. Sometimes, it starts halfway through the process and the audio is delayed (normally on the first mission load). I hope that's a bit clearer, sorry!

This doesn't sound like the issue you describe is actually caused by the OSD text. Sounds more like your game is simply lagging on first mission load (which is common) as this is when the system is under heavy load as it initialises all the AI and scripts for the mission and loads textures.

The OSD text often coincides with large amounts of data being loaded as it is commonly displayed at the start of a mission or after a large transition from a cut scene, common times your system will be experiencing higher than normal load.

Cenwulf - I've tried the OSD script at later points in the mission, still suffering a sight but problematic lag / delay.

I'm sorry, I don't understand what you're talking about?

Many explosive devices have anti-tampering mechanisms, especially anti infantry mines such as the Claymore. Sadly Arma 3's Claymore is not implemented to its full potential (As with many of the mines). Currently they can only be manually detonated. You can still use this to your advantage. If you are spotted, retreat without being seen to a position overlooking your last. Then when the enemy walks up to your original position to investigate, blow them into dog food with the Claymore.

UPD:
This bug depend on pilot fraction. So any IR grenade (CSAT, NATO, AAF grenade) will be "green" to any aircraft (even СSAT and NATO) if the pilot of this aircraft is of AAF fraction.

AAF pilot + any aircraft (CSAT, NATO, AAF) = any IR greande is "green" on the radar of this aircraft.

I don't know and it doesn't matter I think. There are AAF IR grenades in game also and they are "green" for AAF aircraft radars too. It is a bug I think.

If any IR grenade is green for AAF, then why does AAF fraction has it is own AAF IR grenades...

Are you sure the IND side are not set to "friendly to everyone"?

how can you throw those ir grenades? I never can seem to get an option for them.

Like any other grenade. Take it from ammobox, press Ctrl+G to choose IR-grenade and then press G to throw it.

Hello,
do these crashes happen on Arma with no mods activated? If so, would it be possible to upload crashdumps from the vanilla session?

Thank you very much.

Rar added with 3 files.
I will upload another one if we get this error again

Hello,
Thank you for reporting the issue.
We need crash dump files from this folder for solve your problem.
C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When package will be smaller than 5000k, you can attach it here. When package is bigger, please use some free sharing service and post link here.

How to find correct crashdump file:
Try to make the crash happen
Look into crashdump folder
Upload crashdump with latest date in name (crashdump is rpt + bidmp + mdmp file with same name). Please try to provide as many crashdumps as possible, it helps us investigating the problem in a big way.

Thank you.

http://feedback.arma3.com/how-to-user.html

some help ?

http://forums.bistudio.com/showthread.php?179022-Help-Crash-arma-3-server-dedicated

can be a hacker ? script ? server ?

should be fixed since DEV. 125466 and will be distributed tomorrow

unfortunately i can't test it right now because my entire modfolder was deleted some time ago and i lost the map i was working on.

Can you guys confirm the fix?

Ok, i'll explain myself better.
I have a small map, 2048x2048m, with roughly 20'000 objects (of which 17k are plants) as of now.
Until a few days ago buldozer was loading fine, then it just stopped working out of the blue.
I tried to reboot my pc several times, load previous savings, still no results.
A few moments ago it was still doing that.
I went into my library, hid all the plants, started buldozer with just 3'000 objects on map and it started flawlessly.
Went back into my library, set all the plants to "show", restarted buldozer and the issue seems to have fixed itself.
I can't give you any more detail because there really isn't anything else to it.
One minute it was working, the next it wasn't.
If there's something more i can do let me know, thanks.

Well good to know, thanks.

This issue is not about TerrainBuilder, but Buldozer side. We already know what's wrong. Patch will be released soon

Hello,
could you please provide exact repro steps how to make the crash happen? We cannot reproduce it on our data. Thank you.

Killzone_Kid - you humble me. Thanks ever so much. I read your blog every single day when I should be working. Thanks, man - you're a legend in this community! I'll close this ticket!

showHud false

You can do a check by yourself, write one then read to know if it is writable I suppose, not a huge workaround

EDIT: On second thought, this will require game restart as values are read from memory after assignment. At the moment saveProfileNamespace returns nothing, but making it return boolean (true) on successful file operation would probably be the easiest solution.

so +1

I am not sure what to make of this. If this is meant to be a serious bug report please create a new ticket with a description of what the issue actually is.

This is a result of changes made due to the update. All you should need to do
is re open the mission in the editor and save it again.

Response: thanks for the note, opening existing missions > PBO and saving again is not easy to accomplish, are there any documented steps to complete this?

Issue History

Date Modified Username Field Change

2014-06-14 07:39 Pip New Issue
2014-06-14 09:43 Rellikplug Note Added: 0072706

" All you should need to do is re open the mission in the editor and save it again. "

There must be something I am missing here you make this sound very easy but it really isn't. For a start you cant open a PBO in the editor....