EQEmulator Forums - Start_zones: Titanium input through an SoF query

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Support::Windows Servers (https://www.eqemulator.org/forums/forumdisplay.php?f=587)

- - Start_zones: Titanium input through an SoF query (https://www.eqemulator.org/forums/showthread.php?t=39948)

Start_zones: Titanium input through an SoF query

I am having issues with characters being placed at the locations specified in the start_zones table. Upon creation, the characters are placed at the default bind point in most circumstances. I do not have a rule_values entry for `TitaniumStartZoneID` and I don't understand how it could find one.

Code:

[08-22-2015 :: 05:13:11] [World Server] Found 'TitaniumStartZoneID' rule setting: -1

[08-22-2015 :: 05:13:11] [Status] SoF Start zone query: SELECT x, y, z, heading, start_zone, bind_id FROM start_zones WHERE zone_id = 1 AND player_class = 1 AND player_deity = 396 AND player_race = 1



No start_zones entry in database, using defaults

I've played around with the table quite a bit to see if the above query would select `zone_id` instead of `player_choice`. I found it isn't the case with Titanium clients.

Code:

bool WorldDatabase::GetStartZone(PlayerProfile_Struct* in_pp, CharCreate_Struct* in_cc,bool isTitanium)

{

        // SoF doesn't send the player_choice field in character creation, it now sends the real zoneID instead.

        //

        // For SoF, search for an entry in start_zones with a matching zone_id, class, race and deity.

        //

        // For now, if no row matching row is found, send them to Crescent Reach, as that is probably the most likely

        // reason for no match being found.

        //

        if(!in_pp || !in_cc)

                return false;



        in_pp->x = in_pp->y = in_pp->z = in_pp->heading = in_pp->zone_id = 0;

        in_pp->binds[0].x = in_pp->binds[0].y = in_pp->binds[0].z = in_pp->binds[0].zoneId = in_pp->binds[0].instance_id = 0;

        // see if we have an entry for start_zone. We can support both titanium & SOF+ by having two entries per class/race/deity combo with different zone_ids

        std::string query = StringFormat("SELECT x, y, z, heading, start_zone, bind_id FROM start_zones WHERE zone_id = %i "

                "AND player_class = %i AND player_deity = %i AND player_race = %i",

                in_cc->start_zone, in_cc->class_, in_cc->deity, in_cc->race);

    auto results = QueryDatabase(query);

        if(!results.Success()) {

                return false;

        }



        Log.Out(Logs::General, Logs::Status, "SoF Start zone query: %s\n", query.c_str());



    if (results.RowCount() == 0) {

        printf("No start_zones entry in database, using defaults\n");

                isTitanium ? SetTitaniumDefaultStartZone(in_pp, in_cc) : SetSoFDefaultStartZone(in_pp, in_cc);

    }

If you haven't gathered my conundrum, I will spell it out.

When the choice is made on the Titanium client, it does not choose the actual `zone_id` as the query is attempting to find. The query is incorrect for a titanium client. It "thinks" it's an SoF client, from what I can tell.

Advice?

PS. Whoever puts comments in the code, THANK YOU! It's a big help in understanding it and learning.

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.

Code:

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.

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.

Code:

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.

If I could get you to explain what you're wanting to do, I may be able to assist. Also, regardless of if you have a rule in your rule_values table or not, it has a default value in common/ruletypes.h. For this rule its default is -1: https://github.com/EQEmu/Server/blob...letypes.h#L190

Since start zones are just race, class, and deity based, I'm sure there's a way this process could be automated.

Quote:

Originally Posted by Kingly_Krab (Post 242678)

I figured it was a default set by the code. A little tongue-in-cheek. Thanks for the link to the code, I didn't get that far in my search.

I'd like to have all clients use the start_zones table regardless of client. I'm slowly working through the DB to set up something progression style. The newer zones are not available.

Is it possible my client is being identified incorrectly? At a point in the past, I was only a player and I played on P99. Could some of the files they altered affect this? More importantly, what makes this determination? Just a thought.

I appreciate your offer of assistance sir.