PDA

View Full Version : Watermaps


cubber
01-17-2008, 05:08 AM
How do we enable these? I downloaded the .wtf files and extracted them into my maps folder. I noticed that all the rules are set to false, where do I change this so they are enabled on my server? Can it be done in the web interface? Or do I need to recompile my server with the values all set to true in ruletypes.h?

cavedude
01-17-2008, 05:19 AM
Just change the rule values to true in your db.

cubber
01-17-2008, 05:24 AM
I am using the latest peq CVS and do not see those values in the rules_values table. Was there a mysql update I was supposed to run also?

cubber
01-17-2008, 06:30 AM
Ok i think i see my issue. When I load the newest CVS peq I always just do a drop_system and a load_system, never drop_player load_player.

It looks like the rules_values and other variable tables are only dropped and loaded with the character tables. So I must be still be using some old tables that only get dropped and added with the player scripts.

So my question is how do I update all of these tables without loosing any of my character data?

Angelox
01-17-2008, 07:36 AM
You can find rules in the download logs at EqEmu. just read and apply whatever rules you see fit

cubber
01-17-2008, 08:05 AM
Thanks for your reply,

I saw the rules in the logs, but do not see them anywhere in my DB. So I have no place to change the values. As I have stated I am running the latest peq CVS as of I believe 7 days ago. I figured these rule values should already be in that DB somewhere. Hopefully Cavedude will be able to shed some light on my db questions in my previous post.

cavedude
01-17-2008, 08:26 AM
No, it's outdated a bit. Give it a few days, and the whole db will be updated on CVS, including all of the rules.

cubber
01-17-2008, 08:29 AM
Thank you!

Angelox
01-17-2008, 10:17 AM
Here's all my rules, you should be able to take and use what you want;
INSERT INTO rule_sets VALUES (0,"default");

INSERT INTO rule_values VALUES (0,"Character:AutosaveIntervalS","300");
INSERT INTO rule_values VALUES (0,"Character:CorpseDecayTimeMS","10800000");
INSERT INTO rule_values VALUES (0,"Character:DeathExpLossLevel","6");
INSERT INTO rule_values VALUES (0,"Character:EnduranceRegenMultiplier","100");
INSERT INTO rule_values VALUES (0,"Character:ExpMultiplier","1.0");
INSERT INTO rule_values VALUES (0,"Character:HPRegenMultiplier","100");
INSERT INTO rule_values VALUES (0,"Character:LeaveCorpses","true");
INSERT INTO rule_values VALUES (0,"Character:LeaveNakedCorpses","false");
INSERT INTO rule_values VALUES (0,"Character:ManaRegenMultiplier","100");
INSERT INTO rule_values VALUES (0,"Character:MaxLevel","65");
INSERT INTO rule_values VALUES (0,"Combat:BaseCritChance","0.0");
INSERT INTO rule_values VALUES (0,"Combat:BerserkBaseCritChance","0.06");
INSERT INTO rule_values VALUES (0,"Combat:NPCBashKickLevel","6");
INSERT INTO rule_values VALUES (0,"Combat:WarBerBaseCritChance","0.03");
INSERT INTO rule_values VALUES (0,"GM:MinStatusToZoneAnywhere","200");
INSERT INTO rule_values VALUES (0,"Guild:MaxMembers","2048");
INSERT INTO rule_values VALUES (0,"Pets:AttackCommandRange","150");
INSERT INTO rule_values VALUES (0,"Skills:MaxTrainTradeskills","21");
INSERT INTO rule_values VALUES (0,"Spells:BardSpellAggroMod","3");
INSERT INTO rule_values VALUES (0,"Spells:PetSpellAggroMod","10");
INSERT INTO rule_values VALUES (0,"Spells:SpellAggroModifier","100");
INSERT INTO rule_values VALUES (0,"World:ClientKeepaliveTimeoutMS","65000");
INSERT INTO rule_values VALUES (0,"World:ZoneAutobootTimeoutMS","60000");
INSERT INTO rule_values VALUES (0,"Zone:GraveyardTimeMS","1200000");
INSERT INTO rule_values VALUES (0,"Zone:EnableShadowrest","0");
INSERT INTO rule_values VALUES (0,"Map:FixPathingZWhenLoading","true");
INSERT INTO rule_values VALUES (0,"Map:FixPathingZAtWaypoints","true");
INSERT INTO rule_values VALUES (0,"Map:FixPathingZWhenMoving","true");
INSERT INTO rule_values VALUES (0,"Map:FixPathingZOnSendTo","true");
INSERT INTO rule_values VALUES (0,"Watermap:FishingLineLength","40");
INSERT INTO rule_values VALUES (0,"Watermap:CheckForWaterWhenFishing","30");
INSERT INTO rule_values VALUES (0,"Watermap:CheckForWaterOnSendTo","false");
INSERT INTO rule_values VALUES (0,"Watermap:CheckForWaterWhenMoving","false");
INSERT INTO rule_values VALUES (0,"Watermap:CheckForWaterAtWaypoints","false");
INSERT INTO rule_values VALUES (0,"Watermap:CheckWaypointsInWaterWhenLoading","true");

Derision
01-17-2008, 11:02 AM
INSERT INTO rule_values VALUES (0,"Watermap:CheckForWaterWhenFishing","30");



That rule should be true or false, e.g.


INSERT INTO rule_values VALUES (0,"Watermap:CheckForWaterWhenFishing","true");

cubber
01-18-2008, 01:28 AM
Thanks for that post Angelox! That should be helpful to a lot of people.

cubber
01-31-2008, 05:40 AM
Cavedude,

I just updated to the latest PEQ CVS and noticed that my rules_values table is still identical to what it was before. When I update I just do drop_system.sql then load_system.sql, I noticed that when doing drop system I still have to comment out aa_swarmpets and merchantsets in order for it to complete without error. Then when I do a load_system.sql I have to comment out merchantsets because it still tries to load it even though it is not in cvs anymore.

Are these scripts going to get updated? Also how is rules_valuse supposed to get updated out of CVS if it is only included in the load_player script? If I have a db that I am updating I do not want to drop_player , load_player to get the new rules_values table cause I would loose all of my player data.

Can I just do a mysql -u root -p -v -D eqemu < rules_values.sql to get my whole DB up to date after I do a load_system.sql?

cavedude
01-31-2008, 06:06 AM
No, those scripts will not be updated because those tables are no longer needed and people still have them. Data in this community has the way of sticking around, and confusing people years later, so this is my way of purging the system ;) Just source with verbose mode off (drop the -v) and it'll skip right past them. *Releases will not have this issue, only tables contained in the release will be sourced/droped*

rule_values is a player script because it is a table commonly changed by the end user. Having it as a system table would piss people off with tweaked rulesets. Having a third category is not an option because I am too lazy to update PEQ's script, and quite frankly having two scripts confuses many people as is, adding a third would make matters worse.

Yes, any and all tables can be sourced in separately. rule_values, commands, variables, etc. I don't recommend doing this for system tables because obviously many tables are linked together, so sourcing in one without the other will create errors and/or features to not function.

cubber
01-31-2008, 06:22 AM
Thanks for the reply, it is understandable that you want to cause as little confusion as possible.

So if I understand you correctly... If I just source in the new rules_values.sql to my updated database, I will be good to go with a fully updated database without any issues? If I made any changes to my old rules_values table I obviously will have to go back and make those changes again because they will get reset to default.

But sourcing in anything that is in the load_system.sql file by itself will cause problems...

I just want to be clear before I do this to my year old database.

cubber
01-31-2008, 07:10 AM
One other question, I noticed that tables like variables and commands have been updated as well. Is it worth updating these to the newest revisions also or are the updates mostly comments and such? If so a list of tables that are considered "player scripts" that should be watched for changes and updated manually would be helpful.

Thanks again for your help!

cavedude
01-31-2008, 08:02 AM
Yep, you are completely correct.

The only player table that would see any real updates is rule_values. commands, launcher, launcher_zones, rule_sets and variables are tables that are also easily changed, but they won't be updated by PEQ. They are all pretty much one time setup tables.

cubber
01-31-2008, 08:13 AM
Just to be 100% clear and to sum up the thread to mark it solved:

So whenever I update the database via cvs by using load_system.sql, I can also safely update the following tables manually without any repercussions on my character info or my system as long as I take note of any values that I modified and reapply them accordingly?

rule_values
commands
launcher
launcher_zones
rule_sets
variables

I take it that I need to drop the old table first then source in the new ones?

Thanks for clarifying this

cavedude
01-31-2008, 08:29 AM
Yep, that's correct. If I were to make a third sql script, those would be the exact tables within in. I've fiddled with the idea of having system, player, and variables scripts, but as I said the third script may put many noobs over the top.

You don't actually need to drop the tables before hand, either. The sql files will drop the table if it exists, re-create the table, and source the data for you.

So, you'd first source drop_system.sql, then load_system.sql, then rule_values.sql, variables.sql, etc. Make sure you don't have -v when you run mysql so any errors will be ignored and flipped past. -v is only good when you're merging, creating new queries, or if you are having problems sourcing. Otherwise, it's best to leave it out.

cubber
01-31-2008, 08:37 AM
Thanks. I did not realize that for the -v option. Every guide I have used always threw that flag in so I just went with it. I bet the sourcing is quicker without the verbose flying across the screen too.

cubber
01-31-2008, 08:43 AM
So the 3rd script would probably look something like this?



source rule_values.sql;

source commands.sql;

source launcher.sql;

source launcher_zones.sql;

source rule_sets.sql;

source variables.sql;

cubber
01-31-2008, 09:31 AM
I named that script update_variables.sql and ran it in the cvs directory. It worked perfectly. A few key things to note to those that try it:

You will have to Insert LoginType into the variables table again and set it to MiniLogin if you are using minilogin. I found that this entry was not in the new table.

I also had to rename zone in the launcher table to the name of my launcher that my start script calls. I guess you could also change the name in your start script to zone if you wanted.

and I had to adjust a few values in rules_values to get them back to the way I had them.

I guess if you changed any of the values in the commands table you would need to go back and edit that again too. PHPMyAdmin and a printer really help!

cavedude
01-31-2008, 10:28 AM
You will have to Insert LoginType into the variables table again and set it to MiniLogin if you are using minilogin. I found that this entry was not in the new table.


Forgot about that! I cleaned up the variables table some, and added some missing variables, including that one. That'll appear the next time I update CVS.

circuitdragon
01-31-2008, 12:46 PM
I really hope I am not going to cause any more confusion here, but just a few quick questions. I have made CVS as my way of getting updates for PEQ. Now, maybe I am over working myself on this here, but I skip the "drop_system", "Load_system" and such, and instead only source the sql's that have a newer time stamp. Thus far its not had any issues, just trying to figure if I have made bad habits. :) Next question is, which is better, to download the PEQ databse from ProjectEQ's site, or...is the CVS the newest possible in any scenerio?