How do I stop players from spawning in Crescent Reach?

[Lucia Moore]

I don't even see it as an option in the start_zones table!

I changed it so that players start in the old Freeport rather than the new one, and now they spawn in Crescent Reach whenever you try to create one in Freeport!

[Nydosa]

Titanium clients will spawn wherever it says in startzone in the Variables table. There are also start zone variables in rule_values.

[Lucia Moore]

I don't see anything in rule_values or variables that lets me select player start zones.

[rencro]

Its a custom rule..

To enable it you need to insert it into your db..

If you set SOFstartzone to -1 and remove the tutorial option then whatever you set in the "variables" table for startzone will send "everybody" there, to the zones safe coords..

ie...


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

UPDATE `rule_values` SET `rule_value`='false' WHERE `rule_name` = 'World:EnableTutorialButton';


This assumes that the result of this query is -1



SELECT * from `rule_values` WHERE `rule_name` = 'World:SoFStartZoneID';

[Lucia Moore]

Its a custom rule..

To enable it you need to insert it into your db..

If you set SOFstartzone to -1 and remove the tutorial option then whatever you set in the "variables" table for startzone will send "everybody" there, to the zones safe coords..

ie...


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

UPDATE `rule_values` SET `rule_value`='false' WHERE `rule_name` = 'World:EnableTutorialButton';


This assumes that the result of this query is -1



SELECT * from `rule_values` WHERE `rule_name` = 'World:SoFStartZoneID';


That's fine and all, but I'm not having trouble with players starting in the Mines of Gloomingdeep. I took care of that already. I'm having problems with players being able to start in Crescent Reach, an entirely different zone.

Also, I'm getting an issue where new players that pick "East Freeport" or "West Freeport" on the character creation menu start in Crescent Reach.

[rencro]

errr. you can put whatever zone name you want there, and my example is tutorial A not B, because thats where I send players too, remember tutoriala, the small jail cell where you first meet Arias and have to kill the kobold.......Again if you want Crescent Reach, put Crescent Reach...Put whatever you want, sorry if I wasnt clear...

[rencro]

Another example:


INSERT INTO `variables` (`varname`,`value`,`information`) VALUES
('startzone','farsideofmoon','Setting default Startzone for all clients and races to the Far Side of the Moon zone');

[Lucia Moore]

errr. you can put whatever zone name you want there, and my example is tutorial A not B, because thats where I send players too, remember tutoriala, the small jail cell where you first meet Arias and have to kill the kobold.......Again if you want Crescent Reach, put Crescent Reach...Put whatever you want, sorry if I wasnt clear...

*SIGH*

Maybe I'm the one that's not being clear...

I do not want players to spawn in Crescent Reach. At all. Ever.

I went through and replaced all of the starting zone entries that pointed to the new Freeport to Zone ID 9, which is freportw, the old classic Freeport.

When I create a new human warrior, even if I pick East Freeport, the new character starts in Crescent Reach. I do not know why they are starting there or how to make them start where I told them to start.

[rencro]

Apologies...Have you shut down and restarted the server after making your db changes?

If so, perhaps there is an issue in your tables as the server will default you to Crescent Reach if it cant find good info in the db:


{
LogFile->write(EQEMuLog::Status, "Found starting location in start_zones");
in_pp->x = atof(row[0]);
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]);
}
else
{
printf("No start_zones entry in database, using defaults\n");

if(in_cc->start_zone == RuleI(World, TutorialZoneID))
in_pp->zone_id = in_cc->start_zone;
else {
in_pp->x = in_pp->binds[0].x = -51;
in_pp->y = in_pp->binds[0].y = -20;
in_pp->z = in_pp->binds[0].z = 0.79;
in_pp->zone_id = in_pp->binds[0].zoneId = 394; // Crescent Reach.
}

}

[Lucia Moore]

That's the thing, I don't THINK there's an error. I changed the start_zone and zoneid fields from 382 (or 383) to 9 and got the xyz coordinates from in-game. There's no reason I can think of why players shouldn't be able to spawn there.

[Kingly_Krab]

You can use this to see how your rules are set, these must be set to the zone you want people to start in.
SELECT * FROM rule_values WHERE rule_name IN ("World:SoFStartZoneID", "World:TutorialZoneID");
You can also use this query to mass update everystart_zone to the same X, Y, Z, Heading, and Zone ID, just in case they're not all set to the same thing.
UPDATE start_zones SET x = 'VALUE', y = 'VALUE', z = 'VALUE', heading = 'VALUE', zone_id = 'VALUE', start_zone = zone_id, bind_x = x, bind_y = y, bind_z = z;

[Lucia Moore]

You can use this to see how your rules are set, these must be set to the zone you want people to start in.
SELECT * FROM rule_values WHERE rule_name IN ("World:SoFStartZoneID", "World:TutorialZoneID");
You can also use this query to mass update everystart_zone to the same X, Y, Z, Heading, and Zone ID, just in case they're not all set to the same thing.
UPDATE start_zones SET x = 'VALUE', y = 'VALUE', z = 'VALUE', heading = 'VALUE', zone_id = 'VALUE', start_zone = zone_id, bind_x = x, bind_y = y, bind_z = z;

My start zones are set, the problem is the server is kicking people into Crescent Reach if I try to get them to spawn. My only assumption is that I screwed something up, but I can't for the life of me determine what it was.

[rencro]

By chance is the "tutorial" button enabled when the character is created, I assume you may have reassigned the tutorial zone to 0 and its trying to send your characters to tutorial, but when it cant find a proper zone id it craps out to its last choice which is Crescent Reach. Perhaps try disabling the tutorial button as well..

I built a new peq today, and created a human agnostic monk. If I have tutorial enabled, world will spit out:


No starts_zones entry in database, using defaults

Then I start in tutorial zone which is tutorialB

Then created new human agnostic monk and unclicked tutorial:

Found starting location in start_zones


And it puts me in qeynos2 as it should

What does your world report after creating new chars, and by chance have you changed the WorldTutorialZoneID?

[Lucia Moore]

By chance is the "tutorial" button enabled when the character is created, I assume you may have reassigned the tutorial zone to 0 and its trying to send your characters to tutorial, but when it cant find a proper zone id it craps out to its last choice which is Crescent Reach. Perhaps try disabling the tutorial button as well..

I built a new peq today, and created a human agnostic monk. If I have tutorial enabled, world will spit out:


No starts_zones entry in database, using defaults

Then I start in tutorial zone which is tutorialB

Then created new human agnostic monk and unclicked tutorial:

Found starting location in start_zones


And it puts me in qeynos2 as it should

What does your world report after creating new chars, and by chance have you changed the WorldTutorialZoneID?

It looks like people are reading the replies to my post without actually reading what I typed.

People aren't spawning in the tutorial zone, they're spawning in Crescent Reach when I choose to spawn in Freeport.

This issue only happens when I try to have someone spawn in the OLD Freeport. Spawning in Qeynos works just fine for human characters, but any time I pick either West Freeport or East Freeport off of the list of starting zones, I spawn in Crescent Reach instead. The tutorial button is not clicked.

To reiterate: I changed all of the start_zone entries that were aimed at the NEW Freeport zones to the OLD Freeport zones, and I updated the XYZ coordinates to a valid location. Attempting to start in Freeport instead spawns players in Crescent Reach. There is no server error feedback indicating why this is happening, and I cannot find anything in the start_zones entries pointing to Crescent Reach either.

[rencro]

FFS read what IIIIIIIII IIII TYPE....

Im done with you

[Kingly_Krab]

Are you sure the client you're using has the old zones? Would you mind using #zone to go there and see if it works, if it doesn't, that's why it's putting you in Crescent Reach, if you can go there, the problem lies elsewhere.

[Lucia Moore]

FFS read what IIIIIIIII IIII TYPE....

Im done with you

The attitude is entirely unwelcome. If you're going to get angry, please don't bother responding to me. I can wait for someone that's not going to lose their temper to assist me. Furthermore, I did read what you typed, but it doesn't apply to my problem. I guess I can quote the part that doesn't apply, if that helps?

By chance is the "tutorial" button enabled when the character is created, I assume you may have reassigned the tutorial zone to 0 and its trying to send your characters to tutorial, but when it cant find a proper zone id it craps out to its last choice which is Crescent Reach. Perhaps try disabling the tutorial button as well..

You assume incorrectly. I never modified the tutorial zone settings. I would never set a zone setting to 0, because I'm well aware that could cause a big problem. As I've said several times, the only zone settings I've changed were changing 382 and 383 to 9. That's it. I never touched any other settings regarding zone ID numbers. That's why I'm confused as to why it's defaulting to Crescent Reach.

As per the piece of code you quoted earlier:


in_pp->x = atof(row[0]);
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]);

All of those values in my DB are valid. There's no reason the code should hiccup and default to Crescent Reach.

Are you sure the client you're using has the old zones? Would you mind using #zone to go there and see if it works, if it doesn't, that's why it's putting you in Crescent Reach, if you can go there, the problem lies elsewhere.

I can zone there as a GM with no problem, and the zone is fully populated and functional. That's how I got the spawn coordinates and heading. I went there and used the #loc command (not to be confused with /loc).

[Lucia Moore]

Update

Okay, I'm getting an error message now (or, at least, I'm looking at the correct window now) and I can see what's screwing up, but have no idea why, unless it's something hardcoded into the client or server?


[Status] SoF Start zone query: SELECT x,y,z,heading,bind_id FROM start_zones WHERE zone_id=383 AND player_class=2 AND player_deity=204 AND player_race=1

No start_zones entry in database, using defaults


So, if I changed that start zone entry in the database to 9, and I have the whole "separate SoF start zone" rule disabled, why is it still looking for a 383 entry in the database?

[Kingly_Krab]

Can you post some pictures of your rule_values and start_zones settings perhaps?

[Lucia Moore]

Can you post some pictures of your rule_values and start_zones settings perhaps?

Sure.

http://i.imgur.com/5oExaqE.png
There's the relevant part of my rules. As you can see, I have SOFStartZoneID set to -1, so the server shouldn't care if the player is using an SOF+ client or a Titanium client.

http://i.imgur.com/ulEPyqS.png
These were all previously set to either 382 or 383 (the newer Freeport zones). I changed them all to 9 (freportw, the classic West Freeport).

As I indicated above, I am receiving an error output from my server because, for some reason, it is still trying to spawn players in zone 383, and is erroring out because it cannot find an entry for 383, which make sense, because I removed it, because I don't want players spawning in 383.

An idea just occurred to me...

There are two entries...a zone_id, and a start_zone....which one of those ACTUALLY controls where you spawn? Is it possible that start_zone is just what the server looks for, but zone_id is the actual zone it attempts to spawn you in?

Edit: Nevermind, that's not it. zone_id is what it looks for AND where it spawns you. I just checked. So the real question is WHY is it asking for 383? Is the CLIENT asking for 383? If so, how do I change that? I don't want ALL of my players spawning in the same zone, so using that sort of workaround isn't really acceptable.

[Kingly_Krab]

Here is what my settings look like:

Rule Values:
http://i.imgur.com/VtujPC1.png

Start Zones:
http://i.imgur.com/PezjdS7.png

[rencro]

Some "people" dont appreciate being referred to as "people" when said "person" is trying to help, instead they get this rude note,


It looks like people are reading the replies to my post without actually reading what I typed.


and then none of the instructions given were followed, except later in your UPDATE post , you seemed to have woken up...


Okay, I'm getting an error message now (or, at least, I'm looking at the correct window now)


You know its not very easy giving support to others when you have no clue what they have done on their end, so we must ask for bits of info to help us determine whats going on, but you have the attitude throughout all your post that:


You assume incorrectly. I never modified the tutorial zone settings. I would never set a zone setting to 0, because I'm well aware that could cause a big problem.


So you already know all the answers and my pesky probing is bugging you, so I will stop bugging you....

[Lucia Moore]

Some "people" dont appreciate being referred to as "people" when said "person" is trying to help, instead they get this rude note,



and then none of the instructions given were followed, except later in your UPDATE post , you seemed to have woken up...



You know its not very easy giving support to others when you have no clue what they have done on their end, so we must ask for bits of info to help us determine whats going on, but you have the attitude throughout all your post that:



So you already know all the answers and my pesky probing is bugging you, so I will stop bugging you....

I didn't intend to offend you, and clearly I have, so I apologize. I can assure you that trying to fix this issue is as frustrating for me as my responses are to you. I understand that you're trying to help, and I appreciate it. I feel that it's as much my fault for being unfamiliar enough with EQEmu to provide the information needed for proper troubleshooting.

This seems like a really stupid problem to have, and simply changing the start_zone should work, but it doesn't, and I'm at a loss as to why specifically because I'm new to this and don't have all of the answers.

Kingly_Krab
You seem to have everyone spawn in the same zone, though. That's fine, but what I want to do is simply make it so that newbies start in the old Freeport instead of the new one, and I'm starting to suspect that it may require a source code change to do that. I still don't know why my server is still saying "WHERE zone_id = 383", but that's why it's not working. It's still looking for the Freeport revamp, and when it fails to find that, it defaults to Crescent Reach.

[demonstar55]

What client are you using? I know on live you can no longer start in anywhere but CR, and I'm not sure if RoF acts like this and it could be causing problems?

[Kingly_Krab]

Last resort question, did you restart your server or #reloadallrules after doing all of this? Or are you doing it live without reloading or anything?

[Furniture]

char_create_combinations table is what your looking for, change that plus the start_zones table

[Kingly_Krab]

char_create_combinations table is what your looking for, change that plus the start_zones table
Ah yes, there is start zone there; however, I have no idea why it would override the rule value.

[Lucia Moore]

Last resort question, did you restart your server or #reloadallrules after doing all of this? Or are you doing it live without reloading or anything?

I have restarted my server enough that if I was getting a dollar each time I did it, I could retire from my day job :D

[Kingly_Krab]

I have restarted my server enough that if I was getting a dollar each time I did it, I could retire from my day job :D
Haha, that's great.

[Uleat]

Here is the code that processes the create character zone selection: https://github.com/EQEmu/Server/blob/master/world/client.cpp#L1473

I don't have a database in front of me or I'd trace the logic...

[Lucia Moore]

Ah yes, there is start zone there; however, I have no idea why it would override the rule value.

I don't think it's overriding anything, but that could be where that anomalous "383" zone_id value is coming from. I'll try changing it and see what happens.

Edit: Also, would expanding that table allow clients to perform more race/class combinations at character creation?

[Kingly_Krab]

I don't think it's overriding anything, but that could be where that anomalous "383" zone_id value is coming from. I'll try changing it and see what happens.

Edit: Also, would expanding that table allow clients to perform more race/class combinations at character creation?
Yes, if you edited it and the allocations table. You may not have 'Tutorial' selected; therefore, it's sending you to Crescent Reach and not your set zone.

[Lucia Moore]

Success!

Changing the value in the char_create_combinations table fixed the issue! That's where the server was pulling that value from!

Thanks Furniture!

And thanks Kingly_Krab, too! I will experiment with more race/class combinations next!

[Furniture]

Are you able to get humans with underfoot to spawn in old west freeport? I am trying this now and Im having issues.

[Lucia Moore]

Are you able to get humans with underfoot to spawn in old west freeport? I am trying this now and Im having issues.

Yes, I am!

What I did was change the entry in char_create_combinations to 9, then changed the same values to 9 in start_zones, along with providing the correct xyz coordinates.

The trick is that it searches for an entry in start_zones that matches the entry found in char_create_combinations. Those two have to match.