ACE_Spectator TODO list

[nicolasbadano]

Branch: ace_spectator

• [x] Remove stringtable entries that aren't translated. (just leave the English lines)
• [x] Replace isDedicated by !hasInterface (https://github.com/acemod/ACE3/pull/1760#discussion_r33571672)
• [x] Do not modify viewdistance unless the user changes the slider
• [x] Add a canInteractWithCondition isNotSpectating (or similar) to prevent the interaction menu while spectator is open. That will also block all actions binded to keypresses.
• [x] Modify the code so it modifies gear as little as possible
• [x] !(_x in allMapMarkers) (https://github.com/acemod/ACE3/pull/1760#discussion_r33733952)
• [x] Make spectator mode work on missions with respawn
• [x] Add controls as CBA keybinds

SilentSpike's overhaul todo list (for 3.2.0):

• [x] Clean up the display config (use correct interface coordinate systems, remove redundant classes, etc.)
• [x] Unify interface config to make an actual display
• [x] Correctly load and unload the display
• [x] Free cam movement
• [x] Camera mode switching
• [x] Spectator map processing
• [x] Unit list processing (both compiling a flexible list of units and UX)
• [x] Functional toolbar values
• [x] Enable escape menu
• [x] Cleanup (function headers, privates, etc.)
• [x] Re-enable the compass
• [x] Togglable interface components
• [x] Settings for the following:
  • [x] Side filters
  • [x] Camera mode restrictions
  • [x] Vision mode restrictions
  • [x] Unit filters
• [x] Clock
• [x] Unit list side indication
• [x] Mouse dollying
• [x] 3D unit icons

For (3.3.0):

• [x] Provide camera locking functionality
• [x] Prevent ace_goggles overlay
• [x] Enable zeus usage
• [x] Investigate improved methods of keybind handling
• [x] Make the values on the display toolbar interactable
• [x] Speed should adjust with zoom
• [x] Vertical movement speed should scale at half horizontal
• [x] PRIORITY The onDeath setting should be redesigned:
  • Should enable spectator state becoming a replacement for the BI death state
  • This essentially means spectator cleanly integrates into the BI respawn framework when the setting is enabled (enter on death, exit on respawn, compatible with all respawn types/templates)
  • The setting persists so that people using custom scripted respawn frameworks can disable it and integrate spectator into their own framework as desired

[kymckay]

!(_x in allMapMarkers)

Since we will be making this compatible with respawn missions then the code that moves those respawn markers will need to be totally changed anyway :+1:

[kymckay]

I'd propose introducing a new marker "spectator_respawn" (or similar) to handle the spectator holding position. With some code to just move players somewhere off map if it doesn't exist.

[kymckay]

Oh and good idea merging this for further development, I was considering the idea myself :+1:

[kymckay]

Created branch ace_spectator for development (and updated issue).

[nicolasbadano]

I'd propose introducing a new marker "spectator_respawn" (or similar) to handle the spectator holding position. With some code to just move players somewhere off map if it doesn't exist.

Sure. We can also specify hardcoded default positions for common maps. I remember a list of default pen coordinates existed on an addon by Columdrum for ACE2; we could ask permission to use those as they are.

[kymckay]

Actually, looking at the calculation for the pen position now it seems fine. It just shoves players off map. Which removes any possibility of the position being a problem in a mission. I'd probably change it to just be a fixed value and cut down on some of the code, but that's fine in my opinion.

The respawn markers being moved was presumably to avoid any weirdness with people spawning then being moved, but I'll take that code out anyway because it introduces more problems than it fixes (when respawn support is desired).

[kymckay]

Come to think of it, do all terrains start with (0,0) in the bottom left?

I simplified the pen calculation with the assumption that they do.

[nicolasbadano]

Come to think of it, do all terrains start with (0,0) in the bottom left?

No. There are maps that have an offset (a certain map from Iron Front comes to mind; it was discussed on the 10 digit gps thread).

[kymckay]

Hmm, that fixed default position should only be an issue in very edge case situations then. I'll leave it as is, but if anyone feels it's worth changing I have no objections :smile:

[nicolasbadano]

Hmm, that fixed default position should only be an issue in very edge case situations then

Probably. We can very well wait for gps people to solve it for us and then rip off the reward.

[voiperr]

@SilentSpike So how do we want to handle missions with proper respawn? Put a respawn timer in the corner somewhere? Is there a way of postponing the respawn menu?

R.e. gear: Ideas for preventing players from drowning without scuba gear? Maybe make a PFH to setPosASL the player floating in air (network overhead?) or attachTo a static object with an offset above the water?

[nicolasbadano]

Maybe make a PFH to setPosASL the player floating in air (network overhead?)

Yes, that would create large network overhead.

attachTo a static object with an offset above the water?

That'd should probably work.

Another random solution would be to actually put spectators inside bloody submarines. TBH I'm in love with that idea. It'd would also be hilarious if the respawn point is on land, but it'd still work.

[kymckay]

@voiperr The respawn system is up to missions designers, what's needed to allow for that is just plenty of flexibility. What I'd personally consider necessary for this:

• A reliable method to mark a player as a spectator (also means we don't have to rely on checking if someone is near the pen)
• Reliable functions to load/unload spectator mode as many times as desired. Should be manually callable (we can use the ace event system for this) so that designers can set up their own scripted respawn systems

[kymckay]

On top of that, we could develop some configurable standard respawn systems (wave respawn, life pool, etc.) as quality of life improvements for users. Though that's me planning a little far ahead :wink:

[kymckay]

Another random solution would be to actually put spectators inside bloody submarines.

Read my mind :grinning:

I've also been considering a PFH to setOxygenRemaining 1 and figuring out a way to override the vision blurring.

[kymckay]

Hmm, there is another possible solution:

We could delete the player unit and cache all of it's details (so that it can be recreated upon respawn). However this might not be handled well by external scripts.

Edit: Hell we could add a spectator unit to switch into, would also be an easy way to identify spectators without locality trouble. I wonder if doing so would break any other ace systems.

[nicolasbadano]

We could delete the player unit and cache all of it's details

That could be problematic; IDK if we can trust radio spectator modes working without the player existing.

[kymckay]

without the player existing.

Would this be a problem if we switched into a virtual spectator unit?

[voiperr]

Wouldn't just assigning a public objectVar be simpler?

[kymckay]

For checking if a player is a spectator sure, but a virtual unit could bring some advantages (and solve multiple birds with one stone) if it wouldn't cause issues elsewhere.

I'm just spit balling though, I'm not going to change the code unless it's an immediate solution/improvement or an agreed design decision.

[kymckay]

So, good news everyone: hideObjectGlobal actually disables collision too in A3. So we technically don't even need to move spectators out of the way on respawn (which would also happen to make the rest of the code more simple).

[voiperr]

I've seen a few mission scripts use area proximity detection for whether to count players for various reasons. I still think it's prudent to throw them out of the map area.

[kymckay]

Hmm, that's a good point, triggers could also act unexpectedly as a result :+1:

So yeah, probably need to move them regardless.

[kymckay]

I've implemented a basic spectator enter/exit function in ff4fce39501ab0938f8d791b4a59d2da4a4bf1d7

Submitted PR #1783 to implement method of handling object hiding into ace_common (see comment in the code as to why).

[kymckay]

RE: Drowning, we could put the units high in the air and enableSimulation false them?

[kymckay]

Well I tested that and it works, but...something went wrong with the camera script and I'm unsure if it's related

[kymckay]

Okay so I think because the player is being moved so far off map the game is running out of memory and crashing. Introducing optional marker "ace_spectator_respawn" to define an explicit position and avoid that problem.

Currently it'll just use [0,0,0] if the marker doesn't exist, which should avoid potential issues with triggers and things well enough for now. Once the GPS people get something done we can explicitly use the bottom corner.

[kymckay]

I think we should consider just removing the view distance slider.

It feels a little out of place (and redundant) to me having it in the spectator interface.

[voiperr]

Streaming/screenshots/etc would benefit from it. I'm making it optional via module.

[nicolasbadano]

Streaming/screenshots/etc would benefit from it. I'm making it optional via module.

Keep in mind that we have a viewdistance module already, and the plan is to include keybinds to up/down the viewdistance at any given time (those keybinds are not added yet). Maybe that could serve the same purpose here.

[voiperr]

Aren't there plans for VD restriction, though? Some mission makers might want it so spectators can see further than living players.

[nicolasbadano]

Aren't there plans for VD restriction, though?

There's already a configurable (optional) viewdistance restriction. We could add independent restriction distances for playing vs spectating players on that same module.

[voiperr]

VD done: https://github.com/acemod/ACE3/pull/1789

[voiperr]

Oops, still a few left (I blame notepad++): https://github.com/acemod/ACE3/pull/1791

[voiperr]

Keybindssssssss: https://github.com/acemod/ACE3/pull/1794

[kymckay]

All that's immediately left to do is get the enter/exit system to a reliable state and do some cleanup.

There are further enhancements to be made, but we can work on those after this.

[nicolasbadano]

Yup. Keep in mind that entering/exiting spec mode needs to bind/unbind keys now too

[kymckay]

:+1: Good call, I'm gonna clean that stuff up in a bit

[kymckay]

@voiperr May I ask what purpose the "killed" EH serves exactly?

[voiperr]

@SilentSpike Local EH applied to remote units. As soon as they die, updates the tracking array, exits POV if inside that unit, and provides a death message (if markers are on). Could be inherited to base class via XEH, but I thought it would be cleaner if the "CheckUnits" PFH applies the Killed EH only when spectator is actually used.

@esteldunedain For respawn missions or all missions? Are we allowing players to exit spectator on permadeath missions...?

[kymckay]

I mean the one in postInit :)

[voiperr]

Handles when player initially dies, then applies in case player somehow dies in pen (unlikely) or hits respawn button in menu. No reason it can't be a function. :wink:

[kymckay]

Isn't it redundant though? All of those things seem to be handled on respawn as far as I can tell

[voiperr]

The hearing update and fadeout, the fade to black, all need to start on player death (assuming we're keeping those (I think we should keep the sound one, at least)). Group joining could go to respawn.

[kymckay]

• I removed the sound and black fade on death (they don't really serve a purpose). The black fade also kept breaking and becoming permanent - I couldn't figure out why.
• Unit side and group are cached upon death to support "respawning" (unit side was previously cached in postInit, but that won't work in missions where units change side). It seems that the group either can't be cached on death (and becomes grpNull) or BI have changed the game again to delete empty groups (they've flip-flopped on this a bunch of times). Either way, if the group is null is just creates a new one on "respawn" so nothing's changes there. It's important not to create groups en mass because we don't want to contribute to the group limit any more than necessary
• Introduced handleRespawn and handleKilled functions for organisation purposes (handleRespawn is so that we aren't using a public function - setSpectator - as part of the base framework itself).

[kymckay]

My todo for tomorow:

• Clean up camera/controls code
• Finalize "respawning" support. Possible ideas for this:
  • We could forceRespawn the player and let the game handle proper respawn procedure. This would have the benefit of supporting respawn templates by default and processing the correct event handlers. The downside would be that 2 deaths would take place which might produce unforeseen problems for external code (including mission designers) - granted, the current spectator system might produce unforeseen problems for external code anyway.
  • We can manually approximate engine respawn behaviour with code and avoid re-killing the player. This is probably the most obvious decision for the time being.

[kymckay]

Taken care of some respawn stuff, haven't pushed as I'm in the process of cleaning up the display configs.

[kymckay]

ace_spectator now essentially supports respawn. The framework is there, but I plan to add more ease of use functionality into it.

First I want to clean up the interface code/config though. Already made good progress on the config but it's not quite in its final form.

[kymckay]

Oh, there are also some errors present in the interface code I'll have to take a look into.

[kymckay]

Considering stripping out the time acceleration functionality as it seems a little like feature creep, any thoughts?

It's only really useful in single player, but then you'd only enter the spectator mode via script in SP anyway as either a result of:

1. The mission designer - who presumably wouldn't want you messing with time acceleration.
2. Yourself - who presumably could execute the necessary commands manually as desired.

Is our design intent for ace_spectator to be multiplayer-centric?