Jump to content
wolffy.au

ALiVE - Advanced Light Infantry Virtual Environment

Recommended Posts

Not supported at this time... it is on the radar for future versions.

Thanks for the quick reply, Savage.

The FAQ touches on this: http://www.alivemod.com/#FAQ

I have already read this, but the information on it is misleading. ALIVE is technically released and HC support is not included at this time, which to me contradicts the text: "However, we will provide an option in Profile System to spawn on HC in the first release!".

Since ALIVE has been released (even if it is WiP) and I do not see any HC support included, I asked the question in order to clarify.

So, perhaps I am misunderstanding the answer to that FAQ, but I believe the answer should be changed slightly to say that HC support will be included in a future release rather than the "first" release.

Share this post


Link to post
Share on other sites

Hi,

first of all I would like to thank you for your wonderful job that totally changed my way to play Arma3!

In second part I would like to ask you if there is a way to integrate the UPSMON script (http://forums.bistudio.com/showthread.php?170803-UPSMON-Updated-to-ArmaIII) onto the profiled units in our missions?

I think the AI behaviour is interesting in this script because of smokes from AI, suppression,etc...

Or maybe is there already the same functions integrated directly into Alive?

Third question (and the last) :

Is there a possibility to integrate a sort of "dev version" of Alive for the perf server released by Dwarden the 31th (http://forums.bistudio.com/showthread.php?169944-Arma-3-STABLE-server-1-10-quot-performance-binary-quot-feedback/page13)? (of course if it is not a devil job to do :y:)

I've tried to test the last patch of Alive but modules seems to not synchronise correctly.

regards,

sebj

Share this post


Link to post
Share on other sites

In second part I would like to ask you if there is a way to integrate the UPSMON script (http://forums.bistudio.com/showthread.php?170803-UPSMON-Updated-to-ArmaIII) onto the profiled units in our missions?

Third question (and the last) :

Is there a possibility to integrate a sort of "dev version" of Alive for the perf server released by Dwarden the 31th (http://forums.bistudio.com/showthread.php?169944-Arma-3-STABLE-server-1-10-quot-performance-binary-quot-feedback/page13)? (of course if it is not a devil job to do :y:)

I've tried to test the last patch of Alive but modules seems to not synchronise correctly.

Currently no there is no way to integrate UPSMON script into ALiVE as profiling the unit breaks anything in their init field. You can try using bCombat or ASR_AI to get more advanced AI behaviour.

As for your other question this is the first I've heard of this (ALiVE not working with performance binary).. can anyone else confirm this?

Share this post


Link to post
Share on other sites

As for your other question this is the first I've heard of this (ALiVE not working with performance binary).. can anyone else confirm this?

I can confirm that ALiVE works fine with the latest performance binary.

Share this post


Link to post
Share on other sites

Shadow, we will update FAQs on ALiVEmod.com - obv. that info got lost, thanks. Tupolov stated it in the thread already (thread search option), HC support simply wasnt ready. We have planned to do it on first release, but it was more work than expected (it wasnt as easy as to switch everything serverside to the HC as we wanted to for initial release). But we will implement when we get time.

sebj, theres a new perf binary already that also matches the latest stable build version number!

Share this post


Link to post
Share on other sites

Just wanted to share some of my experiences.

I had an Altis mission with a single large TOAR representing an occupying force and a single smaller TOAR for invaders. I had CQB unsynced but whitelisted/blacklisted, occupying mil/civ synced correctly, and invader civ synced correctly. All worked fine until after a few tweaks (exactly which I cannot recall), CQB stopped respecting the whitelist/blacklist and would populate the entire map. I fiddled with it for some time, got CQB tamed and then invader civ would stop respecting whitelist and would populate the entire map; behavior overall was really inconsistent. It's worth noting the invading TOAR was inside the occupying TOAR initially but no TOAR placement seemed to work correctly (removing the overlap, changing the shape, etc).

I set up a more simplified mission on Stratis with similar placements to ensure something of an apples to apples comparison. Occupying forces have an unsynced CQB, properly synced mil/civ (no TOAR so using entire map), with a single TOAR for invaders (mil, properly synced). All enemy placements have the invading TOAR in their blacklist. First load, not all occupying placements respected the blacklist and populated in the invaders' area, and I'm pretty sure a couple times the invaders populated the entire map.

Finally I figured out what seems to be the best procedure for ensuring consistent behavior regarding TOAR placement, this fixed both my Stratis and Altis missions. It seems you have to create a TOAR for every placement. In other words, on Stratis when I created 3 exact and overlapping TOARS and put each different TOAR in each placement the blacklists/whitelist finally worked for all placements. The invaders are using the same TOAR as one of the blacklists so it seems separation by whitelist/blacklist or by OPCOM is ok. Same thing on Altis, when I setup a separate but identical TOAR for each placement everything behaved as expected.

On a different note, if you want a more densely populated base you can use an unsynced CQB module (blacklist/whitelist TOARs if necessary). Using the same percentage/denseness settings, a whitelisted/full map CQB covering the same TOAR as a military placement will populate more heavily unsynced (verified multiple times via debug, more Xs). Obviously you can adjust your mil placement population size but this is no guarantee, even without OPCOM you still get patrols that may use those units and CQB seems to use more of the available buildings in any case. I have not tested with civ placements but I'm guessing the effect is similar.

tl;dr:

  • For consistent TOAR behavior (whitelist/blacklist) use separate TOAR markers for each placement.
  • For more densely populated bases (and likely civ objectives as well), you can use an unsynced CQB module (whitelist/blacklist as needed). Nice because it isn't limited by placement population size.

Question: Has anyone managed to get UPSMON working with Alive? I primarily use Alive for coop missions with my buddies so bCombat won't work (unless there's an MP version I'm not aware of). I have installed the UPSMON script and based on my admittedly limited playtesting so far I'm not sure it works. I do understand it wouldn't do anything with profiled units, only those spawned in player space, that's fine. I'll mess with it some more later, I would just like verification it's doable on the off-chance someone else already got it going. On a related note VTS Duck Hunt works great.

Edited by landis
Question answered just before I posted!

Share this post


Link to post
Share on other sites

  • For consistent TOAR behavior (whitelist/blacklist) use separate TOAR markers for each placement.
  • For more densely populated bases (and likely civ objectives as well), you can use an unsynced CQB module (whitelist/blacklist as needed). Nice because it isn't limited by placement population size.

For your first point yes I have noticed this recently as well... it seems that if you have the same marker set for example in a CQB and a placement module, one of the modules "uses up" the marker and prevents the other from using it (perhaps it gets deleted or renamed?). The easy fix as you mentioned is to use different markers for each module.

edit: were you in SP editor when you noticed this?

Edited by SavageCDN

Share this post


Link to post
Share on other sites
Just wanted to share some of my experiences.

I had an Altis mission with a single large TOAR representing an occupying force and a single smaller TOAR for invaders. I had CQB unsynced but whitelisted/blacklisted, occupying mil/civ synced correctly, and invader civ synced correctly. All worked fine until after a few tweaks (exactly which I cannot recall), CQB stopped respecting the whitelist/blacklist and would populate the entire map. I fiddled with it for some time, got CQB tamed and then invader civ would stop respecting whitelist and would populate the entire map; behavior overall was really inconsistent. It's worth noting the invading TOAR was inside the occupying TOAR initially but no TOAR placement seemed to work correctly (removing the overlap, changing the shape, etc).

I set up a more simplified mission on Stratis with similar placements to ensure something of an apples to apples comparison. Occupying forces have an unsynced CQB, properly synced mil/civ (no TOAR so using entire map), with a single TOAR for invaders (mil, properly synced). All enemy placements have the invading TOAR in their blacklist. First load, not all occupying placements respected the blacklist and populated in the invaders' area, and I'm pretty sure a couple times the invaders populated the entire map.

Finally I figured out what seems to be the best procedure for ensuring consistent behavior regarding TOAR placement, this fixed both my Stratis and Altis missions. It seems you have to create a TOAR for every placement. In other words, on Stratis when I created 3 exact and overlapping TOARS and put each different TOAR in each placement the blacklists/whitelist finally worked for all placements. The invaders are using the same TOAR as one of the blacklists so it seems separation by whitelist/blacklist or by OPCOM is ok. Same thing on Altis, when I setup a separate but identical TOAR for each placement everything behaved as expected.

On a different note, if you want a more densely populated base you can use an unsynced CQB module (blacklist/whitelist TOARs if necessary). Using the same percentage/denseness settings, a whitelisted/full map CQB covering the same TOAR as a military placement will populate more heavily unsynced (verified multiple times via debug, more Xs). Obviously you can adjust your mil placement population size but this is no guarantee, even without OPCOM you still get patrols that may use those units and CQB seems to use more of the available buildings in any case. I have not tested with civ placements but I'm guessing the effect is similar.

tl;dr:

  • For consistent TOAR behavior (whitelist/blacklist) use separate TOAR markers for each placement.
  • For more densely populated bases (and likely civ objectives as well), you can use an unsynced CQB module (whitelist/blacklist as needed). Nice because it isn't limited by placement population size.

Question: Has anyone managed to get UPSMON working with Alive? I primarily use Alive for coop missions with my buddies so bCombat won't work (unless there's an MP version I'm not aware of). I have installed the UPSMON script and based on my admittedly limited playtesting so far I'm not sure it works. I do understand it wouldn't do anything with profiled units, only those spawned in player space, that's fine. I'll mess with it some more later, I would just like verification it's doable on the off-chance someone else already got it going. On a related note VTS Duck Hunt works great.

Hi Landis!

Welcome! I saw this is your first post, so thanks for taking time to register and that share your expierences!

I would like to see the mission with the inconsistent taor behaviours - glad you managed to sort it - but I have not seen such a behaviour yet and would like to check if its replicable somehow. Actually on the CIV/MIL MP modules there is no whitelist (thats only on CQB), but several TAOR markers and blacklist markers in a row are working fine and actually how it should be done (like for TAORs: YourTAOR_1,YourTAOR_2,YourTAOR_3 and for blacklists: YourBL_1,YourBL_2,YourBL3 etc). If you use several MP modules with one TAOR each it will work but will slow down the INIT time as there is another instance of MIL/CIV MP running. The CQB blacklists/whitelists are completely independent of the MIL/CIV MP ones and should in no way affect CQB module!

I really agree that unsyncing CQB will give you a more dense battlefield, just keep an eye on performance, so not 300 AI are transferred to view at the same time.

If you could post that mission to our tracker (http://dev.withSix.com/projects/alive/issues) i would be really really happy, and if its only to get your placements sorted and optimize init time!

--------

Update: Savage just mentioned today that he got something similar if one blacklist marker is used by both, CQB and MIL MP. I will look into, you might be on something there :)

Cheers

Highhead

Edited by highhead

Share this post


Link to post
Share on other sites

Thanks for your fast answers.

sebj, theres a new perf binary already that also matches the latest stable build version number!

Sorry but just to be sure :

is Alive: @alive_0-5-6-1401291 matching with perf server : 1.10.114486 ?

If it's the case I had some trouble to get profiled units spawning... When I came back on stable everything was fine.

If version are matching I think I'll try again with a new mission from crash.

Thank you for your confirmation,

Share this post


Link to post
Share on other sites
For your first point yes I have noticed this recently as well... it seems that if you have the same marker set for example in a CQB and a placement module, one of the modules "uses up" the marker and prevents the other from using it (perhaps it gets deleted or renamed?). The easy fix as you mentioned is to use different markers for each module.

edit: were you in SP editor when you noticed this?

Both SP and MP (preview from editor in SP, preview from 'Edit' option in MP, and also normally launched in MP).

Hi Landis!

Welcome! I saw this is your first post, so thanks for taking time to register and that share your expierences!

I would like to see the mission with the inconsistent taor behaviours - glad you managed to sort it - but I have not seen such a behaviour yet and would like to check if its replicable somehow. Actually on the CIV/MIL MP modules there is no whitelist (thats only on CQB), but several TAOR markers and blacklist markers in a row are working fine and actually how it should be done (like for TAORs: YourTAOR_1,YourTAOR_2,YourTAOR_3 and for blacklists: YourBL_1,YourBL_2,YourBL3 etc). If you use several MP modules with one TAOR each it will work but will slow down the INIT time as there is another instance of MIL/CIV MP running. The CQB blacklists/whitelists are completely independent of the MIL/CIV MP ones and should in no way affect CQB module!

I really agree that unsyncing CQB will give you a more dense battlefield, just keep an eye on performance, so not 300 AI are transferred to view at the same time.

If you could post that mission to our tracker (http://dev.withSix.com/projects/alive/issues) i would be really really happy, and if its only to get your placements sorted and optimize init time!

--------

Update: Savage just mentioned today that he got something similar if one blacklist marker is used by both, CQB and MIL MP. I will look into, you might be on something there :)

Cheers

Highhead

Right, technically it's not a 'whitelist', I am referring to the normal TOAR field. I have only one placement module per side (and per type) as I understand that is best practice so to clarify the initial mission had one each of civ/mil/CQB on the occupying side and one civ on the invading side (as that matched the objective in the area I wanted). Since I got the mission working and I've already experimented with init times and got them to where I'm comfortable I'm good there.

I have only the working mission now but when I have some time I'll see about creating one that replicates the behavior. I can say that on Stratis I setup a map-wide occupying force with one each of civ/mil/CQB. CQB I left unsynced, civ/mil were synced to the occupying OPCOM. I then setup a single mil synced to an invading OPCOM. I synced all placements across sides so the OPCOMs would know their objectives. I placed a single TOAR marker over the Kamino area, set the invading mil to it, and added it to all occupying blacklists. Initial load showed invading force in the TOAR as expected but also some occupying forces, as has been said if I had to guess it looks like one of the placements blacklists correctly and the others don't.

Share this post


Link to post
Share on other sites

@landis - seems it indeed was a bug only affecting SP and MP (host) - HH has already fixed it and will be in the next release. For the time being use different markers.

Share this post


Link to post
Share on other sites
Is this immediatly after loading into a game?Make sure that helo is not being profiled by the Alive profile module.

If thats the case check profile module and select profile all units except synced ones" and sync your helo to the profile,it wont dissapear anymore.

No, it happens at different times. The last time it happened we were half an hour into the game. I'll try what you recommended though. I think that might work. Thanks!

Share this post


Link to post
Share on other sites
@landis - seems it indeed was a bug only affecting SP and MP (host) - HH has already fixed it and will be in the next release. For the time being use different markers.

Oh, nice! Hey, I contributed!

On top of all the other positive comments I'll add that we've been enjoying it immensely and it solved some issues I was encountering with what I wanted out of MCC. For us, MCC with Alive is pretty much the creme de la creme. At the very least, being able to populate all bases on the map in a way that's relatively performant is worth it.

Share this post


Link to post
Share on other sites
Thanks for your fast answers.

Sorry but just to be sure :

is Alive: @alive_0-5-6-1401291 matching with perf server : 1.10.114486 ?

If it's the case I had some trouble to get profiled units spawning... When I came back on stable everything was fine.

If version are matching I think I'll try again with a new mission from crash.

Thank you for your confirmation,

Hi,

- 1.10.114486 on my perf binary.

- landis, thanks for your post, it was really a bug in SP an HOST (but was working fine on dedi). Fixed it, and workaround above!

Btw. I really suggest you run ALiVE on a (local) dedicated server instead of Host. It just performs a million times better.

enjoy

Share this post


Link to post
Share on other sites
1 - I don't think this is possible. You can put down a gamelogic to create an objective for OPCOM but I don't know any way to force OPCOM to send all units to that objective.

2 - Not sure about this one either.. at least I've never tried this myself. I'd guess this is not possible ATM but let's see what a dev says.

...I didn't get a dev reply :pet5:

Share this post


Link to post
Share on other sites

I would REALLY like to enable task force radio as the device needed for CAS. BUT, instead of everyone on the server having access to CAS I would like to limit it to just those with long range radios, so a squad that wants access to CAS must have at least one RTO with them. The class name for the blufor LR is "tf_rt1523g" and all players start the mission with one on their backs by default but even though I changed the Support module from the default "laserdesignator" to "tf_rt1523g" I still don't get the CAS menu...

Can anyone please help me with this? Thanks in advance.

Share this post


Link to post
Share on other sites

@Oktyabr

Task Force Radio and ACRE have a complex scripted system for radios. From memory, the basic radios are a kind of proxy that get replaced by script. Every single radio in a mission has it's own number, so this means that there are actually about 1000 classes of each radio type. However, they have some functions that check if you have a suitable radio type. Here is how I checked for radio presence in my artillery addon:

_haveRadio = false;

_haveSW = false;

_haveLR = false;

_haveDD = false;

_haveSW = call haveSWRadio;

_haveLR = call haveLRRadio;

_haveDD = call haveDDRadio;

if (_haveSW) then {_haveRadio = true};

if (_haveLR) then {_haveRadio = true};

if (_haveDD) then {_haveRadio = true};

if (_haveRadio) then {_radio = "TFAR"};

if ((dtaDebug) AND (_haveRadio)) then {player globalChat "TFAR radio used."};

haveSWRadio, haveLRRadio and haveDDRadio are all TFAR functions. Not sure how you would incorporate this into ALIVE though, might be something for the devs to consider. I also have the code for ACRE if anyone needs it.

Share this post


Link to post
Share on other sites

EDIT: Double post

---------- Post added at 10:40 PM ---------- Previous post was at 10:36 PM ----------

@Oktyabr

Task Force Radio and ACRE have a complex scripted system for radios. From memory, the basic radios are a kind of proxy that get replaced by script. Every single radio in a mission has it's own number, so this means that there are actually about 1000 classes of each radio type. However, they have some functions that check if you have a suitable radio type. Here is how I checked for radio presence in my artillery addon:

_haveRadio = false;

_haveSW = false;

_haveLR = false;

_haveDD = false;

_haveSW = call haveSWRadio;

_haveLR = call haveLRRadio;

_haveDD = call haveDDRadio;

if (_haveSW) then {_haveRadio = true};

if (_haveLR) then {_haveRadio = true};

if (_haveDD) then {_haveRadio = true};

if (_haveRadio) then {_radio = "TFAR"};

if ((dtaDebug) AND (_haveRadio)) then {player globalChat "TFAR radio used."};

haveSWRadio, haveLRRadio and haveDDRadio are all TFAR functions. Not sure how you would incorporate this into ALIVE though, might be something for the devs to consider. I also have the code for ACRE if anyone needs it.

Thanks Drongo!

I had read in the wiki, and elsewhere here in this thread that ACRE and TFAR could both be used in such a way... ALIVE treats *something* (I still haven't found out what, exactly) as a suitable replacement for the default LaserDesignator. But you have it right, all I was hoping to accomplish is that ALiVE might be easily configured, by substituting the correct class name, to treat a LR radio as such a device, bringing up the CAS option when the admin action key is pressed.

Share this post


Link to post
Share on other sites
EDIT: Double post

---------- Post added at 10:40 PM ---------- Previous post was at 10:36 PM ----------

Thanks Drongo!

I had read in the wiki, and elsewhere here in this thread that ACRE and TFAR could both be used in such a way... ALIVE treats *something* (I still haven't found out what, exactly) as a suitable replacement for the default LaserDesignator. But you have it right, all I was hoping to accomplish is that ALiVE might be easily configured, by substituting the correct class name, to treat a LR radio as such a device, bringing up the CAS option when the admin action key is pressed.

Yes you can use the class name for an ACRE or TFR Radio as access to CS. Any particular reason for spamming the Skype channel and the a forum with the same questions?

Edited by Gunny1979

Share this post


Link to post
Share on other sites
Hi,

- 1.10.114486 on my perf binary.

- landis, thanks for your post, it was really a bug in SP an HOST (but was working fine on dedi). Fixed it, and workaround above!

Btw. I really suggest you run ALiVE on a (local) dedicated server instead of Host. It just performs a million times better.

enjoy

Hi highhead,

Thanks, yes I confirm I'm only running version on dedicated server.

localhost is not working with a lot of scripts.

I didn't had time to test again but I'll give another try this weekend.

thanks for your support,

bye

Share this post


Link to post
Share on other sites

Sebj, the perf binary has a different build number as latest hotfix, though the indexes should be the same. Im looking into this!

Share this post


Link to post
Share on other sites
Thanks highhead! Good to know. Looks like I'm always looking for a feature that isn't out yet ;)

Dude, thats old. It has been fixed in the last hotfix.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×