Since the second-player code was the first code I wrote, it was implemented
poorly. At that point, I didn't know the code base at all and the way it was
written would prevent anyone from ever adding to those parts.
The rewrite allows me to use the default geo.inc.c file for Mario, and removes
all of the geo2.inc.c files. I no longer do a bunch of bit shifting to figure
out which player is being drawn in the rendering code.
I'm also now able to remove tons of duplicate code that exists just for the
remote player. The main player code is generic enough to support both indices.
A side-effect of the rewrite is I was able to remove many assumptions in the
code where two-players is assumed, but many other parts of the code still
assume two players.
This is a fairly major change that, if all goes well, will be completely
unnoticed by the player. However, I do expect new bugs to pop up in strange
places. Time will tell.
Saves and loads last join IP/port attempt
Made host's port configurable in config file
Made host's save slot configurable in config file
Made host's player interaction setting configurable in config file
Indicated when the client was trying to connect on the join menu.
Fixed join menu display error where the port would disappear
Made water punch do an attack
Increased knockback significantly
Different types of attacks will have different knockback severity and damage (Stomp > kick > the rest)
Fixed rapid attack spam
Adjust radius for bouncing on players and popping bubbles
Made player interactions a synchronized server flag:
None - Players are not solid
Solid (Default) - Player can run into each other and stun each other
PVP - Same as solid except friendly fire is on
Note: Not currently configurable due to a lack of a UI.
Player life counters are separate.
When one player dies they lose a life and are turned into a bubble.
If the other player pops it, they are alive again.
If all players are bubbled, they get kicked out of the level.
If the bubbled player ran out of lives, they can not come back to life
until the level is over.
Whenever a level change happens, everyone's life count is set to a
minimum of two.
No game overs.
Took heavy inspiration from Kaze Emanuar
Now when a client joins, it will request the entire 512 byte EEPROM from
the server and refuse to continue until the server replies with the
contents. Then the client will override all reads and writes to the
EEPROM/save file. Thus, a client will never overwrite their local save.
Fixes#21
Due to my compile & launch scripts, I was silently ignoring warnings
this whole time. I've fixed my process, and gone back to fixed all of
the warnings I could (even outside of my code).
As reported by somario360:
After grabbing the small box at the same time, one of two results can happen.
There will be a fake cloned box that will only be visually in the other
player's hands, or one player will be stuck in the punching animation until
the other player lets go of the box, in which the box goes into the stuck
player's hands.
Now escapes from action if the grab fails, preventing a softlock.
And now if both players report having the same object, the client
will drop their copy.
Fixes#14
Tuxie will regain its hitbox if dropped through crouching or any other means
Fixed detection of if any mario is far away
Immediately sends an object packet whenever any object is dropped or thrown
Fixes#9
Players are now solid to each other and can push each other
Players can now attack each other (but they do not deal damage)
Players can bounce on top of each other, and they get squished
temporarily
Players are given slightly offset positions when they transition between
areas and levels, so they're no longer on top of one another.
The code was skipping playing the sound of the first punch, and changing
the size of the first for the first punch. Added hacky stuff to the
player packet code to ensure those events are hit.
Fixes#10 reported by somario360
Sleeping animations were desynchronized previously. Now remote goes to
sitting, and to laying down, at the right times. A snoring remote player
will no longer lower your music, and will no longer get stuck snoring
when they wake up.
Fixes#11 reported by somario360
There have been several times where the unpredictable behavior of
a remote player where execute_mario_action() would get caught in
an infinite loop. Now we attempt to detect an infinite hang and
escape from it. The sequence of actions will be recorded into an
errorlog.txt file. In debug mode this infinite hang will cause an
assertion to fail, crashing the game. In normal mode the game will
break out of it and hopefully carry on normally after new packets
come in.
I believe this addresses github issue #12 but I can't be sure.
Reported by somario360:
After I (Luigi) gave the baby penguin to the mother, the start spawned,
but I was stuck in the looking up animation.
My friend (Mario) talked to Bowser after defeating him, Bowser turned into
a key, but he was stuck in the looking up animation after (I was able to
grab the key though, but Bowser was slightly visible) (Also don't mind 0
stars, he loves doing the lobby BLJ)
The issue is the state machine moved on without removing the reading
dialog action. There was no straight forward way to deal with this.
Custom functions were written for each call to dialog to ensure that we
should stay reading the dialog.
Bug reported by somario360:
After I (Luigi) exited the slide in CCM, an error message appeared and ignoring would make it pop up again.
This was due to the sync ID reservation system not being flushed and
reset on area change.
Bug reported by somario360:
When trying to open the cannon in a level (so far tested in BOB & WF) the cannon dialogue will repeat infinitely. Sometimes the cannon will open, but the game will crash after.
The code I had written previously to prevent softlocks ended up causing
them due to a incorrect check of activeFlags.
Synchronized currentRoom per-player
Synchronized haunted bookshelf, and the bookshelf manager
Synchronized haunted chairs
Synchronized mad piano
Synchronized BBH's tilting trap, and made the physics multiple-player-aware
Synchronized scuttlebugs
Synchronized every variety of Boo
Synchronized elevators
Synchronized flamethrowers
Synchronized the various types of enemy books
Synchronized the book switches
Synchronized jumping box
Made coffins multiple-player-aware
Fixed everything that used gMarioState as an array instead of gMarioStates
Prevented some NPC-dialog softlocks
Prevented the remote player from messing up the local's camera settings
Possibly fixed the relatively rare chain chomp softlock
Possibly fixed the relatively rare chain hoot softlock
Fixed the first-person-camera softlock
Forced camera code to use the correct mario struct
This allows clients to spawn a new sync object after the level loads and synchronize it.
Changed how un-initialized sync objects are detected
Koopa shells are the first thing to use this new system
Removed network_object_settings() command, instead explicitly setting the sync object parameters
Added Luigi model.
Renamed all previous references to 'Luigi' to 'Mario2' since player 1
isn't always mario, and player 2 isn't always luigi.
Now server is always mario and client is always Luigi.
Luigi model credits:
Original model by Cjes, converted by AloXado320, textures added/fixed by
SunlitSpace542.
Now we will never kill remote players locally, they will have to let us
know that they died.
Synchronized more of the small breakable box
Fixed desync where an object wouldn't be dropped sometimes
Fixed infinite loop when remote player was squished
Added maximum sync distance, special cases for infinite distance and
only synchronizing entity deaths.
Started mocking out reliable packets for entity deaths.
along with options to select backends for windowing, rendering, audio and controls in the Makefile
use RENDER_API=D3D11 or D3D12 for the D3D renderers, that will also automatically enable using DXGI for windowing; SDL2 will still be used for input and audio for the time being
also adds three-point filtering to the OpenGL backend and an option for it in the menu
saves by default go into XDG_DATA_HOME/sm64pc
external data is read from the executable directory, if it's not found there on Unix systems the game will attempt to read it from some paths like /usr/local/share/sm64pc
both save data and readonly data fall back to other options in case of a problem
behavior can be overridden by specifying --datapath and --savepath on the CLI
both of those will expand the exclamation point ('!') to the executable path, e. g. --savepath '!/save'
