Naked units after transfer to HC #48
Comments
|
I never experienced this issue, and sleep is not something we will use. Delaying 10s is also not wanted, I'd say this is up to BI to fix. And please use Gist or Pastebin for the huge list of settings, as it is described in the issue template. |
|
It ultimately is, but ACEX is kinda useless now... I tried to "force" our group mission makers (curators) to use HC but there are so much problems with zeus and HC.
It's just a irreplicable mess you cannot fix as a modset/server admin. So is there a scope for ACEX to make HC really usefull and usable with zeus ? |
We can't do anything about either of those, it's completely a Zeus problem.
Well that's simply not true. We use it just fine and it works perfectly, never had a single issue. |
|
Well it sure is usefull, but not really if you don't want to make every curators job much more tedious. (or if not using zeus at all) Is it really meant to use with zeus ? |
|
Sure, but Zeus has its own problems we simply can't fix. You might want to take a look at Mars in the future as a Zeus replacement. I have put this issue on Backlog for now, as it is not something I'd like to see implemented due to rather high delays necessary, but if someone wants to, feel free to, can always make it a setting. |
|
added github spoiler text |
|
Our group has been running Zeus alongside HCs for over a year now and ACEX is the best implementation we've used. In my experience, increasing the time delay before a unit is transferred reduces the frequency with which the nakedness bug occurs (ACEX has a setting for adjusting the delay - ours is at 45 seconds). A delay also gives time for Zeus to make precise adjustments (move, rotate) before the transfer occurs. We eventually developed a Zeus module for setting the "no HC transfer" flag on units, which is useful when precise control over a particular group is needed. |
|
@Fourjays I'd be interested in that module. |
|
Same here
…On Thu, Nov 24, 2016, 23:25 jonpas ***@***.***> wrote:
@Fourjays <https://github.com/Fourjays> I'd be interested in that module.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhbVXwDuV90rmQAyeT1WfH1Uj5wc-ks5rBg7HgaJpZM4K4jxE>
.
|
|
@jonpas @Arcanum417 I've not publicly released it in compiled form (one day maybe), but I keep the code open source under one of the Arma Community licenses so others can learn from it. It is part of a set of utility tools I developed for Zeus/Eden: This file is the main part of the HC transfer prevention (looks complicated, but all it does is set the blacklist variable that ACEX looks for before transferring a unit - you could just as easily set it via a unit's init line if pre-placed in the editor): |
|
So @jonpas please implement this in acex? It looks like it would be quite
desirable.
…On Fri, Nov 25, 2016, 13:40 Fourjays ***@***.***> wrote:
@jonpas <https://github.com/jonpas> @Arcanum417
<https://github.com/Arcanum417> I've not publicly released it in compiled
form (one day maybe), but I keep the code open source under one of the Arma
Community licenses so others can learn from it. It is part of a set of
utility tools I developed for Zeus/Eden:
https://gitlab.com/blackwatchint/bwi_addons/tree/develop/addons/bwi_utils
This file is the main part of the HC transfer prevention (looks
complicated, but all it does is set the blacklist variable that ACEX looks
for before transferring a unit - you could just as easily set it via a
unit's init line if pre-placed in the editor):
https://gitlab.com/blackwatchint/bwi_addons/blob/develop/addons/bwi_utils/modules/fn_preventHCTransfer.sqf
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhYl41Nn0l9NiYYeLj9wVWODcV997ks5rBtdagaJpZM4K4jxE>
.
|
|
I can see a few approaches now.
|
|
This issue is actually related to bad documentation. If you connect headless client using the IP address of the server you'll get the lag because it's going outside of the LAN. You have to use the local ip, as they say use the 127.0.0.1, yet they fail to mention you MUST also provide the port of the server. So it's actually 127.0.0.1:2302 bam. We've since had no issues with naked AI. |
|
Can anyone with the issue confirm @PhillyJoker 's solution works? |
|
I think @PhillyJoker's solution would only prevent the nakedness occuring on units placed in the editor that get transferred to HC. Our HCs have always connected to 127.0.0.1:2302 and the issue still occurs on Zeus->HC transfers, but not server->HC transfers. With the Zeus->HC transfers, the frequency with which it occurs seems to correlate to the connection quality of the Zeus. Increasing the delay between spawn and transfer does help reduce the number of occurences, but still some slip through. My assumption has always been that it is simply a case of the HC client not getting the full copy of the unit's inventory by the time the unit is transferred, causing the HC's version to become "canon". We've had the same issue with other HC scripts as well, so I don't think it is ACEX specific. |
|
Ah, Zeus, awesome as always... |
|
I guess I should have added that it erased 99% of the occurrences. We can still force it to happen by spawning 300 + AI in a minute, but it is extremely rare. I think at this point we're just hitting the limits of our hardware and BIS software. I agree this is not an ace issue. Theorizing for a second, it might be because BIS has no throttle to the amount of data it's trying to pass, so like others mentioned, it's missing gear and going default. |
|
We have experienced this issue yesterday, however the units spawned only turned naked for the Zeus client that spawned them. Everyone else saw them normally. By reports it also happens when transferring from Zeus client to server. I am closing this issue as there isn't much we can do, all we can do is bandaid and that's already possible by increasing the delay. However, since majority apparently does not have the issue I will not be changing the default values. Fingers crossed this gets fixed one day. 🤞 |
|
@jonpas A possible solution could be saving the gear of the units before transferring them to the HC. |
|
Has someone meanwhile found a workaround for this problem? Also sometimes the AI does not react to Zeus commands after the transfer to the HC, but this could be another problem. |
|
Latter is locality issue, some Zeus modules only properly work on local units. |
|
Saving gear could work, but could also be destructive if someone relies on certain gear or something, would keep it default disabled maybe. I have no clue what the cause would be, never really experienced the issue myself. |
|
Just an idea... |
|
@Meiestrix |
|
Hm okay, than we need to add the default items back to the unite, |
|
The command This is the current workaround we are using for our transfer ownership module: |
|
Thank you. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Any plans to include the workaround in the acex itself ?
…On Sat, Nov 10, 2018, 12:33 stale[bot] ***@***.***> wrote:
This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs. Thank you
for your contributions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhZ-A2L8OSQNDKVZUUnQ_-MoIaaBkks5utrlxgaJpZM4K4jxE>
.
|
|
What is the workaround? It looks like there is a sync issue, wonder if we can fix it somehow else by making the HC aware of the loadouts first. |
|
Well, yeah the workaround fifth comment above me. Also sure, whatever gets
it fixed.
…On Sat, 10 Nov 2018 at 12:55 jonpas ***@***.***> wrote:
What is the workaround? get/setUnitLoadout?
It looks like there is a sync issue, wonder if we can fix it somehow else
by making the HC aware of the loadouts first.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhQ2e0MLrqRSPdBbbBgvboQ2br8ifks5utr61gaJpZM4K4jxE>
.
|
|
I will take a look at some point, can't promise any time frame. If anyone wants to add and test a fix/workaround, that'd be great. |
|
Ok, so I recommend something in this form (modified from Arma 3 Discord, posted by Schwaggot) which just sets loadout to config's default: ["CAManBase", "Local", {
params ["_entity", "_local"];
if (_local && {uniform _entity == ""}) then {
_entity setUnitLoadout (getUnitLoadout (typeOf _entity));
};
}] call CBA_fnc_addClassEventHandler;But rework it so we have a setting that enables this functionality (because of possible network performance penalty). Functionality is saving gear of each unit moved to HC, transmitting that data to the HC ( Final form should look like this: // Somewhere in transfer code
UNIT setVariable [QGVAR(loadout), getUnitLoadout UNIT, true];
// XEH code
["CAManBase", "Local", {
params ["_entity", "_local"];
// Check something more or is that enough?
// Definitely check something though, `setUnitLoadout` is not a light command used en masse
if (_local && {uniform _entity == ""}) then {
// Set old loadout, if unavailable reset to config default (still better than naked)
_entity setUnitLoadout (_entity getVariable [QGVAR(loadout), typeOf _entity]);
};
}] call CBA_fnc_addClassEventHandler;As said, setting because some communities are not experiencing this at all, and it would only cause unnecessary overhead. Thoughts? |
|
Having unit's loadouts reset themselves to their configs would ruin my group's scripted loadouts. It's strongly prefer something like cache getUnitLoadout |
|
That sounds more flexible.
…On Sat, Dec 22, 2018, 03:50 Drofseh ***@***.***> wrote:
Having unit's loadouts reset themselves to their configs would ruin my
group's scripted loadouts.
It's strongly prefer something like
cache getUnitLoadout
wait until transfer
getUnitLoadout , check if == cached loadout
if true then do nothing
if false then setUnitLoadout cached loadout
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhZg9NeutMjr5rsuSV3m-TVim8d_aks5u7Z34gaJpZM4K4jxE>
.
|
|
@Drofseh that's solved by the "final form" |
|
I now actually looked at the code and it does seem to save the load out and
load it after, if for some reason it is not found set config default.
…On Sat, Dec 22, 2018, 07:49 Cuel ***@***.***> wrote:
@Drofseh <https://github.com/Drofseh> that's solved by the "final form"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhbKSOwI0aO8bozcvD5ysXmK5rFuDks5u7dX4gaJpZM4K4jxE>
.
|
|
derp, that comment didn't expand properly on my phone. |
|
Lol, I love how quickly you guys panicked after 1 misread. XD |
|
We all know how frustraing it is to read that your issue is getting
resolved after a few years, but the fix will break your things, I can
relate here ;)
…On Sat, 22 Dec 2018 at 12:33 jonpas ***@***.***> wrote:
Lol, I love how quickly you guys panicked after 1 misread. XD
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGAFhYHO8C_15lMaPXbP7qRYaU261A_0ks5u7hh4gaJpZM4K4jxE>
.
|
|
How intensive on network resources or performance would the initial saving of the loadout to a variable be? I ask as simply resetting to the config default would be perfectly fine for our needs. All of our AI units are configured as addons, so saving loadouts to a variable would be a pointless waste of valuable resources. Could this behaviour be a secondary option or even a per-unit option (e.g. Preserve Customized Loadouts)? You could also just have the "no uniform and reset to config default" check as standard behaviour, with only the more intensive step of "saving the variable and reading it back" as a configurable option. |
|
Not that big of a deal, although loadout arrays can get pretty big. But as you said, still pointless in your case, I'll add an option to save that (Disabled, Config Loadout, Save Loadout). |
|
Awesome, thanks @jonpas. |
Arma 3 Version:
stable 1.64.138762(stable / rc / dev)CBA Version:
3.1.2.161105(stable / dev + commit hash)ACE3 Version:
3.8.1(stable / dev + commit hash)ACEX Version:
3.1.1(stable / dev + commit hash)Mods:
@CBA_A3@ace@acexDescription:
Some units loose their clothes on transfer to HC and drivers and or crew tend to disembark.
There should be a workaround for this.
https://forums.bistudio.com/topic/189818-units-becomes-naked-driver-jumps-out-on-ownership-change/
Steps to reproduce:
Where did the issue occur?
Placed Modules:
The text was updated successfully, but these errors were encountered: