DeletedUser
Guest
It's a hard one to explian...well, let me run it through my head for a while.
I'm with you this far, but 5 days ago only 19 Romes would appear, each would have their own unique IDImagine this :
You search for Rome and get 20 results.
You set the history slider to 5 days ago.
Now one of these 20 Romes appears to be conquered that day and used to be named Athens before the conquer. That leaves us with a projected result set of 19 Romes and 1 Athens.
Not exactly. I'm suggesting that if the Rome selected today was changed 5 days ago, the name would change to Athens when the history is set to 5 days ago.The original search term Rome is still valid, but according to your suggestion, the town name input should reflect the name change of that one town.
only if a new search is invoked, ie user types in the input field. This is based on the original search matching the input text and then looking up the ID today. The text data for the same ID 5 days ago would be Athens. All cities have a unique ID even if there are multiples of them with the same name. The converse is true if Athens was looked up 6 days ago and the same one selected. walking forward in history would reflect the name change to Rome 5 days ago, and will continue to be the same until today.Which for towns it obviously cannot, because there still are 19 Romes in the result set. Town names are not unique and that causes problems for this alternate mechanism.
All objects have their own unique ID, just some of them are unlikely to change.So i think this could work only with alliances (and I guess playernames), because those are unique at any given time.
Currently, whatever is typed into the input field is matched and displayed. If there is not a match, then the red highlight is shown, so the system is partially there for updating the text. All that needs to happen, is if there is a match, the ID is looked up and stored, and whatever text belongs to that ID at any point in history is displayed. If the ID doesn't exist, the object doesn't exist, so therefore is void.
This should work for all objects. Towns are the most troublesome because of the possibility of multiple matches, and that problem exists in game (which of 4 5quelch's City is the right one?), but once one is selected, the ID can be used wherever you like and it will always point to the same city even when it's named Viccoh's City.
Another benefit of this method, is the very long URL's could be shortened to a string of ID's
Last edited by a moderator: