SilentSpike

Not at all. Though I should point out that the script was directly taken from ACE2 and updated. I do agree with you though that the resulting effect is too predictable. It's something that's slowly been improved, but the nature of ACE is that things get worked on as needed/desired (and when time permits). The good news is that it's open source, so anyone can submit a change to improve cookoff and if the consensus is that it's good then it'll become part of ACE3.

Downloads Steam Workshop Google Drive Description Trapped in a virtual arena, you must drive fast to stay alive. A variety of mission parameters are available to mix up the formula. Supports up to 32 players (and has additional spectator slots). This is a last man standing game inspired by Tron, the original concept was created by PabstMirror (a fellow ACE dev) who provided me with the old code which I've entirely rewritten and built upon (i.e. added silly mission parameters to make things interesting). Thought I'd share since this has proven to be a reliably fun, goofy game mode within the group I play with. If you have any suggestions for more mutators please share them! Requires ACE3 (uses the spectator system). Compatible with ACRE (will add a radio to players for all your trashtalking needs). The random vehicle options are compatible with all vehicle addons (they are generated from config). Mission Parameters Arena Size: How big the arena you're trapped in will be. Vehicle Selection Method: How the mission will pick each player's vehicle, by default it uses preselected vanilla vehicles to ensure the mission will play as expected. However, I definitely recommend trying the random options as literally anything could come up! Vehicle Selection Pool: The pool of vehicles from which the selection method will pick from. The current pools are based on the vehicles' max speed for balancing purposes. Block Size: The size of the blocks that make up each player's trail. Block Gaps: The size of the gaps (if any) between blocks in the player's trail. Note that the gap size is relative to the player's vehicle width. Speed Threshold: How fast of a speed the player has to maintain to stay alive. Note that it's relative to the max speed of each player's vehicle. Mutator: Random, ridiculous options to change up the game. These are intentionally pretty ambiguously named, but you should be able to figure out what they all do. Videos Playlist graciously provided by drofseh

I wrote the ACE spectator code (which is now largely based on the EG spectator code since the rewrite) and can provide some insight on the source of this bug: The commands for drawing icons/lines in 3D have no visible effect when the current `cameraOn` unit is not alive. There's a bit of weirdness to this in that it never seems to happen in respawn modes 2/3 where the player is still associated somehow with their corpse for the duration of the `respawnDelay` mission attribute. However, in other respawn modes where the player dies permanently they seem to become disassociated with their corpse after a seemingly random time (some kind of engine garbage collection) which is when the icons stop drawing (I'm guessing what's actually happening is that the AI brain associated with the unit is no longer present - and yes, players have an AI brain of sorts). That's the reason why it only fails in free camera, because behind the scenes the view is switched back to the player unit. The way I've fixed this in ACE is to have a temporary agent unit which I switch the view to while in free camera. Reference: https://github.com/acemod/ACE3/pull/5868

This shouldn't be possible, a player's body can't be deleted until they have respawned (at least, that was the case when I tested this when I first wrote the spectator code) ? There are only two pieces of code that do anything with the corner of the map: One is the respawn template for modes 1/4/5 (bird, group and side) where death is permanent and the player becomes a seagull. It creates a new virtual unit to switch the player to, so that they can still use zeus even though they're technically dead. The other is that an agent is created so that while in free camera the code can switch the current view to it (this is to get around issues with icons failing to render when the player is permanently dead and their corpse is deleted, it's entirely behind the scenes and as far as the user is concerned does nothing). Your best bet would be to create an issue on the tracker with an appropriate rpt file and reproduction steps.

Checked and neither has changed names (ACE_EarPlugs and ACE_EntrenchingTool respectively). It's safe for the time being, but the future is fairly uncertain we can't say when/if they will stop working so you may want to switch now to save headaches later down the line.

I think your first point is fair in that it's not so obvious which components of ace are being edited by a mission at a glance in the editor (if I'm understanding correctly). Perhaps there's something we could do to remedy that in the new system (a checkbox or something to only show settings that aren't default). I don't necessarily agree that it takes time to learn the new system since it's basically exactly the same aside from the more explicit handling of client/mission/server setting precedence (which hopefully the UI is clear about). As for your 3rd point, you may have misunderstood something because settings can still be set at the mission level which will override server settings by default (unless they are set to override the mission). I do largely believe there's a lot of familiarity bias going on and we did obviously expect a period of transition - which is why the old system is temporarily supported while people familiarise themselves with the new one. However, only time will tell what we need to change with continued feedback. Are you from Reykjavik by the way? I'm quite excited to be visiting there soon :) Have a happy holiday season too! Edit: Regarding my first point actually, the export dialog will only show settings that have been changed.

It seems all the menuXXX commands are just totally broken and don't work sadly. There's also weirdness with the menu control types themselves, type 46 deletes itself when losing focus (like a context menu - which is meant to be type 14).

That's correct, those systems are considered deprecated as they have been replaced by CBA settings. They will eventually stop working as code is updated in future versions.

That's correct yes, and the ones that are already greyed out are those which can't be changed by clients to begin with as you seem to have guessed Not all settings are currently handled on the back end to allow switching on the fly. In future versions we intend to make most of them work this way where possible (and make it clear where a restart is required to change). I believe the prevent instant death setting might already work if switched mid-mission though (best way is to try it and see). The interface settings should still be present under the Interaction Menu category. The pain effects one should be under medical I believe. If you're asking where the client settings are, please see our announcement again.

Hey, here is the documentation of current version: https://ace3mod.com/wiki/feature/spectator.html Please note that next release will contain an overhauled version which I'd definitely recommend waiting for if your mission doesn't have to be finished asap (it has greatly simplified settings and works better). The documentation pages will be updated to reflect the changes one the release is live.

It seems like the menu control type (46) added with eden is broken. Seemingly as soon as the display focus is not on the menu the control will be deleted. This would make some sense for a context menu (type 14), but seems unintentional for a plain old menu. Strip menus (type 47) behave as expected. It's entirely possible I'm overlooking something though as there's no documentation on these types and I've just been playing with configs to try and get them working.

Or just cases where you want to toggle the behaviour at a later point. Worth noting editor groups have an attribute to delete when empty (default unchecked)

Well, did you read the post above it? I apologise that I didn't predict the existence of the allPlayers command back in 2014.

Oh my, that is an old post of mine. It's missing a bracket and an equals sign, that's probably why it errors. I assume it was just hastily written as an example anyway as it also has a totally redundant if statement.

Just thought I'd post here to try and get some feedback. Ever since the 1.70 update I've been plagued with crashes, they seems to have the error message on this really old ticket so I started uploading crash reports to it. I've only ran into these crashes while in my dev environment for ace so far, but they are extremely frustrating as they tend to lock up my whole system and crash my display drivers completely. I just encountered the worst one yet which somehow broke my display driver so bad I had to hard reset the system 3 times - on top of this it managed to annihilate my git repository as I was in the middle of comitting changes when it happened. So far I've tried: Totally uninstalled my graphics card drivers and reinstalling Reinstalling arma Reinstalling DirectX Running the profiling branch Running the 32 bit executable "Upgrading" my OS to windows 10 Stress testing my CPU and RAM with prime95 blend mode Stress testing my GPU with FurMark Performing a memory test Running `sfc /scannow` The most annoying thing about these is that they are consistently inconsistent. I don't know exact reproduction steps, but they are happening almost every time I'm running arma while working on development stuff. I was not having this issue before 1.70 and no other game I've played has given me the same problem (I thought perhaps it was a problem with my hardware). If a BI dev could let me know how I can go about helping to debug the cause of this I'm more than happy to oblige them as it's seriously hindering my ability to work on projects.