How can I disable tutorial zones and force a start location

[The_Architect]

Before you say to look it up I've already tried all the ways listed on the forum, they are out dated.

Could someone tell me step by step how to set all clients to skip the tutorial zones, and force them to start in POK no matter what race/class combination they chose or what client. The rules variables don't seem to work, and the start zones database doesn't work either. Everything but titanium starts in the wrong places following the guides here... Any help would be appreciated. I'm not looking to post my database info, just a guide from doing it from stock PEQ database would be most useful.

[Kingly_Krab]

There is a start_zones tables that allows you to set zone id, x, y, z, and heading. There is also a rules in rule_values for setting the tutorial zone and disabling the tutorial button., more information below.

start_zones Query (Change # to the corresponding co-ordinate):

UPDATE `start_zones` SET `x` = '#', `y` = '#', `z` = '#', `heading` = '#', `zone_id` = '#', `start_zone` = `zone_id`, `bind_x` = `x`, `bind_y` = `y`, `bind_z` = `z`

Rules in rule_values:

World:TutorialZoneID
World:EnableTutorialButton

[The_Architect]

That doesnt work. People still go to tutoriala /crescent reach on newer clients.

[Uleat]

I'll take a look at the character create/world entry code..I think there may be a value that you can compile with that will disable the button.

Been a while since I looked at that code..so, I may be mistaking it for another flag.

[Uleat]

I basically found what Kingly already provided.

Just make sure to set your 'EnableTutorialButton' to false for the rule_set that your using..all of them if you're not sure.


I did see a hard-coded value for Ti- clients..so, please post back with what clients are still going to the tutorial, if any, and we'll go from there.

[rencro]

Here is what I see with UF client:

If I have World:SoFStartZoneID as -1 and I use this sql:

INSERT INTO `variables` (`varname`,`value`,`information`) VALUES 
('startzone','poknowledge','Setting default Startzone for all clients and races to POK');

Then all my created characters will start in POK, wether "Tutorial" is enabled or not.

If lets say I set World:SoFStartZoneID to 21 for "commons"
and it reads as:

10	World:SoFStartZoneID	21	Sets the Starting Zone for SoF Clients separate from Titanium Clients (-1 is disabled)

And I restart server and create new char, i start in: POK...

Why?

Because the only rule for World:SoFStartZoneID is set to 10, and the zone commons has:

mysql> use eqemu
Database changed
mysql> select short_name,zoneidnumber,ruleset from zone where short_name = "commons";
+------------+--------------+---------+
| short_name | zoneidnumber | ruleset |
+------------+--------------+---------+
| commons    |           21 |       1 |
+------------+--------------+---------+
1 row in set (0.00 sec)

The zones "commons" is using ruleset 1, if I change the rule_values "ruleset_id" to 1 for World:SoFStartZoneID which is using rule_value 21 set earlier (commons zone) and restart server, then new chars on my UF client start in commons.

ie, the ruleset in the rule_values table needs to match what that specific zone is setup for.

The easiest solution is to use the "variables" table setting whilst leaving the World:SOF rule_value at -1, so the code will fallthrough to the variable setting.

just fyi, pok uses ruleset 2.

[The_Architect]

Thanks that worked.

[rencro]

Nice going, you got that working even though I cant spell knowledge correctly

Now that I am at home I have checked with my titanium client and the only difference is that the "tutorial" has to be unchecked, else the zone allocated to tutorial, in my case tutorialb, will be the start zone, unchecking "tutorial" has me starting in POK. This is without making any changes to the start_zones table, just the variables setting. So there is different operation based on client as to tutorial zone being used or not(My uf client will start in the declared startzone variable zone regardless of tutorial setting)

Best bet is to do as Kingly said and disable tutorial( 'EnableTutorialButton'), then use the startzone variable as I mentioned and should be set all the way around.

[Bandor]

Hate to necro an old post but im having a tad bit of a issue. I edited SQl entries and now have my clients starting in the correct zone (mesa) but not in the correct location of the zone the codes I ran were as follows:

UPDATE `start_zones` SET `x` = '-231.28', `y` = '-887.93', `z` = '184.19', `heading` = '54.8', `zone_id` = '397', `start_zone` = `zone_id`, `bind_x` = `x`, `bind_y` = `y`, `bind_z` = `z`

INSERT INTO `variables` (`varname`,`value`,`information`) VALUES 
('startzone','mesa','Setting default Startzone for all clients and races to mesa');

Like I said they spawn inMesa just not at the location in code #1

[iluvseq]

I'm having the same issue as Bandor. I have successfully forced all class/race to load into pojustice regardless of class/race/diety combo or tutorial button status, but they always appear at the safe point in zone, not at the location I configured in start_zones.

How to fix this?

[iluvseq]

Ok, here's the deal:

If you configure the startzone variable, then the start_zones table is ignored completely. Also, the starting location will be the safe point of the zone. This is hard coded.

The documentation for the start_zones table is incorrect. The way the code works, it queries start_zones using zone_id, player_class, player_deity and player_race. Most guides say to set zone_id and start_zone to the zone you want players to start in, and this is incorrect. You should instead ONLY set start_zone, leaving zone_id and player_choice set as default in the PEQ tables, otherwise the various queries against start_zone will fail and your characters will end up in the default (hard-coded by class/race for Titanium and older clients, and hard-coded to Crescent Reach for SoF and newer clients.)

Additionally, for SoF+ clients, only the x,y,z, heading and bind_id are actually pulled from the start_zones table, not the start_zone (this is probably a bug). So with the default code base, it is not possible to over-ride the start zone for SoF+ clients in any way other than using the startzone variable (which has the issue of always using the safe point of the zone).

This patch fixes that issue, so that the start_zone set in start_zones works for both Titanium and SoF+ clients.

diff --git a/world/worlddb.cpp b/world/worlddb.cpp
index 91406b5..23d6722 100644
--- a/world/worlddb.cpp
+++ b/world/worlddb.cpp
@@ -429,7 +429,7 @@ bool WorldDatabase::GetStartZoneSoF(PlayerProfile_Struct* in_pp, CharCreate_Stru
        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;
 
-    std::string query = StringFormat("SELECT x, y, z, heading, bind_id FROM start_zones WHERE zone_id = %i "
+    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);
@@ -459,8 +459,8 @@ bool WorldDatabase::GetStartZoneSoF(PlayerProfile_Struct* in_pp, CharCreate_Stru
                in_pp->y = atof(row[1]);
                in_pp->z = atof(row[2]);
                in_pp->heading = atof(row[3]);
-               in_pp->zone_id = in_cc->start_zone;
-               in_pp->binds[0].zoneId = atoi(row[4]);
+               in_pp->zone_id = atoi(row[4]);
+               in_pp->binds[0].zoneId = atoi(row[5]);
        }
 
        if(in_pp->x == 0 && in_pp->y == 0 && in_pp->z == 0)

[vsab]

Iluvseq- I've made a pull request based on your changes. There's a few changes in the way it works as well as I think really it was code that evolved over time and needed a bit of a clean up (imo).Simply, I put the start zone definitions for both Titanium and newer clients in the server_rules table rather than one in there and one in the variables table.

https://github.com/EQEmu/Server/pull/336

My home pc died literally just after making the PR so I didn't get to discuss it with the devs in IRC, but feel free to comment on the link above and try to spot any bugs. I tested it quite a bit, but I may have missed the odd scenario.

[vsab]

The method has slightly changed now and is detailed here:-
http://wiki.eqemulator.org/p?Changin...Zones&frm=Main

[iluvseq]

awesome, thanks for fixing this. One less local diff I have to re-apply whenever updating to HEAD