GunZ Private Servers (and you)

[Hymn]

I didn't see a detailed list on what each Release and what each file does in GunZ and GunZ Servers, and even more detailed, the database. I'm going to need a LOT of help writing most of this, but I will put in exactly what I personally know.



[GunZ Private Server ]
╟ [Locator]
║ ╟ [Log]
║ ╟ Locator.exe
║ ║ Not sure
║ ║
║ ║
║ ║
║ ╟ Locator.ini
║ ║ Not sure
║ ║
║ ║
║ ║
║ ╟ Locator.pdb
║ ║ Not sure
║ ║
║ ║
╟ [Match Agent]
║ ╟ [Log]
║ ╟ AgentConfig.xml
║ ║
║ ║
║ ║
║ ╟ LIST.txt
║ ║
║ ║
║ ║
║ ╟ MatchAgent.exe
║ ║
║ ║
║ ║
║ ╟ MatchAgent.pdb
║ ║
║ ║
║ ║
╟ [MatchServer]
║ ╟ [Log]
║ ╟ [Maps]
║ ║ This is the folder where the server side spawn locations are kept.
║ ║ If you add a new map to
║ ║ the game, you will need to copy the spawn location file inside of the map.mrs to here.
║ ╟ AntiCpSvr.dll
║ ║
║ ║
║ ║
║ ╟ channel.xml
║ ║ Contains the list of channels kept on your server.
║ ║ DEFAULTCHANNELNAME: Sets the channel name of an unnamed channel (I'm assuming)
║ ║ DEFAULTRULENAME: Sets the rules of an unnamed channel (also assuming)
║ ║ CHANNEL: Defines the channel list displayed on your server. They are displayed in order from first to last
║ ║
║ ╟ channelrule.xml
║ ║
║ ║
║ ║
║ ╟ cserror.xml
║ ║
║ ║
║ ║
║ ╟ dbghelp.dll
║ ║
║ ║
║ ║
║ ╟ droptable.xml
║ ║
║ ║
║ ║
║ ╟ Event.xml
║ ║
║ ║
║ ║
║ ╟ EventList.xml
║ ║
║ ║
║ ║
║ ╟ filelistcrc.txt
║ ║
║ ║
║ ║
║ ╟ formula.xml
║ ║
║ ║
║ ║
║ ╟ HackShield.crc
║ ║
║ ║
║ ║
║ ╟ hashmap.txt
║ ║
║ ║
║ ║
║ ╟ ladderstat.dat
║ ║
║ ║
║ ║
║ ╟ libcomservice2.dll
║ ║
║ ║
║ ║
║ ╟ MatchServer.exe
║ ║
║ ║
║ ║
║ ╟ messages.xml
║ ║
║ ║
║ ║
║ ╟ npc.xml
║ ║
║ ║
║ ║
║ ╟ npcset.xml
║ ║
║ ║
║ ║
║ ╟ questmap.xml
║ ║
║ ║
║ ║
║ ╟ SacraficeTable.xml
║ ║
║ ║
║ ║
║ ╟ scenario.xml
║ ║
║ ║
║ ║
║ ╟ server.ini
║ ║
║ ║
║ ║
║ ╟ server2.ini
║ ║
║ ║
║ ║
║ ╟ shop.xml
║ ║
║ ║
║ ║
║ ╟ shutdown.xml
║ ║
║ ║
║ ║
║ ╟ strings.xml
║ ║
║ ║
║ ║
║ ╟ worlditem.xml
║ ║
║ ║
║ ║
║ ╟ zitem.xml
║ ║
║ ║
║ ║
║ ╟ zquestitem.xml
║ ║
║ ║
║ ║
╟ [ServerKeeper]
║ ╟ Config_Save.txt
║ ║
║ ║
║ ║
║ ╟ Configure.ini
║ ║
║ ║
║ ║
║ ╟ dbghelp.dll
║ ║
║ ║
║ ║
║ ╟ PrepareAgentPatch.bat
║ ║
║ ║
║ ║
║ ╟ PrepareServerPatch.bat
║ ║
║ ║
║ ║
║ ╟ ServerKeeper.exe
║ ║
║ ║
║ ║
║ ╟ ServerKeeperConfig.xml
║ ║
║ ║
║ ║
Phew, lot of mindless copying. Alright, now from here we need to break this down into each file, what they are used for, what you can and cant edit in them, if they are generated autonomously, why they are there ETC... I will give you an example.

[MatchServer] -> zitem.xml
Manually Generated
zitem.xml is used to manage the ingame generation of items, and is both server and client sided. If the client sided zitem.xml turns up a different checksum (means that they do not match up perfectly) that the client will not be able to connect with the server. This was put in place so that you could not create custom items and play on a legit server.

For more specific information pertaining to zitem.xml please see (insert thread here).





I want to do that for EVERY item on that list. I would also like to do it for the databases. I think that doing this will further the gunz private server community and our understanding of the clients that we use.

[MentaL]

[RepublicOfAstra]

Not to bust your chops, but if anyone needs to know what any of these files are for, they can just... oh, I dunno... open them?

Same goes for the DB. They can just open all the procs and see what they do. If they don't know SQL, or can't at least infer what the existing code does, they shouldn't be running a Gunz server imo.

It's a good gesture, but I think it's kinda pointless.

The only things on that list that might confuse people are the PDB files. You can probably use something like dia2dump and it'll show some of the functions, etc. Only useful to programmers. I might be wrong though, I'm just going off what I've heard, I've never messed with pdb files personally.

[Hymn]

Not to bust your chops, but if anyone needs to know what any of these files are for, they can just... oh, I dunno... open them?

Same goes for the DB. They can just open all the procs and see what they do. If they don't know SQL, or can't at least infer what the existing code does, they shouldn't be running a Gunz server imo.

It's a good gesture, but I think it's kinda pointless.

The only things on that list that might confuse people are the PDB files. You can probably use something like dia2dump and it'll show some of the functions, etc. Only useful to programmers. I might be wrong though, I'm just going off what I've heard, I've never messed with pdb files personally.

Well... to be honest, I did so much hunting and pecking already that I didn't want to do, I sorta wished a list like this would exist. If not to do it to better the community, then do it to further my own knowledge of what each does.


Currently I'm redoing the entire stock zitem.xml so that it is easier to understand and add items to without screwing something else up (for instance replacing an already existing item by using the wrong item code). Also I'm going to remove a lot of the useless procs like sf="0" and such.

	<ITEM name="Iron Dagger"
		id="1010002" 
		mesh_name="dagger01" 
		type="melee"
		res_sex="a" 
		res_level="5" 
		slot="melee" 
		weapon="dagger" 
		weight="5" 
		bt_price="200" 
		delay="356"
		damage="9" 
		range="160" 
		slug_output="false"
		color="#FFFFFFFF"
		desc="Easily obtainable dagger. It was made in a factory. A faint serial number is visible on the surface."/>

Thats the generic entry I'm going to be replacing all the others with over time. Its gonna take me a few days but I'll get the whole file cataloged and looking nice and pretty.

1010001
│└┤└┴┴┴ This determines which item it is.
│ └ This determines what type of item it is.
└ This means its an item.  If it doesn't start with a 1, its not an item.

I don't understand the logic "if they don't understand 'this', then they shouldn't be doing 'that'". If the literature to learn 'this' doesn't exist, then how in the world are they supposed to do 'that'.

[RepublicOfAstra]

I didn't mean the SQL thing like that. I meant, if they don't know SQL, they shouldn't be running a server that is based entirely around SQL. That's just my opinion.

[Hymn]

I didn't mean the SQL thing like that. I meant, if they don't know SQL, they shouldn't be running a server that is based entirely around SQL. That's just my opinion.

Hell, I don't know that much about SQL, but just from the last few days, I've learned quite a bit from setting up the generic igunz client. I've learned how to hex edit ascii strings in a executable, how to change the stored icon of a executable, how to use MSSQL 2005 express...


Making it easier doesn't mean you learn less when you do this, it just makes it easier to learn. Infact, a tool like this doesn't make it easier to learn, it gives learners a thing to reference to. It doesn't walk you through it, you have to be looking for something specific to utilize a tool like this.

[-RooK-]

I have to agree with RoA, there are plenty of tutorials here in the release section that explain how to do almost everything in a server, and if there isnt, a simple question asked will solve this, there are numerous people including myself who answer almost every question asked, like RoA said, I also applaud your efforts, but this has no place

I didn't mean the SQL thing like that. I meant, if they don't know SQL, they shouldn't be running a server that is based entirely around SQL. That's just my opinion.

I very much agree

[WhiteMoga]

Well, I do say it's a noble idea, but what do you mean by getting rid of useless procedures like sf="0"

The reason those procedures are there is to execute some SQL code, and return a value to the Server.

From a programmers standpoint, it's easier to go:
int r = runproc(GunzDB, "GetPlayerID", "Buga");
'ID is now in r

Than this:
AccountDatabaseStruct Accounts;
char name[] = "Buga";
char sql[] = "SELECT UserID From Accounts WHERE User='" + name + "'";
execute_sql(sql, GunzDB, &Accounts);
int r = Accounts[0];

Especially when you need to use the same code 1 bazillion times.

It's much much easier to write the PROC once in the DB, and make it return what you want, then use it easily in the program, without all the datahandling that frankly, is a pain in the butt in C++.

If you think you can remove certain procs, you'll find you're quite wrong.

Anyways, the PDB files that are there you might as well not even attempt explaining. Learning SQL is one thing, learning how to handle program dumps is another thing, and they will find it absolutely pointless.

[Hymn]

Well, I do say it's a noble idea, but what do you mean by getting rid of useless procedures like sf="0"

The reason those procedures are there is to execute some SQL code, and return a value to the Server.

From a programmers standpoint, it's easier to go:
int r = runproc(GunzDB, "GetPlayerID", "Buga");
'ID is now in r

Than this:
AccountDatabaseStruct Accounts;
char name[] = "Buga";
char sql[] = "SELECT UserID From Accounts WHERE User='" + name + "'";
execute_sql(sql, GunzDB, &Accounts);
int r = Accounts[0];

Especially when you need to use the same code 1 bazillion times.

It's much much easier to write the PROC once in the DB, and make it return what you want, then use it easily in the program, without all the datahandling that frankly, is a pain in the butt in C++.

If you think you can remove certain procs, you'll find you're quite wrong.

Anyways, the PDB files that are there you might as well not even attempt explaining. Learning SQL is one thing, learning how to handle program dumps is another thing, and they will find it absolutely pointless.

sf="0", they removed the functionality of sf a long time ago.


No place huh? Alright, I'll find another place that will appreciate what I am willing to do.

[-RooK-]

1) I didint say you had no place, and one can copy/paste the names of the files included in botgods server files
2) It doesnt take but 30 seconds to edit the zitem to the code you posted

[Hymn]

1) I didint say you had no place, and one can copy/paste the names of the files included in botgods server files
2) It doesnt take but 30 seconds to edit the zitem to the code you posted

I understand, but when your creating and cataloging the items you have (there are reasons to create pservers besides just having every item in the game) a item database thats organized is going to do SO much better.