User Details
- User Since
- Oct 17 2013, 1:39 PM (579 w, 7 h)
May 28 2018
Road visibility seems to be linked to terrain view distance but in an odd relation, at 3km terrain view distance the road is invisible at 700m distance.
Feb 9 2018
Nov 27 2017
Seems to be implemented in current devbranch.
Thanks for that!
Sep 8 2017
Aug 28 2017
Aug 27 2017
Any chance of this ever going to happen?
Aug 22 2017
Aug 16 2017
Aug 11 2017
Jun 18 2017
Jun 14 2017
Jun 9 2017
Jun 2 2017
May 25 2017
May 23 2017
May 20 2017
Still the case in 1.70 Jets DLC release build, it's impossible to do some proper logistic scripts with most supply trucks having one trillion capacity.
Do you guys even know that people exploit this in multiplayer by using 2x bobcats next to each other?
Dec 4 2016
Dec 1 2016
The CRV-6E Bobcat and Mi-290 Taru supply variants now also have a near infinite supply of ammunition, fuel and repair resources, just like the other supply vehicles in the game
Nov 26 2016
Still no changes in 1.64.
Nothing new here in 1.64.
Oct 1 2016
Jul 23 2016
Can you please edit your comments, otherwise this might get confusing with you stating you get an excellent amount of illumination with 1.62 while mentioning the usage of mods only at the very end of your comment.
No idea what rogerx is talking about, in 1.62 Tanoa release build, vanilla arma 3 flares are not illuminating anything.
It has 0 effect on illumination if there's a flare up or not.
Jul 15 2016
Jul 13 2016
May 10 2016
AAF shooting at civilians needs to be investigated further, do you have a quick reproduction mission to see what exactly is going on?
Might be related to the weird side relation that I've been experiencing in the past:
http://feedback.arma3.com/view.php?id=20036
You're right about the reaction to armed civilians, soldiers should react in a proper way, but as stated before, the game works in a way that the civilian side would always be the "no threat" side, you shouldn't take the meaning of "civilian" literally.
The civilians in A3 also run a different danger.FSM and won't act in a proper way either when being engaged, they will just try to flee or hide instead of trying to fight back.
If you want a proper reaction to armed "civilians" just add them to a side other than civilian.
The sides in this game were never meant to take armed civilians into account.
In the past iterations armed civilian units were always under either west, east or resistance sides.
Mission makers need to take that into account when making missions with armed civilians (if you absolutely need a fourth hostile side that is).
As to your point that AI should see armed civilians as a thread I'd like to note that there are some countries where it's normal for civilians to be armed in public (Pakistan as a non US example).
If it's only a few hangars, why not just add them to an array and rotate the direction by 180 degrees if the hanger is one of those reversed hangars?
Uh, why not use some 3rd party tool for that?
If you are having this issue in other games too (as you stated) then there are other solutions to your problem.
Still the case in 1.48.
Checked it again, it's still borked.
You can try it out for yourselfs with this little snippet:
_sidearray = [blufor,opfor,independent,civilian];
{
_getenemies = [_x] call BIS_fnc_enemysides;
systemchat format ["Enemies of %1: %2",str _x,_getenemies];
}foreach _sidearray;
Then set the independent behavior in the advanced intel tab.
Indfor friendly to Blufor:
"Enemies of WEST: [EAST]"
"Enemies of EAST: [WEST,GUER]"
"Enemies of GUER: [EAST]"
"Enemies of CIV: [EAST]"
So far, so good, working as expected.
This is where things start getting weird.
Indfor friendly to Opfor:
"Enemies of WEST: [EAST,GUER]"
"Enemies of EAST: [WEST]"
"Enemies of GUER: [WEST]"
"Enemies of CIV: [WEST]"
How the heck are civilians hostile to WEST? Doesn't make any sense.
Shouldn't blufor be the good guys for civilians per definition?
Indfor friendly to Everyone:
"Enemies of WEST: [EAST]"
"Enemies of EAST: [WEST]"
"Enemies of GUER: []"
"Enemies of CIV: []"
Weirdly civilians are now somehow friendly to opfor.
Indfor friendly to Nobody:
"Enemies of WEST: [EAST,GUER]"
"Enemies of EAST: [WEST,GUER]"
"Enemies of GUER: [EAST,WEST]"
"Enemies of CIV: [EAST,WEST]"
Now all of a sudden civilians are hostile to both opfor and blufor but NOT to indfor, even if indfor is set as friendly to nobody.
This is making it extremely hard to have 3 hostile factions without having civilian faction acting weird to the good guys.
Does that make any sense to anyone?
No, usually only when opfor is around.
So setting Indfor to either friendly to opfor or friendly to nobody will make civilians run away from blufor. Which shouldn't happen in any case at all, since blufor will never be a threat to civilians, according to the definition.
This ticket is not about if civilians should flee or not, it is about the nonsensical state of side relations between civilians and blufor.
You can also place a hovering chopper above a car and notice how you can barely hear the chopper just 10m above the car.
This definitely needs some attention.
You can play as a blufor marksman and fire a few rounds at an OPFOR static HMG raised facing away from you at 300m distance.
It takes up to 20 rounds in broad daylight, standing upright without concealment for the AI to return fire.
related:
http://feedback.arma3.com/view.php?id=19720
It's awkward to watch AI squads to run at crawling speeds when fatigued, removing any sense of tension during a combat situation.
It feels like they're about to collapse after running for only 150-200m or 40 seconds...
Probably related to this ticket:
0012505
Also some forum threads for further reference:
http://forums.bistudio.com/showthread.php?160942-Make-AI-sprint
http://forums.bistudio.com/showthread.php?186594-unarmed-AI-can-t-sprint
Still impossible in stable branch 1.46.
Just took a look into the animation preview, there don't seem to be any working sprinting animations except in the <unknown> category, is that a config mishap perhaps?
Thread for reference:
http://forums.bistudio.com/showthread.php?181024-Force-unarmed-AI-to-sprint-how&p=2739388#post2739388
"that involves math a fifth-grader can grasp"
this statement and the fact that what you want is easily achievable with scripts make it more than unlikely being implemented by the devs.
On a sidenote: If you know your average speed and the distance to your destination you can already give an approximate duration until you get there.
Let's assume you're running at 20km/h, with 4km to your destination, that's not even hard to guess.
I'm sure if you open a thread on the mission editing and scripting sections there's plenty of people who can write you a script for that, if you want to implement it into your missions.
As KK suggested, this would be a most welcome addition!
They definitely made some stealth changes to artillery, no idea to what extend.
If you hop into the SPA pieces the bearing indicator is stuck at 15, while in the mortar it's working just fine.
Also the doArtilleryFire/commandArtilleryFire seem to be less reliable now (guns will turn into the right direction, rubber band a bit and then swerve back without firing a single round)
probably related:
http://feedback.arma3.com/view.php?id=19661
http://feedback.arma3.com/view.php?id=19662
It's not about me in particular, it's about anyone who is playing the mission. If you're using DLC assets in a mission and the player who is playing the mission doesn't own that particular DLC asset he will see the "purchase DLC" popups all the time.
It's also not about the cart DLC but about all DLCs to come.
Should have been more clear in the description.
there are already small objects like soda cans or plastic bottles for this purpose.
their physx behavior when being fired at is lacking though.
Just tested the 40mm, 82mm and the Zeus GM flares in the current stable branch,
none of them illuminate the area, they're barely noticeable.
It takes around 8 mk6 white flares to achieve an acceptable (still too dark) level of illumination.
See image.
Can confirm this, uploaded 2 images.
Good to hear!
Thanks!
Upvoted.
On a sidenote most location classes are unused in A3, locations like "FlatArea","ViewPoint","RockArea" and all Vegetation locationtypes are unused and will return [0,0,0] when used as a filter for locationtypes.
What's the current standing on this?
Would make para insertions more viable since you can cover some ground when inserting from greater altitudes when not being limited to 55km/h.
Still an issue in 1.22.
Uploaded 2 screenshots, in Arma2 you could reach speeds up to 270km/h+
Why is this a ticket?
How about you try it in the mission editing and scripting forum first?
If you play around with the setmass command the ifrit feels best when setting it's mass to 22-24,000
This obviously will mess up the suspension but makes it apparent that either the mass values are way off in the game or not properly implemented (either from a config or physx point of view)
Is there any chance that these sounds will get accessible again?
Maybe I'm not getting your point but do you basically want to display trigger states using a colored lightsource in game?
This would be possible to do with simple scripts.
Could be a good addition, I hate it having my hand in the face every 3 seconds.
Would be useful in many situations. Auto-kick hot mics anyone?
As far as I know AI already designates possible targets if they got a designator + batteries and there's a friendly vehicle with GBU12s around.
Just taking a guess here but check if your windows audio settings are set to stereo if you use stereo speakers/headphones. If it's set to 5.1 and you don't have a proper 5.1 system you won't hear the center channel, where your own gunsounds are getting played.
Duplicate of :
http://feedback.arma3.com/view.php?id=17661
On a sidenote this happens on every airport on altis, only with the buzzard. On stratis airfield the buzzard is landing just fine.
Still the case on 1.22
Compare the visual quality of the H-Barrier Wall on the left with the H-Barrier [Big, 4 blocks] and the H-Barrier [3 blocks] on the right in the last picture.
Hard to believe it's the shadow causing this, if you look at the texture between the netting it looks like the resolution of the h-barrier wall texture is at 8bit or less, if you compare it to the other h-barrier standing right next to it.
Very obvious to see it in the last picture.
Is there even anyone where this doesn't look completely out of line with the other H-barrier textures? Hard to believe it's just me having some stencil shadow issues like FrankHH stated, since all other barriers are looking fine.
Switched to devbranch to check it, they are still ugly and compared to my screenshots (uploaded picture) there doesn't seem to be any difference in the shadows too.
So the issue is still there, on the current devbranch 1.19.123830.
Can you please explain how shadows make the H-barrier wall, corner and watchtower look like the pictures I posted?
Any updates on this?
The texture quality difference is really big, an eyesore compared to the rest of A3s graphics.
From the looks this seems to be assigned now,
in hope that a funtion for it will be implemented, is it by any means possible to make vehicles that are being spawned mid-mission to have working numberplates aswell?
Cheers
Still the case in 1.46 stable branch.
Would it be possible to save the license plate of a vehicle via setvariable "BIS_fnc_licenseplate" or similar?
It could work the same way like setting the go-karts numbers:
this setVariable ['number', XX];
This would be a neat little feature.
Any further input on this?
Would be nice to have for certain missions (only get the vehicle license plate as hint where to find a target etc.)
Just did some further testing, if you spawn civilian vehicle mid mission they won't have any license plates at all.
This is making me happier than I want to admit.
This would be a great addition.