jaynus

Nope, this has always been true since at least A2 (pre-OA) ---------- Post added at 09:19 AM ---------- Previous post was at 07:27 AM ---------- Found the bug. AI Has been fixed in the latest dev build.

Can anyone please file a ticket with a repro case so we can test? I cannot reproduce. ---------- Post added at 02:43 PM ---------- Previous post was at 02:43 PM ---------- NO, I've never heard it - we are internally discussing what it could possibly be. Are you available to discuss via skype? I can pull you into our tester channel to discussion/describe. Please PM skype name and I can get you in for more details ---------- Post added at 02:55 PM ---------- Previous post was at 02:43 PM ---------- We have done no new work on JVON yet

You are wrong. Sorry. ACRE removes the *visual display* of the ItemRadio radio slot, and replaces with a inherited radio into this slot. All radio functionality of arma (chat, radio 0-9 keys, etc) all work just fine. We dont replace normal radios with 343s; we add 343s to all players with ItemRadio. ItemRadio gets replaced by ItemRadioAcreFlagged, which lets us know we already processed the user. This has the exact same functionality as ItemRadio (its literally just inherited) and works fine. ---------- Post added at 08:12 AM ---------- Previous post was at 08:11 AM ---------- Nah, hes correct, ItemRadio is required for all chat. However, again, ACRE *leaves that there so does not affect it* ---------- Post added at 08:16 AM ---------- Previous post was at 08:12 AM ---------- Oh. So when you say stutter, your not speaking to a performance stutter. Your speaking to the fact we don't recalculate directional interpolation in real time? What exactly are you asking for here? This is not a bug, its a performance feature so we don't eat up performance with multiple speakers. Are you asking for optionally being allowed to have the performance hit? Real-time calculation will be a pretty intensive FPS hit. EDIT: tracking the feature request here http://gitlab.idi-systems.com/idi-systems/acre2-public/issues/3 of adding the option of real time interpolation if you don't care about perf

All radios go to all players from the module, and the module initializes the basic mission parameters for ACRE (babel, radio channels, etc) Anything more complex than that needs to be added via init lines or scripts. ---------- Post added at 08:22 AM ---------- Previous post was at 08:20 AM ---------- We are aware; we will be adding the ability to move to window for these huge ratios. We cannot test (for obvious reasons) such gigantic aspect ratios.

It depends how they are applied; its mainly the use of addUniform/removeUniform in the same frame.

Dont use arsenal boxes. Please see a few pages back, that they completely break the arma inventory system. Completely and utterly. if you really have to, then dont change uniforms.

We unofficially publish all dev builds to the archive folder (http://acre.idi-systems.com/archive/). There is *no guarantee that they are operational builds*, but our latest development builds go live there. Build 760 is the latest RC; your welcome to test them live as we upload them, just again, no guarantees. Feel free to file tickets for them, but *please dont discuss the bugs or issues in dev builds in this thread* Also, the changelogs are not updated per-build; we wrap those up in releases. Our dev build is currently working at this changelog:

There are already fixes for this in our internal development builds. They have not been able to be released yet because of lack of testers; Cities: Skylines has kind of halted any testing on ACRE this week.

Side note - we have had no new bugs reported due to testing as yet.

Please email your ts3 crash dumps to my email jaynus at gmail dot com They will be in your Document folder; Please email the last recent ones (Sorted by date) and I will look at them immediately and see if I can help you out :)

I can't reproduce this; are you changing them via API, or physically changing them? May be that your changing of the channel via the API is not working correctly (if thats the case). We have had no issues with persistence of radio data for a long time. ---------- Post added at 10:20 AM ---------- Previous post was at 10:14 AM ---------- I'd love to hear what the other issues and limitations are; over the years we have always been told the key menus are very easy to use; I think the issue may be getting overly confused with the comparison of features. We do implement artificial limitations for realism (opening one radio at a time, radios that dont support dual band dont have dual band, half-duplex, range limitations, terrain, etc) - this is the features I speak to when I say "for realism". This isn't really a design choice to make things intentionally difficult just for the sake of it, these are physical limitations of the radios that we implement. As far as the statement "multiple hotkeys for multiple radios", sure, you can do that, with the MPTT keys if that is your chosen usage. For a unit setup, you can even use the API to assign these keys if the mission already knows what radios you are going to have. So - we do allow this. Thats what MPTT is. I'm not sure what the limitation/constraint here is. I'm not sure what limitation is being placed that is stopping you from using this. Shacktac does this, with usage of the API, automatically assigning radios to their appropriate MPPT key index (1-4) and then also channel naming and default radios for each player. For a unit setup, we've found this works out very well. In a dynamic play setup - we are flexible in allowing the MPPT being "in the order you got them", and always provide the cycling (alt+shift+caps) to choose the current radio to use. Lastly, I'm not trying to come across as harsh so please don't think so if it is - just trying to understand so we can internally discuss this, as its been banged on and discussed for years now and we have thought we found the best solutions to our problems. The behavior itself has been present since ACRE1, and I don't really see WHAT changes your asking for, except "its not tfar', which it is not. Please forgive me if I'm misunderstanding. So again - please feel free to express your limitations and issues and I encourage you to; as the majority of the time, it is very frustrating hearing that these exist and no one cares to expand on their perception/opinion. We work very hard on this product and we always are open to improvement.

I'm not sure what your asking for, at this point. As Soldia said, there are two things here: You can either swap between radios and use PTT, or you use Multi-PTT which is ordered by the order you received the radios. We have plans to make this assignable via a UI shortly, but it is currently assignable via API. To expand on your misunderstanding: The "current" radio is what radio you have selected via cycling the radios; alt+shift+capslock changes the "current radio selection". It has been this way since ACRE1 (albiet different hotkeys) and we have found it to be the most flexible method for realistic radios. In regards to your statements about bind seperate keys to radios, it really just isn't possible and I am not sure what your asking for. You mean no matter what servery our on, if you have a 148, you want to bind it to that key? Even if it is completely different comsig for a different server? This seems redundant and kind of pointless. Lastly, sure, TFAR's method ensures you never need to carry more than 2 radios; thats an artifical gameplay limitation they chose to implement and we did not. We instead chose to implement the realistic limitations you'd find present in real life. In real life, you very rarely will be carrying 2 radios let alone 3 or 4. Additionally, you'll have a PTT toggle on your vest for MAYBE your two radios. Usually more like you have 1 radio you use, every now and then. I believe you're falling into the trap of assuming ACRE provides just a TS3 extension for voice with some in game integration; which we certainly do not. This is strictly a design choice on our part, that we do not strive to provide a method of allowing people to communicate more structurally through Teamspeak. We provide realistic radio simulations and usage. Using multiple radios is supposed to be difficult; because its difficult in real life. This may explain your stutters. Thats over 10000 items; how many radios between all of these? Do your results replicate without 10000 items and 9 boxes, can you test that?

how many radios do you have placed in your mission? How many items/ammo crates?

Yes, please do this. Run ACRE+CBA only to reproduce. You have a lot of AI mods there, all which would cause that problem for you.

Yah this doesn't make much sense. What do you mean Bots? What do you mean by loop problem for them? are you suggesting your dedicated server is lagging too? We have never had any sort of report like this for dedicated servers; perhaps you mean headless clients? Are you offloading AI to them? Is it your AI is lagging? It is literally impossible for ACRE to be affecting the AI on a dedicated server, as the majority of our code does not start on dedicated server. This sounds like your server and mod set may have deeper issues, as this is definitely something we could in no way impact. We will keep looking into the client-side stutters, but you may want to investigate the performance of your mods you are using more to determine if any of them are impacting performance.

Can you confirm whether you have TS3 open or not when this is happening? I've created a ticket for us here http://tracker.idi-systems.com/issues/436

Which is perfectly correct; you are trying to use UHF through terrain; it is blocked much easier by terrain than lower frequencies. Overall, the higher the frequency the less able it is to pass through obstructions. ---------- Post added at 06:51 PM ---------- Previous post was at 06:46 PM ---------- No, antenna's will not be released until after we go stable (probably this week). Then, new alpha/dev releases will commence for some massive changes we have. Please try using the other plugin in the "Extras\vs2013" folder. This DLL should run on your system. Are you trying to detect if the remote player is currently a spectator? If that is the case then yes; this function only returns if the local player is a spectator, it takes no arguments (WOOPS! ). This was an oversight; good catch! We have corrected it in our latest build. Temporarily, you can check if(_unit in ACRE_SPECTATORS_LIST). Again though, this has been fixed in the next version which should be released soon.

Sounds like it was artifact of the terrain you had around you? We will investigate, but open air testing has been more at 15-20km range on the 117.

We'd love to improve - feel free to tell us what is wrong or what needs improvement in our thread, suggestions are nice ;) P.S. Our sounds are all in acre_sys_sounds.pbo. They are base64 encoded and free to use. Just decode them, and they are flat wav (16-bit PCM mono last I checked) files.

http://feedback.arma3.com/view.php?id=19829 http://feedback.arma3.com/view.php?id=22741 ---------- Post added at 11:29 AM ---------- Previous post was at 11:27 AM ---------- You are incorrect; this warning has been in ACRE2 since public release - downgrading is just "making it go away" because you are restarting your mission, and coincidentally not hitting the bug yet. It is not removing the error or changing anything to do with it. Downgrading is having no affect on the warning occurring or not, you will still get it.

The point is to be annoying and get the mission makers to fix their missions. Certain circumstances are well documented to break things completely (inventory system, virtual arsenal gear desync bug, overriding all PFH's, massive script lag) - so we warn on these cases, as they are cases that will utterly break other parts of the mission a lot of the time as well. The gear desync bug is what you received - specifically that gear becomes completely desynchronized between clients and the server. We have a ticket filed with BI for this - if you feel it is a problem, please upvote our ticket on the feedback tracker as this bug was reported over a year ago. Although positional continued working, it will completely break radios and a lot of other arma features. We believe it warrants letting the users know the mission is broken. Alternatively, don't use arsenal to switch uniforms until BI has fixed the issue.

We are tracking these reports and fixing them as we get them. Due to the low number of current bug reports, expect stable soon. #1. AI Unit revealing has been fixed; I made a booboo #2. Babel module has been fixed; I again, made a booboo. #3. Investigating the channel naming module errors. #4. Vehicle configuration issues; we utilize the *vanilla arma* sound values; so if you are having trouble hearing in a specific vehicle, it means the model maker did not do their sound coef settings correctly. We will not include compatibility patches due to that having added dependencies; the model makers need to fix them. If anyone notices errors in the default BI vehicles, please let us know or file a arma3 feedback ticket. Lastly, @JWordsly, that is very odd. Could you contact me on skype 'walterpearce' and we can investigate your problem?

What do you mean, it "does not work" ? How are you testing? What do you mean? How is it exhibited? Where are you seeing it? Are you expecting AI to shoot at you instantly when they hear you? If so, that is not the case. Current ACRE weighted Reveal private["_distance", "_rand", "_curChance", "_finalChance", "_curWeight"]; // Scale revealing to be a better and better chance over time // and based on distance _distance = _curUnit distance player; _curWeight = _curUnit getVariable[QGVAR(speakingReveal), 0]; _rand = floor(random (_distance ) ) * 0.1; _chance = 1.0 / sqrt ((_distance - 0.001) ^ 3); _finalChance = _chance - (_curWeight * 0.025); TRACE_6("", _curUnit, _distance, _rand, _chance, _finalChance, _curWeight); if(_rand > _finalChance) then { TRACE_2("REVEAL!", _curUnit, player); _hasRevealed = _curUnit getVariable[QGVAR(hasRevealed), false]; if(!_hasRevealed) then { _curUnit setVariable[QGVAR(hasRevealed), true, false]; ["acre_onRevealUnit", [player, _curUnit, [_finalChance, _chance], ACRE_REVEAL_AMOUNT ] ] call CALLSTACK(LIB_fnc_globalEvent); }; }; _curUnit setVariable[QGVAR(speakingReveal), _chance, false]; we strictly incrementally make them "aware" of a presence and then of the specific persons presence in a weighted method. We never set a full reveal 4; additionally, occlusion occurs for the hearing so obstructions will prevent this.

AI revealing is enabled by default; that functions return value is udefined (its a setter, not a getter).

Test disabling key signing. If it works, check your keys and key load order and bisign's client side.