jaynus

You must be running the latest beta's for this release.

This would mean he is not actually running 64-bit TS3 like he thinks.

Many communities regularly play 100-150 players with radios, and no issues. We need actual reports and issues to be able to resolve anything or give support. "my shit don't work" is difficult for us to debug.

You'd have to use the older JayArmA2Lib. Note, though, that a good amount of stability comes out of the latest beta's as well.

It is not needed anymore. The new JayArmA2Lib uses the ArmA2 extension DLL interface.

Once the radio gets used within a vehicle, it gets added to your radio list like any other radio. This isnt happening?

This isn't because of the configs, its the models themselves. OA backpacks get attached to the back differently than weapons or any other objects. The actual models need to be rotated about 80 degrees because the model itself is centered; items on back, in game, do not sit centered. They sit at something like a 40 x 80 degree x-z tilt.

Nou and I are still hard at work on the 1.5 data system re-organization. A lot of performance and functionality extensibility will come from it. Until then, since I was gone for a year and needed to get back into the code base, a hotfix is currently coming. It is currently being tested. This is a result of "jaynus is back and needs to get back into the code", and should strictly be considered hotfix for 1.4 stable. If test's work out, we'll release later today.

boo :cool:

FYI - Its not an "issue", Its that I don't get paid to do these updates at such a fast pace like BI does to release beta's :) ---------- Post added at 04:44 PM ---------- Previous post was at 03:43 PM ---------- On that note - http://www.dev-heaven.net/projects/jayarma2lib/files Updated for 1.60 RC2

updated for 86652

Work-In-Progress Report - October, 2011 Topic: 1.4 Engine Revamp Magic Introduction Hi all. We have decided to post a general overview of what you can expect with 1.4 of ACRE. We've decided to take a major overhaul for this version, so a lot of things (internally and from a mission maker perspective) are going to change. A lot of the core engine mechanics are changing, and all for the better. We decided it was best to give a small update on where we are heading, rather than just leaving everyone hanging still. Topics of Interest Move away from TS3 reliance - Reliance on the TS3 sound engine and systems has been reduced to a minimum. We now perform all our 3D and audio calculations on our own. This basically means the only interaction we now have with TS3 is "They give us audio data, we give it back audio data" - TS3 3d position, mixing, and all the related have been removed. We now do it on our own. - All of this functionality has been written from the ground up either by hand, or utilizing XAudio2 Libraries (DirectX 3D Audio) Core Engine Transition A majority of the of processing, functionality and math has been moved away from arma2 and into what we call our "Core Engine". For ACRE, this engine lives in TS3. However, this is basically, for all intents and purposes, our own program now running and processing ACRE information. This should completely eliminate all the game lag issues which have become present sometimes during large play scenarios. This means we are doing it *outside of arma2*, in C++, on our own and with our own process management. What does this mean? It means the following got moved away and are extremely fast now: - Radio information - Signal calculations - 3D Position tracking and calculations - Network (Freq/power/etc) settings information - Player Head positions (yes, we now track head vectors) Data System Re-Evaluation Nou has also revamped our data propagation engine, to allow for smoother and easier transition between players swapping radios. This is mainly an internal change, but what it allows is for us to use information in both TS3 and A2 transparently. We are now allowed to transfer our own large amounts of information without desyncing the server. Signal Loss Revamp Nou can speak more on this below, but we are moving towards more realistic and quicker models. Audio Engine Revamp As stated above, we have written our own complete audio processing engine now, including 3D positional audio. JayArmA2Lib Redesign TBA :) Technical Overview TBA :)

What sickboy was referencing was the fact in Windows 7/Vista, you can adjust different applications volumes in the mixer. ACRE also does not mess with the main volumes in TS3, ONLY the soundpack volume. Why? Because we play wave files for the squawk sounds and have to make sure they are playing - otherwise most people would not hear the squawks. Thanks to TS3, these can only be covered under the soundpack volume so we have to ensure that is up to hear it. Also, we only adjust it while squawks are playing. It gets turned back down after a squawk is done. This is all being changed in the re-write, since we are basically ditching the TS3 sound engine (mostly, they just "give us" audio streams) and doing all the mixing and positional by yourselves.

Updated again for 85598 Will be live on six shortly.

updated for 85510 http://www.dev-heaven.net/projects/jayarma2lib/files Live and available via SixUpdater Network.

Sigh. Which just got added :(

It includes no fixes for this: http://dev-heaven.net/issues/25222 Which means jayarma2lib wouldn't even run anyways (it uses CBA)

WIP Report Link http://forums.bistudio.com/showthread.php?p=2033885

Updated for 85101. F U ALL :)

Updated for beta 84984. Auto-update pushed live on SU Network

Sickboy hit the nail on the head for my intended behavior. This was an extension for mainly large-player missions and unit caching (read: > 60 player COOP missions). This allowed us an extra extension on disabling AI; this also allowed us to create custom ambient civilians. The tests/initial implementations for these are internally (@ UO) known as jcache and jciv respectively. They results were: Perform the following to actually allow for > 700 AI on the map, with 30 players, with minimal lag. { _unit = _x; _unit disableAI "TARGET"; _unit disableAI "AUTOTARGET"; _unit disableAI "MOVE"; _unit disableAI "ANIM"; _unit disableAI "FSM"; _unit enableSimulation false; _unit allowDammage false; } foreach _groupUnits; This allowed me to completely 100% remove all performance and network oriented processing for a given unit / group of units. The end result was: 1. Leave only the leader of a group on the map 2. Perform the above 3. Move them to -1000,-1000,-1000 on the map Additionally - for the sake of a "Not broken ambient civilians" module I was working on, this allowed me to disable the massive script overhead of the default AI behavior even for civilian units in concern to the danger FSM. This allowed me to strictly perform the processing myself via SQF (using PFH/triggers and my own queuing mechanism for processing). This meant much more basic "ambient" civilians, at a much lower server performance cost for count. That about sums up what the initial intent behind that feature request was, and my results with it.

Update is also pushed to auto-updated and live on SixUpdater Official Network.

I was gone on vacation. Updated for beta 84628 http://www.dev-heaven.net/projects/jayarma2lib/files

Its supported and works. Also fixes the 5.1/7.1 bugs.

PFH is what makes half of arma2 and ACE work with > 30 players.