Crescent Reach - not using it?

[Baruuk]

Guys, is there a way to redirect new characters to their home city other than Crescent Reach when they create a new character?

I notice when I create a new toon (with SoD client) that it defaults to Crescent Reach. I've put a lot of work in folks starting in traditional home cities rather than a hub zone or everyone starting it CR. One of my goals has been to have folks revisit home cities from years ago, which are being tweaked/updated with new content - at least from lvls 1-20. After 20 - I'll open access to PoK as a hub. I've already disabled the Tutorial button. As it is, what I'm foreseeing is folks logging in and 50% of the time accidently choosing Crescent Reach as their start zone if their a SoF or higher client, which is not the intended methodology. I'm assuming this issue will only affect SoF+ clients and that Titanium users will default to their home city. I guess worst case scenario I could set the SoFStartZoneID value in rule_values to some generic location with a teleporter who has a list of starting cities to choose from, but it's clumsy. Any thoughts?

Many thanks.

Baruuk

[ChaosSlayerZ]

try to experiment with that rule.
it may be already set to Crescent Reach for some reason, and all you need to do is perhaps turn it off

[trevius]

Check the rule_values table and look at your settings for rule World:SoFStartZoneID. The notes field explains it:

Sets the Starting Zone for SoF Clients separate from Titanium Clients (-1 is disabled)

The default is -1 which is disabled, but I think PEQ has it set to Crescent Reach, so if you are using PEQ DB, you have the same setting.

[Baruuk]

So it sounds like my only recourse is to set it to a "hub" zone for SoF clients (with this setting/rule) and then have them use a teleporter from there to a starting city of their choice. Or...just leave it to CR and just do the same.

Thanks for your replies.

[trevius]

Did you try setting it to -1 as I mentioned? That should disable it so it follows the same starting cities that Titanium uses IIRC. Though, I am not sure what it will do when a Drakkin is created.

[cavedude]

Check the rule_values table and look at your settings for rule World:SoFStartZoneID. The notes field explains it:

Sets the Starting Zone for SoF Clients separate from Titanium Clients (-1 is disabled)

The default is -1 which is disabled, but I think PEQ has it set to Crescent Reach, so if you are using PEQ DB, you have the same setting.

We consider rule_values to be a player table, so the values on our SVN should be mostly default. I checked, and indeed that rule is set to -1 on SVN (is not on gameserver though, of course.)

[Baruuk]

Well - I think I'm at an impass. I simply can't prevent SoD clients from creating characters that default to starting in crescent reach. I've changed and rechanged the World:SoFStartZoneID value to -1. I've even changed it to another value (1, 5, etc) and it sends SoF/SoD clients to the appropriate zone - so that's working as intended. However, when I change it to -1 (which it was originally), when I create a character with my SoD/Underfoot client it still displays Crescent Reach as the default selection for starting city (for every race/class combo) and then sends me to Crescent Reach. It's very strange. I've disabled the Tutorial Button - that works properly. I also tried setting the minstatus to CR to 250 - which of course results in it sending my new character to the Arena.

I'm open to suggestions - and thanks in advance for those. I was really trying to avoid using a hub zone for starting characters - and had put some work into putting merchants, quests, etc in cities like Qeynos, Rivervale, Grobb, etc but since half my clients or more will probably be SoD - there's nothing stopping them all from going to Crescent Reach.

Am I missing something obvious?

Thanks.

[louis1016]

I've done this a few months ago. I had to go in the server code and delete crescent reach as a starting point for each race/class and it did not show up on character creation screens anymore. I'm trying to find where its at now but im having difficulty finding it. Try looking around yourself in the code for now and when I find it i'll post it

[Congdar]

in \world\SoFCharCreateInfo.h
remove the entries for crescent to remove the choice of crescent reach

[robinreg]

\world\SoFCharCreateInfo.h has been changed with rev2024 as it's now part of the DB in the table "char_create_combinations".

[Baruuk]

Good tip. I'm almost there. I've updated to 2024 and now have that table in my database. That really will solve my problem. I could simply just delete the rows manually for other races other than Drakkin. However, I wanted to try a SQL statement but I'm getting a syntax error. Probably something simple:

DELETE * FROM 'char_create_combinations' where start_zone = 394 AND allocation_id < 94;

Strangely enough, a select statement of the same thing works fine:

SELECT * FROM `char_create_combinations` WHERE start_zone = 394 AND allocation_id < 94;

*** Nevermind - I realized I could simply use the SELECT statement above and then just delete the resultant rows.

Thoughts?

[Baruuk]

Strange - well, after removing all entries in the char_class_combinations table for zone 394 (Crescent Reach) except for race 522 (drakkin), I restarted the server and then created a new character expecting it not to display Crescent Reach or at least not let me create a character there. Unfortunately that didn't do it. My new dark elf SK started right in CR again. I verified those rows are now gone from the table. Is it controlled elsewhere?

[Robregen]

I used to be able to disabled them prior to rev2024 with \world\SoFCharCreateInfo.h as well as starting in the new revamp freeport. I haven't look into it as I am working on other project. I'll take a look at it when I have the time.

[Baruuk]

No problem at all -thanks for your input gents. I didn't recompile or anything - I simply updated the database from all SQL files 2000+ after re-sourcing the "source" folder.

[lerxst2112]

I didn't recompile or anything.

What version of the server code are you running then? If it isn't the version that reads the table from the database then it isn't surprising that editing the table had no effect.

BTW, the correct syntax for delete in MySQL is 'delete from <table_name> where <something>'. I sometimes forget to remove the * when I switch from a select to delete as well. :)

[Baruuk]

Well - if I'm looking in the right place, when I launch World.exe it says EQEmulator 0.8.0. The log file references eqemu_debug_world_3384.log. Is there another way of determining the server code I'm using? I'd be happy to go back to the guide and redownloaded the entire package and recompile.

[joligario]

http://code.google.com/p/projecteqemu/updates/list

[Baruuk]

Okay - not to sound like an absolute retard, but I went to that link and see the update history (wow! I had no idea it got updated that often)...I see where you go to Downloads and get the Rev2022-Bots.zip (in my case I use bots), but what's the procedure for updating your server? Do I just unzip and overwrite files and then import SQL changes or right click my SVN folder (C:\source) and update there and then recompile? I'm going to search forums again to make sure I haven't missed something in the meantime.

Edit: I just found http://www.eqemulator.net/wiki/wikka.php?wakka=ProjectEQSVN on the wiki. It looks a tad old, but in regards to updating, do you have to recompile every time a new release comes out (looks quite often), or is overwriting or updating those folders enough?

One more update - In the interests of helping myself and not bugging you further, I'm resourcing everything via SVN into a separate folder right now. It looks like it's revision 2050. Mine was from 9/19. I'll simply follow the procedure for compiling, etc from scratch.

Thanks.

[revloc02c]

You do have to re-compile every time you want an update applied to your server.

I can't stress this enough, backup before you do (this applies to every digital piece of information you have control over--not just EQEmu). If you have a working server make a backup copy somewhere of the entire server folder. That way if anything goes wrong you can always roll back. (I know backing up is the most basic idea, but I know plenty of veterans that sometimes make this mistake, me included. I can count the number of times that backups have saved me a ton of grief. Just sayin.)

[Baruuk]

Understood. I've copied the entire c:\eqemu folder somewhere else. I actually have a VMware image of the server from yesterday as well. So if you don't have to recompile every time there's an update...does simply downloading the ZIP file for the latest update, copying then contents over your existing files (world.exe, eqlaunch.exe, etc) suffice? It's the process for successfully updating to a new version that I'm cloudy on.

[revloc02c]

does simply downloading the ZIP file for the latest update, copying then contents over your existing files (world.exe, eqlaunch.exe, etc) suffice?
I assume you are referring to this zip file that you mention in you earlier post:
EQEmu-Rev2022-Bots.zip
I have actually never done it that way, so personally I am not sure if that works. Probably does. Anyone?

My process for applying updates:
1) Backup.
2) Right click C:\EQEmu\EQEmuSource folder and select "SVN Update" and get the latest stuff (I have obviously installed Tortoise SVN, for anyone scratching their head).
3) Open MS Visual C++ 2008 Express and recompile as outlined in this thread: http://www.eqemulator.org/forums/showthread.php?t=32293 (I do have some custom C++ code that I want included in the update, that's why I re-compile from "scratch" so to speak.)
4) For me I go here: C:\EQEmu\EQEmuSource\trunk\EQEmuServer\Build and copy the .exe files, and the .dll file to my main server folder (this is also outlined in the above linked guide).

In fact, I need to do this again soon, so I'll complete the process and edit this post if I remember something else.

[Baruuk]

Thanks much - greatly appreciated. Yah I went ahead and did exactly what you just outlined while I was waiting for reply. I resourced (into a different folder out of sheer paranoia) using Tortoise SVN and then recompiled. I'll go ahead and copy the EXEs and DLL into the EQEMU folder and see how things go. I just wasnt sure if there was some other procedure for updating. You have sparked my curiosity into modifying the source code itself. Mind if i ask what types of customizations you have done in yours?



EDIT: Quick update - excellent news! By updating the server code and now having the latest PEQ database revisions I can now verify that Crescent Reach is no longer an option as a character starting city in the SOD client, with the exception of Drakkin. Thank you all for your input and assistance.

[revloc02c]

Good, glad you got it working.

I can go over some stuff I did in the C++ code (nothing fancy) but not now. It may take a few days, but I'll get to it this week (I hope :) ).

[revloc02c]

Ok, Baruuk here's something I am doing:

File Path: C:\EQEmu\EQEmuSource\trunk\EQEmuServer\zone\exp.cp p

Description: Changed the way exp is calculated


else if (check_level < 62) //added additional steep mod (basically double exp required each new level) revloc02-24Aug2011
mod = 5.56;
else if (check_level < 63)
mod = 8.33;
else if (check_level < 64)
mod = 12.5;
else if (check_level < 65)
mod = 18.75;
else if (check_level < 66)
mod = 28.12;
else if (check_level < 67)
mod = 54.6;
else if (check_level < 68)
mod = 81.9;
else if (check_level < 69)
mod = 122.85;
else if (check_level < 70)
mod = 184.28;
else if (check_level < 71)
mod = 276.41;
else if (check_level < 72)
mod = 560;
else if (check_level < 73)
mod = 840;
else if (check_level < 74)
mod = 1260;
else if (check_level < 75)
mod = 1890;
else
//mod = 3.1;
mod = 2835;

//float base = (check_levelm1)*(check_levelm1)*(check_levelm1);
float base = pow (check_levelm1, 2.74); //changed exponent revloc02-24Aug2011

//mod *= 1000;
mod *= 10; //changed mod from 1000 to 10 revloc02-29Aug2011




Something else I did is already posted here: http://www.eqemulator.org/forums/showthread.php?t=32664

Cheers