-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix "Player" name. #388
Fix "Player" name. #388
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As always great work! I did see one issue we might want to think about.
weenieheaderflags should be set by the existence of data call SetWeenieHeaderFlag() in world object. This should be the same for physics Flags. If we have issues using that method - we either have not set needed data or there is a bug in the flag setting routine. They have to match - setting a flag with no data causes bad packets. Not setting a flag but setting the data will not create a malformed packet, but your data will not be sent. Now you are over on the AceObject. So we need to figure out what to do there. Having to set the flags by hand was causing us a lot of issues before.
Object Description flags are a different animal and not related to data - they carry information themselves and are not used as a communication flag to the client about what data to expect and read. They unlike the other two have to be set or read verbatim from the db.
After reviewing Og's comments, I should probably look at how the flags/headers work. Right now I take all data possible from the database, apparently it holds extra data I should re-calculate. Hopefully will address tomorrow (6-18-17) |
@@ -90,7 +90,9 @@ public static void Handle(ClientMessage message, Session session) | |||
forcePositionTimestamp = message.Payload.ReadUInt16(); | |||
message.Payload.ReadByte(); | |||
|
|||
session.Player.UpdateLocation(position); | |||
// FIXME(ddevec): The game sends invalid positions sometimes... when in portal space. Ignore? | |||
if (position.Cell != 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we might ought to have a Position constant that indicates portal space. This way you don't leave the character behind somewhere too long where they can still be targeted by monsters or something after they've portaled away.
@@ -22,6 +22,8 @@ public AceCharacter(uint id) | |||
// Required default properties for character login | |||
// FIXME(ddevec): Should we have constants for (some of) these things? | |||
ItemType = (uint)ObjectType.Creature; | |||
AceObjectDescriptionFlags = (uint)(ObjectDescriptionFlag.Stuck | ObjectDescriptionFlag.Player | ObjectDescriptionFlag.Attackable); | |||
WeenieHeaderFlags = (uint)(WeenieHeaderFlag.ItemCapacity | WeenieHeaderFlag.ContainerCapacity | WeenieHeaderFlag.Usable | WeenieHeaderFlag.RadarBlipColor | WeenieHeaderFlag.RadarBehavior); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is absolutely ideal, but are we ready for this yet? Just checking.
Cleaned up player initialization, and bugs related to player creation. Player names now display properly.