Liberi Issue Tracker

Revision as of 19:04, 16 May 2016 by Clarke (Talk | contribs)

(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

Seems like you can just get in a bad state or miss a packet during connection to a zone or minigame server. Currently the player has to close and reopen the client a lot of the times this happens. There should be a way of detect the bad state, and at the very least making sure the player ends up in the zone they started with a controllable avatar and some visual "Error connecting to Minigame" message. April 15th Update: Unable to reproduce

Code to assign player avatar details sometimes would terminate prematurely. Relied on a dictionary that held data values. However, the code was using incorrect logic and was returning out of the function if it detected a duplicate entry, rather than skipping it and moving to the next iteration.
Fixed in revision: 6596

On world server each client has a data file, which is based on a default file in the players directory called default.dat. This data file was not configured properly and did not have the needed parameters. Spawn code could be corrected to not need this config file; however, this bug seems to be a niche case and this fix does solve the problem
Fixed in revision: 6596

Caused by health regen occurring client-side and post-round heal occurring server-side. Should have a nice way of reviving things without having to worry about this.
Fixed in revision: 6549

This shouldn't be happening, may have something to do with the way bots are reassigned.
Fixed in revision: 6550

Was caused by incorrect naming of checkpoints. Code was not pulling correct checkpoint from scenes.
Fixed in revision: 6594

The code for Home Nest recognition is simplified in the Tutroialized version of the code. Dino Dash was just better the second time it was created and the tutorial code could be merged in to the main repo.
Fixed in revision: 6557

Assumption was correct, players were not getting the update from the Muferoth timeline and a variable was not being set. Updated code so that players get this data even if they join midway through the fight
Fixed in revision: 6594

Corrected by using reliable ordered messages rather than unreliable. Players join in and there are no major sync issues occurring now.
Fixed in revision: 6594

Jan 23rd: Server reports that 8 players should be able to join. However, when any more than 7 players attempt to connect to the server, the last is unable to play.

This was caused by shuffling the start points and gekkus colliding into each other. Solved by not shuffling start points. Should this behaviour be desired later it can be reimplemented by uncommenting line 184 of gekkuracelogic.cs
Fixed in revision: 6596

No idea here. The game isn't really finished (because there was always talk of the game having a complete redesign but without ever actually doing so). So this one may not be that big of a deal, but for now it renders the minigame unplayable when the bug occurs.

Players each other dip into the ground, moonwalk (face the wrong way), and just generally jerk around. Honestly just feels like positions here should just be interpolated and not extrapolated because you just don't care where other players are. Not flipping is a problem with discrete timelines not sending when they should?
Fixed in revision: 6551

It's possible for two players to get a power bubble because that interaction is done locally. It's pretty rare and kind of funny when it happens, but the logic could be changed to avoid this.

This was one of the first games ported when Dan was still learning the framework. It's possible this is just a small glitch in the BoboView script and is not indicative of a more serious issue.
Unable to reproduce as of revision: 6551

Double checked the Sorting Layer and Indices for the floor and the leaves and it looks fine. May be related to the custom floor shader (which makes it hardware dependent).
Fixed in revision: 6557

Enemies will attempt to attack monitor as if it were a real player as well. As well, monitor is affected by in game hazards and traps.

Lodestone code triggers an exception for clients before a lodestone is enabled. Typically has no effect on players beyond writing the exception. However, this does break the monitor client as it is unable to trigger a lodestone.

Or do they? Noticed this happen only a handful of times, and it was always difficult to tell if the Gatto just happened to die moments before it hit the Wiskin, but it really looks like sometimes the Wiskin just tanks the hit.

Enemy avatars fall slightly through the floor when they land. Not game breaking but could be made to look a little better. Does not seem related to latency but could be

Monitor client should not start games. However, if a monitor enters the whiskin portal before other players the enemies start spawning. Should be mindful if using the monitor client as it will affect any players that enter after.