-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds Suitcase Device module #94
base: develop
Are you sure you want to change the base?
Conversation
Will look through it soon. Just to confirm before I do. Do you think it works in MP between clients that do not have the mod loaded? (The server would not have this mod loaded as a requirement, as its clientside). You can let me know if you want to test it at some point and we'll get someone to restart the server without whitelist so you can test it. |
Believe so; but I'd like to test to be sure.
The texture just uses
That'd be good - particularly if someone can join without CZA or CEW loaded |
True, EWAR requires everyone to load it. So that should be a fair assumption. Not sure if you have the module only loaded if EWAR is loaded too? |
The rest of the module should work fine - the EWAR dependency is only checked to play a soundfile when the device is disarmed. Crows-Zeus-Additions/addons/misc/functions/fnc_suitcaseNukeZeus.sqf Lines 172 to 178 in a829032
(Now I look at it, that might need to be |
|
||
|
||
// Timer code | ||
// TODO: move to server to avoid problems if zeus crashes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly can't assume server would have this loaded as clientside only. So no real way to offload custom functions easily. Only option would remoteExec a spawn, but unsure how it transfers the code in the spawn.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, remoteExec was the approach I was considering, but that brings its own set of issues. Probably best to leave it on the zeus's machine; but worth testing exactly what happens if the zeus leaves/disconnects (presumably the code just stops running and the device becomes inert - but it might be nice if there was a way of maintaining it or cleaning it up!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about an EH for if/when the object changes locality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about an EH for if/when the object changes locality?
on which client would you register said EH? It won't fire on the Zeus' machine if already left ;-)
Hmm, does ZEN or CBA not have a event you can call that spawns or executes code? Might be able to piggy-back on that to send code to run on server. Like the execute_code module and sending the code as string? Not pretty, but this mod require CBA and ZEN loaded on server, so it should be available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on which client would you register said EH? It won't fire on the Zeus' machine if already left ;-)
If registered on all machines, it'll only fire on the one it was transferred from (except they've left), and whichever one it moves to (which could in theory take over the timer/activation)
I'm not sure its a good idea...
Hmm, does ZEN or CBA not have a event you can call that spawns or executes code?
Maybe; the reason not to do a straight-up remoteExec
is because some servers/clients will block use of call
with arbitrary code, and I'd be surprised if CBA let you get around that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe; the reason not to do a straight-up
remoteExec
is because some servers/clients will block use ofcall
with arbitrary code, and I'd be surprised if CBA let you get around that
Pretty sure CBA gets around that, as you would send a CBA_EVENT which is received by a CBA_LISTENER on the other side. So its not a remoteExec. In general I believe I have seen places with disallowed RemoteExec work with CBA events instead.
Although not completely sure about the underlying tech used for the actual communication.
"Defuse Device", | ||
"\a3\ui_f_oldman\data\IGUI\Cfg\holdactions\repair_ca.paa", | ||
"\a3\ui_f_oldman\data\IGUI\Cfg\holdactions\repair_ca.paa", | ||
format ["(_this distance _target < 3) and (alive _target) and _target getVariable [""crowsza_misc_suitcaseNuke_isArmed"", false]%1", _condition], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please use QGVAR(suitcaseNuke_isArmed)
as that will automatically add the prefixes and put it in quotes. I think you can even do:
QUOTE((_this distance _target < 3) and (alive _target) and _target getVariable [QGVAR(crowsza_misc_suitcaseNuke_isArmed), false]%1)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran into an issue doing that (I think it may have been in an earlier PR) where using setVariable inside a QUOTE caused some odd behaviour when it hit the comma; I'll double check on that and see if I can clean this up!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so:
QUOTE((_this distance _target < 3) and (alive _target) and _target getVariable [QQGVAR(suitcaseNuke_isArmed), false])
fails to be processed - the QUOTE(...)
gets replaced with an empty string.
QUOTE((_this distance _target < 3) and (alive _target) and (_target getVariable [QQGVAR(suitcaseNuke_isArmed), false]))
fails as well - the ,
before false
gets removed from the processed string
QUOTE((_this distance _target < 3) and (alive _target) and _target getVariable [QQGVAR(suitcaseNuke_isArmed)])
gets processed just fine, but I'd rather be explicit about what the default behaviour is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...but doing #define COMMA ,
and then
QUOTE((_this distance _target < 3) and (alive _target) and (_target getVariable [QQGVAR(suitcaseNuke_isArmed) COMMA false]))
sorts it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be needed to use ARR macro for the array?
https://discord.com/channels/976165959041679380/1039189045655392389/1204464769373835295 (Ace Discord)
But I also saw this lately. Is that the same thing you are running into?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yeah, looks like exactly that issue - spooky. ARR might fix it, will try
|
||
private _controls = [ | ||
// TODO: size of slider makes it very difficult to be precise - replace with (parsed) text? | ||
["SLIDER", ["Timer", "How long until the device activates in MM:SS"], [1, 30*60, 5*60, {[_this, "MM:SS"] call BIS_fnc_secondsToString}]], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would multiplying values with a factor 10 or 100 and then multiply with 0.1 or 0.01 when you get the input, make it better?
Or set it so minimum step-size would be 10 seconds. So every tick on the slider is 10s. Or 5, etc. Might be easier to use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minimum step is probably the best approach.
But the main issue is the wide range of times you might want to set (possibly even above what the max value currently is - I can definitely image scenarios where zeus says "you have one hour to find the device, go!")
Having typed that out, I think I'm inclined to lean towards a text box with a HH:MM:SS format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On that note - might be useful to have an additional module (or when the current module is reapplied to an existing "device"), that allows the user to pause/restart/adjust the countdown
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is fair point. I hadn't thought of a zeus going "you have 1 hour" as usually with zeus, that period would be way too long. Too many things able to go wrong or arma being arma, with players loosing time and the timer "strictly" would need to be paused or extended.
But could open up for some extra zeus options. Like time-acceleration on 1, and use ingame time, to say that they need to be in position at XX time, as then this or that would happen.
In that case HH::MM::SS is likely best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like time-acceleration on 1...
Oooh, hadn't even considered whether it should be affected by time acceleration. Probably not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say not. Makes it too difficult for Zeus. Imagine forgetting you had 10x acceleration on and putting down a 10s countdown for players. Instantly effect happens. Better to keep it to irl time. (As so far the human players don't experience a 30x acceleration, as the computer does ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On that note - might be useful to have an additional module (or when the current module is reapplied to an existing "device"), that allows the user to pause/restart/adjust the countdown
Ugh, now I'm dealing with race conditions! 😅
Plus some bug fixes and comment cleanup
Whats the status here? Need another review? Trying to figure out if you are waiting on me, or just to have more free time yourself ;-) |
I think we're just waiting on a server-test to shake out any locality issues! |
Fix EW loaded check for server
Adds "Suitcase Device" module; spawns a ruggedised laptop with a countdown towards a customisable event (small/large/nuclear explosion, smoke, etc).
Device is also "killed" at the end of the countdown, so can be paired with the
On Death
module to add custom code, etc.Can be disarmed (optionally, only by Engineer/EOD tech) after a customisable amount of time.