- User Since
- Mar 5 2013, 11:26 PM (259 w, 2 d)
Sat, Jan 27
Sigh, I'm getting old. Already reported it, although it did not show up when searching.
Oct 16 2017
Jul 16 2017
Feb 23 2017
Feb 8 2017
Sep 23 2016
Aug 11 2016
Aug 8 2016
Note: This bug also affects accessing character inventories and ammo boxes (which technically are vehicles, anyway)
Jun 26 2016
Jun 14 2016
Jun 10 2016
May 10 2016
I think the fuzzy effect indicates that you are injured. You need to eat enough so your health starts regenerating.
The actual bug is not the fuzzyness, but the fact that you can clear it by going into the graphics settings
Have the same problem. A blood transfusion returns some blood (and hence color), but apart from that, no regeneration even after eating half a day
Same issue here, looks like every second frame is rendered a bit offset to the previous one, resulting in a really nauseating jittering
Still valid. Init event handler is not called for non-player units
I think, as long as we have to edit the loadout of every single unit with the Initialisation box
By all means, that is of course a much more important functionality, and as far as I understood it, it will be in.
If you ever worked with the Neverwinter Nights toolset, it had a similar problem: when the fog and ambient lighting were enabled, you couldn't see much since things you placed beyond the fog range were simply invisible, and maybe the whole area was too dark. You could switch both fog and ambient lighting off with icons in the toolbar, for a much clearer view.
With a possibility to switch off the current weather and daytime in favor of a clear visibility condition.
Compare those two shots:
Spot the difference. Assuming you are doing a mission with the lighting conditions of the first shot, you will be thankful for a switch to something where you can actually see something at all.
Every time you test you need to establish the final weather conditions for your mission, since the AI is heavily influenced by the weather and daytime. Now assume you would have to make those changes every time you want to test and edit.
The new editors main focus is usability, and this very easy to implement feature would make it more usable.
Maybe it IS opinions, but I see a great potential in such a functionality.
Whoa, there's some proposals... so instead of implementing a functionality that takes less lines of code than the "creative proposals" you have for solving the issue, you expect people to "change the weather settings a couple of times in between to check" or "make screenshots" ?
Just because you don't see a direct use for this kind of functionality doesn't mean it's not necessary. I for example like to give some thoughts to the weather settings and daytime I use for my missions, so I spent quite some time tuning it.
Again, this is functionality that can be implemented with very little code, will immediately benefit everyone and does not require users to fiddle around with nonsense like screenshots.
Sometimes, I don't get you guys.
It was mentioned in the chat during the stream that this is going to come in
I had similar issues when AI in the editor suddenly started talking
For the record latest Dev build exhibits the exact same problem. Note again, must be dedicated server
Please see attached example:
A dedicated server outputs:
"paramsArray has scalar entries and value any"
"paramsArray is of type "
while a self-hosted server outputs:
"paramsArray has 4 entries and value [1,25,0,1]"
"paramsArray is of type ARRAY"
To reproduce: Start a dedicated server with the supplied mission, launch it by slotting in and clicking ok, and then examine the server's RPT file
Actually found a way to make it work, by NOT using the predefined CopilotTurret. While this is still a bug of sorts, this means that this ticket can now be closed.
Yes, the problem appears with non-official content, but the problem itself is in the engine, not the content. The Plane_Base_f base class DOES define the copilot turret, hence I am assuming that it was put there specifically for custom made content to make use of it (since, as you said yourself, there is no copiloted plane in Arma 3's vanilla content)
I am the author of the mod in question (CUP). I've ported the C-130 from Arma 2 to Arma 3 and it exhibits the problem. I also saw it in other Arma 2 ports like the one I quoted on the original bug.
I understand that the developers can't do anything about the problem in the mod, but I was hoping that this issue could be addressed on the engine side, since I _suspect_ (without having knowledge of the engine, of course) that the problem is rather minor and most likely easily fixed.
Uhm, not wanting to sound rude, but can't you at least leave the issue as open and unresolved ?
Confirmed it's still a problem in 1.52
The problem seems to be random. I'll try to see if there is a pattern, but up to now I haven't seen one.
Might be related to #0020746
Yes, it also happened on the Speedboat Minigun
Confirmed, works now. Thanks!
This has been fixed in the latest Tools beta
This bug should have a severity of critical, because it basically makes every mission with UAVs unplayable if it also involves a vehicle or a static weapon.
If necessary, I can provide the addon files that produced the problem
I was able to find out that the problem apparently was caused by a duplicate shadow volume 2. Seems that Binarize has problems with certain or too many shadow volumes.
I've reported two bugs (#15730, #9184) that also tie in to this bug, so I suggest setting them to be related
This is likely caused by the way UnitPlay is implemented. See Ticket #15919.
Basically, UnitPlay uses a hidden control that provides the timing. This means that any new dialog (like splendid camera) will kill it.
Same problem here.
Interesting sidenote: Start local server with no missions subscribed, then open the workshop, subscribe a mission, and you will see them pop up.
Restart the game in this state, and again crash
Not necessary anymore
Yes, I mean that, mixed up the two. See, I changed the ticket to prevent any further heart attacks to you.
And I am well aware that the command does not work in multiplayer. You might want to re-read the ticket, because I said "or disabling simulation". Zeus works in single player too, by the way.
But never mind, I found a way around this anyway, so this ticket has become moot.
Note: This bug report is still valid
You should be more explicit in the feature requests, and give examples
It's the Arma 3 feedback tracker, so excuse me if I assume that people would know that it's related to Arma3 and now DayZ.
I'm sorry, the title alone says it all. I can not understand what I should make more explicit.
And honestly, what's with the downvoting ? Would one of you downvoters be so kind an actually say WHY you vote it down ?
Did you actually bother to read what I wrote ?
micovery: The dev build now contains "DayZ" items, i.e. items taken from DayZ that are basically placeable objects. This feature request has absolutely NOTHING to do with DayZ, that's why I put the "DayZ" items in quotes, basically because the items have been announced as items taken from DayZ.
KevsnoTrev: Yes, I know that they are in the SITREP states that they are in the dev branch, and they are in the dev branch, just as CfgVehicle classes, i.e. static objects that can be placed. The feature request asks for them to be available as CfgWeapon classes so they can be used as items in your inventory.
And honestly, I don't know why the heck people vote these features down ?
They aren't, it's only vehicle classes that can be placed in the world, not items that you can have in your inventory
Koala, you misunderstand the point of this feature request.
I'm quite happy that it is possible to remove any trace of the "magic player position indicator" on the map (see my other bugs #15266 and the now closed #5568, reported by myself).
The point is: In Arma 2, you could actually see the GPS (the device) on the map screen (along with radio, watch, and compass). It would not show the map, but it would show the coordinates.
In Arma 3, the GPS is not visible. To actually know your coordinates, you have to switch back to main view, open the GPS with CTRL+M, read the coordinates, and then switch back to map and determine your position.
What I would like to see is the GPS, showing the coordinates (not your exact position) to be visible on the map screen.
This is somewhat related to bug #8485, but this report really just calls for the basic GPS, not additional tools.
Just a heads up, this has NOT been fixed yet
I *think* this was related to the paraglide crash that was fixed in Build 10747. The mission I was testing with previously started with paragliding. I could no longer reproduce the problem with another mission (no paragliding), so I would say the issue IS actually fixed.
Note: Definitely fixed
Not solved, bug is still present
According to Wikipedia, a Combat Lifesaver is a non-medic soldier with moderate emergency medical training. If that holds for Arma, it might hint at a separate medic class
First of all: You insisted on insulting me. Secondly, I did not call you a troll, you called me a troll.
On topic: Even if they are on different sides of the island, they know when the other has been killed. Nothing more, nothing less. This only works if they are in a group. If they are not in a group, they don't know. This is without having any means of communication (no radios).
To get back to the example with the perimeter guard, if the guard would have been in a group of it's own, it would not have alerted anyone to kill him.
The point is: Without changing any other circumstances, detection is only dependent on the grouping. If group, they know, if not grouped, they don't know.
The point you missed is that the only "scripting" involved is the dostop command, which is given ONLY to prevent the units from wandering around.
You said: "If they need to share target info you could use the 'reveal' command (probably more tedious than using doStop, but just saying". This is the reason why I think you did not understand the problem. This issue has nothing to do with scripting, it has nothing to do with the reveal command. There is a good chance that the remaining team member doesn't know about your position at all. But they do get alerted when any team member is killed, even though that should not be possible (being on the other side of the island without radio contact).
mepwaygame, with all due respect, but unless you start reading the post and understand what is going on, I suggest you cut back on the snappy remarks.
So instead of calling me an "annoying little troll", you should actually understand what I am saying. You agree with the ticket but you don't understand what it is about ?
"Here's a point for you: Groups stick together and share information by design. If somebody scripts them to behave differently, then they should have a good reason for asking Devs to change the way it works. "
Here's one for you: Individuals do NOT have extra sensory perception. The point is that if you have, for example, a perimeter guard that NO ONE sees and you kill him WITHOUT the others noticing it, they still know. This is clearly NOT what should happen.
And for your information since you don't seem to have gotten that: There was NO scripting involved that changed anything about their behavior.
"I'm wondering now why these AI need to be in the same group? If they need to share target info you could use the 'reveal' command (probably more tedious than using doStop, but just saying). "
Not the point.
The point is that they automatically know that their buddy is dead IF and ONLY IF they are in the same group. Even if they are on opposite sides of the island without any radios.