Skip to content
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

Merged
merged 4 commits into from
Jun 19, 2017
Merged

Fix "Player" name. #388

merged 4 commits into from
Jun 19, 2017

Conversation

ddevec
Copy link
Contributor

@ddevec ddevec commented Jun 17, 2017

Cleaned up player initialization, and bugs related to player creation. Player names now display properly.

Copy link
Contributor

@ogmage78 ogmage78 left a 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.

@ddevec
Copy link
Contributor Author

ddevec commented Jun 18, 2017

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)
Copy link
Contributor

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);
Copy link
Contributor

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.

@Mogwai-TheFurry Mogwai-TheFurry merged commit 215ac7b into ACEmulator:master Jun 19, 2017
@ddevec ddevec deleted the name_fix branch June 21, 2017 22:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants