Skip to content
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

experimental 4player Counter / Co-Operative #389

Closed
wants to merge 75 commits into from

Conversation

NeonNyan
Copy link

@NeonNyan NeonNyan commented Feb 11, 2024

4 player pvp missions

Screenshot from 2024-07-05 20-42-26
Screenshot from 2024-07-05 20-46-53

known issues

  • coop + anti is still janky
  • dark rooms + NVG or x-ray vision may be a flashing light hazard

goals

Want to play 4player coop / anti with a mix of coop / anti team characters

No recompiling of ailists. Should "just work" with vanilla levels and well-formed mods.

Load mp profile for coop / anti characters for controller / hud settings / "leveling"

non-goals

  • Custom characters as coop characters (for now)
  • Fixing non-breaking n64 bugs beyond what is required
  • adding coop / anti support for levels not built for it
  • adding anti support to mp ailists commands that don't use it in retail until modders who actually make levels also weigh in on how they should work

background

In Vanilla PD, 'coopness' or 'antiness' of a PD session is controlled by setting g_Vars.coopplayernum and g_Vars.antiplayernum This is used to determine if coop or anti is running, and what player index to use. Also, coop / anti logic is mutually exclusive.

approach

Porting PD to 4 player local coop/anti requires is set via g_MissionConfig.isteam that allows players to join a solo mission as a team of coop or anti characters.

g_MissionConfig.isteam is set to true when the mission is a team mission.
g_Vars.playerroles is used to track player role constants against player slots. This is used by playermgrAllocatePlayersFromRoles to initialize the player slots and various control variables.

g_Vars.currentplayer is the current player struct.
g_Vars.players : player structs for all players.
g_Vars.currentplayernum is the current player number

g_Vars.coopplayers : player structs for coop players. The bond slot is set to 0 as well as the anti players.
g_Vars.currentcoopnum is the current coop player number. On each frame the coop player is set to the next coop player struct that exists.
g_Vars.coop: current coop player struct

g_Vars.currentantinum is the current anti player number. On each frame the anti player is set to the next anti player struct that exists
g_Vars.antiplayers : player structs for anti players. The anti index is set to 0 as well as the coop players.
g_Vars.anti: current anti player struct

In order to gaurentee that ailist commands that are intending to reference CHR_ANTI, CHR_COOP, and CHR_P1P2/CHR_P1P2OAIlist commands referencing CHR_COOP or CHR_P1P2 will be treated as any or all coop / ally chaaracters.

limitations

  • scripts targeting CHR_COOP or CHR_P1P2 will need to be treated as any or all ally characters.
    This means that mission-related hud messages intended for one coop character will be sent to them all.

acknowledgements

  • borrowed fixes from @iamgreaser's 4player anti effort: merging the tiktok mode hud settings into 4p, correctly spawning 4 players into a mission
  • @fgsfdsfgs / Ryan Dwyer for the pc port / decomp but specifically reviewing the scheduling logic and talking me down from attempting any kind of live ailist reinterpretation.

@iamgreaser
Copy link

I'm having a look at the ailists for a hopefully cleaner solution and it's starting to look a lot more feasible than I thought it would.

Having said that, having a list of all anti and coop players is a nice idea. Not sure how tempted I am to borrow that idea, but I do intend to have something working to the point where you'd have co-op and counter-op stuff happening in the same game mode.

Something you'll want to consider is the CHR_P1P2 reference and the chr_toggle_p1p2(CHR_SELF) command. If you cycle through all protagonist players then I suspect that would tackle the most general cases. But there will definitely be plenty of pain especially pertaining to objectives being failed in situations where they should not be, and also stuff appearing and disappearing while visible to some of the extra co-op players.

@NeonNyan
Copy link
Author

Cycling the "current coop" player and basing the p1p2 toggle calculation based on MAX_PLAYERS and the current coop number number does make most things work. Like @fgsfdsfgs suggested CHR_COOP / CHR_P1P2_OPPOSITE references in the if_chr_.*(chr,[... ,] label) should check for all the other coop characters (when p1p2_opposite isn't bond) so the ailist can make the appropriate jump. Right now non-bond characters need to tap the use button repeatedly for some ailist scripted objects like lifts and objective items because of the coop cycling. Also the surveillance cameras take a long time to notice non-bond players.

NeonNyan and others added 27 commits June 17, 2024 12:31
This allows all 4 players to be detected and targeted by enemy guards in
coop
... but manually typed in

see fgsfdsfgs#383
These work fine in the 2x2 split arrangement.
use currentcoopplayernum instead of coopplayernum

p1p2_opposite: attempt to resolve a new player by subtractng the
coopplayerindex from the max number of human coop buddies
@NeonNyan NeonNyan changed the title experimental 4player coop experimental 4player Counter / Co-Operative Jul 7, 2024
@JacksBestGaming
Copy link

I have no clue who came up with 'Build Your Perfect Team", but I love it so much. This is not only extremely cool on a technical level, but on a creative one as well.

@Unradelic
Copy link

image

Happened while fiddling with the menu options, going back and forth, then crashed :P

revert: allyplayers was a bad idea
@NeonNyan
Copy link
Author

image

Happened while fiddling with the menu options, going back and forth, then crashed :P

Pretty sure I've seen this while trying to get controllers setup.

@NeonNyan
Copy link
Author

image

Happened while fiddling with the menu options, going back and forth, then crashed :P

cf75ba3 should fix it if it's the same issue I encountered.

@NeonNyan
Copy link
Author

NeonNyan commented Sep 1, 2024

  • BUG: vanilla allocation flow disabled and this breaks vanilla campaign flows

@MonsMarineris
Copy link

Screenshot 2024-09-30 154934
I am unable to build this for some reason :(
I do admit I have no fuggin clue what I'm doing. But still, I was so excited to try this out.

bgunSetSightVisible(GUNSIGHTREASON_NOCONTROL, false);
bgunSetGunAmmoVisible(GUNAMMOREASON_NOCONTROL, false);
if (isChrPropCoop(chr->prop)) {
struct playerpool** playerpool = getPlayerPool(CHR_COOP);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wtf I have no idea how this built and worked on Linux. I'll take a look when I'm on my computer next. Unblocks #389 (comment)

@NeonNyan
Copy link
Author

NeonNyan commented Oct 2, 2024

Screenshot 2024-09-30 154934

I am unable to build this for some reason :(

I do admit I have no fuggin clue what I'm doing. But still, I was so excited to try this out.

I broke windows builds with some stupid code that I'm not sure how it built on Linux. I'll take a look when I'm on my computer next.

@NeonNyan
Copy link
Author

NeonNyan commented Oct 8, 2024

I'm closing this PR and taking it private until it's in a more stable state.

@NeonNyan NeonNyan closed this Oct 8, 2024
@NeonNyan NeonNyan deleted the dev/4pcoop branch October 8, 2024 03:59
@MonsMarineris
Copy link

Thanks for having a look at it. I wish I had any sort of knowledge to help. I'm trying to learn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants