Should be snappier and less prone to crashes. I tested as many scenarios
as I could think of and it has been rock solid. But time will tell.
Also created a new debug log system, just so I could understand what the
hell was going on with this code.
Two players in the same cannon was causing softlocks and general
insanity. Now this should be fixed. Also prevented players from being
able to push or attack a player inside of a cannon.
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
MysterD
fgsfds