Start_zones: Titanium input through an SoF query

[AdrianD]

Out of the blue! I may have found a workaround. The query below is quite simple. I don't plan on testing several hundred character create combinations. I don't think it would work on all of them. I'm also uncertain if this would affect bind points. It has worked for the few I tried that didn't work before.

update start_zones set `start_zone` = `zone_id`;

update start_zones set `zone_id` = `player_choice`;

I would rather have a real fix than a cheap hack.

* It does affect bind points as noted in the character_bind table. I suppose the only thing hurt for the noob after appearing in front of their gm naked is their pride. Stiil, not ideal or resolved. This has been happening for quite some time. unix_timestamp = 1417319554 - first occurrence of double bind coords in the table - around 8/9 months?

This also leaves SoF clients with the same problem Titanium clients had, I believe.

[AdrianD]

I think I found a workaround to my workaround. I still don't like it. It's not clean or the most efficient but, I believe it will work. Please tell me what you think.

I took the original start_zones data and created a copy table. I unkeyed all the primary keys and used the query below.

update start_zones_copy set player_choice = zone_id;

I set the keys back to the way they were. No conflicts because player_choice = zone_id, don't know how else to put it. Then, I used INSERT IGNORE INTO the main table.

Clients with SoF won't notice a difference save a few dozen duplicates where that issue was raised above for a real fix.

The point of doing this was to essentially make copies of the rows which have primary keys. As you know, the maximum int player_choice for titanium clients is about 14 and SoF clients don't make use of that column.

Let me know if something doesn't seem right.