jaynus

updated for Beta 74630 :)

In the log, or popup?

The PRC77 currently has the same values as the 119. Nou can answer better on the signal map. Takistan does kill reception pretty well. They are big mountains. The 119 and 77 are both VERY old radios too. The 148 is much stronger than them.

D3lta, can you please confirm this is when you ARE or ARE NOT using voice activation?

The 343 is on a completely different frequency spread (2.4ghz) than the other radios; it cannot share frequencies with the other radios.

Thanks. I'm back at the grind as well, folks. So dev is back to about 80% full forward again (still slacking a bit, but back on the ball)

Version 1.3.6 Released Support for Version Beta 74123

while {(GVAR(runServer))} do { if(isNil QUOTE(GVAR(pipeHandle))) then { LOG("ATEEEMPTING TO OPEN PIPE!"); GVAR(pipeHandle) = ["\\.\pipe\acre_comm_pipe"] call jayarma2lib_fnc_openPipe; if(isNil(QUOTE(GVAR(pipeHandle)))) then { if(time > 5) then { hintSilent "WARNING: ACRE IS NOT CONNECTED TO TEAMSPEAK!"; LOG("Teamspeak3 not responding, trying again."); }; GVAR(serverStarted) = false; } else { LOG("PIPE OPENED!"); GVAR(serverStarted) = true; }; }; sleep 5; }; and in another script (read script)... if(!(isNil QUOTE(GVAR(pipeHandle)))) then { _ret = [GVAR(pipeHandle)] call jayarma2lib_fnc_readPipe; if(!(isNil "_ret")) then { if(!(_ret == "_JERR_FALSE")) then { if(_ret != "_JERR_NULL") then { TRACE_1("got message", _ret); _ret call GVAR(ioEventFnc); }; } else { GVAR(pipeHandle) = nil; }; }; }; ---------- Post added at 01:56 PM ---------- Previous post was at 01:55 PM ---------- oh and I forgot to mention - we use async pipes in JayArmA2Lib, so read will *always* return instantly, it does not block. Same with write. So you can guarantee off of those basic return values in read whether the read was successful or not. Write operates basically the same. But we have it as a *guaranteed* communication of a single packet if the pipe is open. No partial packet failures. ---------- Post added at 02:12 PM ---------- Previous post was at 01:56 PM ---------- Added OA Beta 73968 Support VERSION 1.3.5 - Added OA 1.54 B73968 NON-STEAM beta support

http://dev-heaven.net/projects/a2ts3/wiki/Class_Names_and_API As we always say, watch http://forums.bistudio.com/showthread.php?t=98647 for beta support. We aren't' guaranteeing nor officially supporting *any* beta via ACRE officially. We just package up whatever the latest jayarma2lib was at the time because we are nice :)

http://srv2.unitedoperations.net/ACRE_1.0.10.137_NEW_DLL.msi New test installer. Use at own risk - is same as that package nou gave.

We will be doing a DLL-only hotfix shortly. We decided to not push any new features, and keep our version at 1.0.10. So it will strictly be a few crash fixes on the DLL and a version fix for TS3. But like nou said - I have 3 episodes of "Weeds" to catch up on, and am on a star trek kick atm. We are taking it easy :P

updated for new betas I didnt increment the version number (left it at 1.3.3), as most everything else said it was 1.3.2 :)

From our Known Issues list:

Are you using multiple tabs? Do these crashes produce any dumps, or are they hangs that do not (Dumps go to your Documents or my Documents folder).

@Howard: We have had reports of anti-virus/anti-spyware blocking the communications. Any possibility of that happening? Try disabling them @SwissMAG: Yes. It is confirmed that the crash *ONLY* occurs with your groups *specific* addon pack. If you just remove it down to ACRE+ACE+CBA, it works fine. It is the specific addon of your group - we are looking into the crash to see if its jayarma2lib specific or a addon conflict crash (suspected).

Ah. Yah - we have no concept of duplex in our code, its just whatever limitations we give it. And right now, all radios act as full-duplex anyways. As for the RXMT - its only a virtual object right now. Later, for deployable radios, than duplex will come into play.

@Woodoo, @Cyborg11: Did you *read* the error? All it means is you didn't have ACRE selected in plugins. It just is letting you know it wasnt loaded. @M1n1d0u: Yah I know...working on it, some vehicles don't position correctly it seems. @mia389: Can you confirm that these are *ARMA2 CRASHES*, not TS3 crashes? @swissMAG: You need to clarify Arma2 Crash to desktops please. TS3 is known to crash, but we have had *no* reports of ArmA2 CTD's except for your guys, with your specific modset. BIS is looking into the crashes. @Howard, @SpetS15: JayArmA2Lib has not been updated for the latest beta yet. they released 115 and 116 back to back within a few hours, and I didn't know that until after release. It works up to 115. 116 was just a server fix anyways. @secludedsfx: Can you please file a ticket on DH with the crash dump? This is an unreported issue, and just saying "it crashed" is not helpful. @TonySoft: Can you please be less brief and a little more descriptive? "It doesnt work", doesn't work. Retrans works like this: You set a retrans object with 2 frequencies. You test with 2 people, on those 2 frequencies. They have to be on *the separate channels*. So - if you have a retrans station setup with CH1 and CH3. Then you talk on CH1, it gets rebroadcasted to CH3. Same for people speaking on CH3. Its not just a simple signal boost. Can you confirm that this is the way you are using it, and it is not retransmitting? I just tested again - works fine. Example pbo HERE @Petko: See my description of how retrans works above. It works the same - its a relay between two frequencies.

Its that size on purpose. When you are looking at a 117F, your peripheral vision is not the greatest. Especially cause the thing is on your back. Retrans/Relay stations are in the works for the domi makers to put in. They are technically already coded, just they obviously don't care enough to put it in :P Please read the API wiki (and rest of the wiki) before yelling that its not there :) http://dev-heaven.net/projects/a2ts3/wiki/Class_Names_and_API Its constantly getting updating with more stuff. p.s. If you're playing with people that don't want to bother with radio signal loss (which it sounds like is your guys case, you want the coolness with none of the realism), then you can turn down the signal loss model. Noob-mode, no signal loss: [1] call acre_api_fnc_setLossModelScale; Default mode: [0] call acre_api_fnc_setLossModelScale;

the 117F goes up to 20,000mW, that should transmit to the coast from the airfield. Sorry - but don't expect us to gimp radio signal loss just for Domi :)

Sigh yah...BIS released 73115 and then 73116 back to back within a couple hours :| Will have it out today.

Updated to version 1.3.2. Supports latest beta, B73115

Sure thing - looks like we got it (mostly) solved with server-side config changes; but would still like to poke you about perf on some of it :)

Hey Protegimus - I know you hit our TS occasionally, and feel free to stop by for this but I thought I'd post it here for now unless I didn't see you soon. Currently - latest test version off of Yoma, running tests to implement @ UO. We currently have it up on our test server, and are getting severe AI stutter/jitter/jump. This includes on just static waypoint patrols and it gets worse during engagement. Tested locally via dedicated server + client, with only @CBA;@ACRE;@Zcommon, same problem occurred again. Known issue and working on it? Or have run into it/something not setup right? I assume it may have something to do with delay/timelapse within the FSM, but I could just be an idiot :)

Yes. Results with people not running ACRE are unknown. And they piss off everyone running ACRE.

I'll check it out, Rafalski. Either way - its not game breaking FYI, so it shouldn't affect anything else ACRE-related (its a separate module). Just gives the script error.