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
Now a patch can choose to register callbacks for sending and receiving
packets. It's a bit tricky to use but at least it won't collide with
normal packets or other mod packets.
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.
MysterD
djoslin0
fgsfds
Garrett