|
|
|
|
|
|
|
|
|
|
|
|
Re: Need to move away from using names as IDs |
Sat, 09 July 2011 03:15 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Musmuris wrote on Sun, 03 July 2011 23:18 |
Daniel wrote on Fri, 01 July 2011 07:56 | I have modified Item.Owner to bit shift values passed in or out so they are in the range 0 to 0x7F instead of being Item.Id & 0x7F000000. This allows code of the form item.Owner = 1 instead of item.Owner = (1 << 24); I also added some unit tests for item.Owner and item.PureId properties.
This fixes a couple of the integration tests for the battle engine, but there are more to go.
|
It might fix the tests.... but it breaks the making of a new game!
So i've just reverted that change locally so I can carry on until we decide what to do
|
Ok, so I have had another go at this. Firstly note that the current state of the code base (Rev 698) does not allow you to play turns. You can open and submit a turn, but turn generation is bugged due to the turn year issue discussed here. The code I will upload after posting this fixes this issue so you can submit your first turn properly. It however fails to generate, but that is a small step forward.
In Rev 698 we have 32 bit Ids comprising a sign bit, 7 owner bits and 24 PureId bits. The collection key is referred to as Id and setting and getting the owner breaks a number of unit tests
I have re-written the code to handle Ids. The backing store is now called key (accessed by the Key property) which is a signed 64 bit integer (aka long) thus:
/// <summary>
/// Backing store for the game wide unique key.
/// First bit is for sign. Negative values are reserved for special flags.
/// Bits 2-24 are reserved.
/// Bits 25-32 are for the empire.Id aka Owner.
/// Bits 33-64 are the Item.Id, which is a number generated by the client and unique for objects owned by that empire.
/// Bit map is:
/// S-----------------------OOOOOOOOIIIIIIIIIIIIIIIIIIIIIIIIIIII IIII
/// IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
/// ^ ^ ^ ^
/// +-- sign bit +-- reserved +-- owner +-- client generated Id
/// </summary>
private long key = Global.NoOwner; // Default to no-id and no owner.
As you can see there is still a sign bit (not really used). The owner is now an unsigned 8 bit number (ushort) from 1 to 255 (zero reserved for unknown/unset). The Id (formerly the PureId) is a 32 bit unsigned number (uint), again zero is for unknown/unset.
Item also implements Owner and Id properties to access the masked fields embedded in the Key. These should always be used when referring to just the Owner (or empire.Id); or to the Id portion of the key. The Id is unique to the client but not necessarily unique in the game and should be only used for generating display values such as in a fleet name.
This has been a big change and has taken two days to track down the bugs caused by miss matched Ids and Keys. Using long, uint and ushort was a strategy to try and catch some of these bugs, however implicit casting still causes some problems.
The advantage is now that a collection.Key is always generated from an Item.Key, an owner/empire.Id is always a number from 1-255 and there is no need to think about bit masking or shifting outside of the Item object which implements this.
I will now try to fix the rest of the turn generation issues caused by these changes.
Have fun.Report message to a moderator
|
|
|
|
Re: Need to move away from using names as IDs |
Sat, 09 July 2011 04:37 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Aeglos wrote on Sat, 09 July 2011 18:06 | Sounds good to me; it's like the finishing touches that consolidate the system.
I assume the 2-24 reserved bits are futureproofing for flags?
|
They are so the Id could be a full uint and I could add a seperate value for owner, as this allowed me to use different types for Id and owner to catch some of the casting bugs.
Aeglos wrote on Sat, 09 July 2011 18:06 |
One thing though; last time I tried to use unsigned values (for Resources), I had a heck of an ugly time and needed a tremendous amount of casts to make it work. I asume this wouldn't be the case as Ids/Keys are fairly isolated from the rest of the code as far as setting and getting goes.
|
It is all handled inside Item. If you are casting with owner or Id (except to/from strings) you are probably doing something wrong.
Aeglos wrote on Sat, 09 July 2011 18:06 |
Also and just for the record, unisnged types seem to be non conformant with the CLS spec. We shouldn't have any issue though as we are not interoperating across languages.
|
Possibly an issue for third party tools. I tried to create a type definition for Id and owner so it would be easier to change the type in the future if required, like:
typedef owner_t ushort;
However this is not supported in C#. I would love to have the sort of type control available in ADA for this as it would save me hunting down a lot of runtime issues caused by implicit casts that should be errors, usually where an Id is used instead of a Key.
Have fun.Report message to a moderator
|
|
|
|