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).
Added -DCOOP to identify that this is a coop build so that one patch can
be applied to EX and/or COOP. They can choose to ifdef entity synchronization
out.
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
