Z Coordinates ...

Discussions on various DOL development features

Moderator: Support Team

Z Coordinates ...

Postby Smallhorse » Sat Aug 26, 2006 11:17 am

Another issue we have left out since years are those Z-Coordinate calculations. Somewhere on the forum and on our old Wiki I have posted how it is possible to calculate the Z-Coordinates of land and water of overland maps based on the PCX images inside the packed client data. It is not very complicated at all...

The question now is, how can we use this data inside DOL most effektively?

The raw Z Data as far as I remember can be stored as unsigned short (0-65535). If we store this data for each overland zone for both land and water it will sum up to: 256 * 256 * 2 * 2 = 262144bytes for EACH Zone. In my old TOA version we have around 82 overland zones ... resulting in
21.495.808bytes of raw Z data!

Well, this might not seem too huge to be held in memory for fast access, however it is much too big to be shipped with DOL on each release. I think this data can be compressed quite well and it should lead to something below 5MB of Data when compressed.

We could provide an additional Download for DOL with this Z-Data file (since it only changes when a zone changes or a new expansion comes out) which should be quite rarely.

Or we could provide a small utility which can take in a DAOC client's zone directory and generate the Z data file on the fly. I have written such a tool some time ago (just need to find it again...) that did exactly this.

Or we could build this into the server itself and make it possible for the server to fetch the zone-data from a client at runtime or at startup (generation of the Z-Data takes around 10 seconds as far as I remember)

And if it is installed in DOL it could allow the server to use a CalculateLandZ(x,y) and CalculateWaterZ(x,y) for each arbitary point in the landscape. This would also enable the server to detect "flying" characters as well as characters that use a map-hack to travel beneath the surface...

Well, if you have other thoughts about how we could compress the stream inside memory and still have somewhat fast access then please shout out aloud :)

For Dungeon and Buildings it is more complicated. We need to define fixed Pathpoints inside buildings and connections between those pathpoints. You can imagine it as sort of a grid being laid onto walkable places in dungeons and buildings.

Whenever a mob is near a pathpoint and his target is also near a pathpoint the mob will follow the route from pathpoint to pathpoint until he meets the pathpoint closest to his target. There he can leave the path and walk directly. This works in overland-building combination too, especially good if buildings are surrounded by a small circle of pathpoints.

Imagine this: A guard is at the top of a tower, a player is standing outside the keep. The closest pathpoint of the guard is where he is standing right now, the closest pathpoint to reach the player is a pathpoint right outside the keep wall. So, the guard will walk down the stairs, walk outside the keep door, walk around the keep (not through walls) and reach the pathpoint close to the player. He will leave the pathpoints there and head straight for the player using the overland Z coordinates... After killing the player he wants to go back to the tower, so he walks to the closest pathpoint which is somewhere around the base of the keep, walk along the path, throught the front-door, up the stairs and back to his tower position.

Sounds nice no? :) Well the bad news is that I can not think of a real possibility to generate those pathpoints automatically since this would require reading the NIF files and a lot of surface calculations (eg. which point can be reached from which point).

So the only possibility is to manually define those pathpoints. Theoretically you could do this simply by making a custom script command eg. like our horse-route commands. However since pathpoints need to be interconnected and often one point needs to be connected to several other pathpoints this can get tricky... I have not come up with a solution on how to visualize those interconnections between points ingame really. If you have an idea, shout out here :)

Well thats it, just a small rumbling of me again. Not that I have time to spare, but just thought we should not forget this issue completely :)
SmallHorse
Project Ex-Administrator with too little time to be of much use currently :)
Smallhorse
Inactive Staff Member
 
Posts: 2919
Joined: Sun Jun 22, 2003 5:54 pm
ICQ: 11718314

Postby Etaew » Sat Aug 26, 2006 11:42 am

Yay Smallhorse, I'm so happy you brought this up, I've been starting to think about how to do this myself because of the guard system, and the random mob movement system.

Metty has a .dll we could use to calculate the Z, I think it might be neater in a DB, I know Holly had some ideas, as I asked him to think on the movement problem for a single path certainly.

I think we could ship that as a extra download, we could place it in the download section, and then you could add it as a dll reference in the config?

We could build it on the fly from a servers DAOC install, but the problem arises what is some servers can't install DAOC.

My thoughts for pathpoints are exactly yours, I'd be willing to set this up manually for the keeps etc, if we had a reliable means of using it, right now the pathpoint MovementMgr does not work well.

Regarding the speed of things, I'm not qualified enough to comment on such things.
Retired DOL Enthusiast | Blog
User avatar
Etaew
Inactive Staff Member
 
Posts: 7602
Joined: Mon Oct 13, 2003 5:04 pm
Website: http://etaew.net
Location: England

Postby Smallhorse » Sat Aug 26, 2006 1:08 pm

No, not the Z Data nor the calculation routines should be placed in a seperate dedicated DLL. The calculation routines should be placed inside DOL directly and the Z Data file can be provided as a seperate data file. It does not make sense putting Z Data in a database either! Don't even think about putting 20mb of byte data into a SQL database ;-)

In my opinion the Z Calculation should be in the gameserver.dll and the Z Data can be provided on per zone or per region basis.

For the Dungeons and Buildings it might be enough to provide relatively few pathpoints. For example a keep. You only need to set pathpoints around the outside walls, around the inside walls (connected through the main gate, or through more than one gate), up the stairs and around the walkway. That would be enough since then always one pathpoint is close to the monster (no matter where it is) and one pathpoint is close to the player and since all pathpoints are connected the monster can walk to the player without going through walls or jumping up without going stairs.
As said, the only trouble is when you manually need to connect the different pathpoints :)


About NIF files, dungeons etc. I found a very interesting group on SourceForge. Check this out guys:
http://niftools.sourceforge.net

They provide open source support tools and plugins to work with, edit, import and export NIF files in varous 3d Programs. Best of all even for Blender which is a free 3d Editor! With this library being able to export NIF files the question about custom DAOC content and having a full patch server available arises again eh? :) Think about making new weapons, monsters, dungeons, etc... on different shards :)

They also have a nice Render utility that can display NIF files and you move the camera around.
Attachments
NifSkope.jpg
NifSkope Screenshot
NifSkope.jpg (162.75 KiB) Viewed 7448 times
SmallHorse
Project Ex-Administrator with too little time to be of much use currently :)
Smallhorse
Inactive Staff Member
 
Posts: 2919
Joined: Sun Jun 22, 2003 5:54 pm
ICQ: 11718314

Postby Etaew » Sat Aug 26, 2006 1:18 pm

I thought we always stayed clear of the idea of modifying the client to not anger Mythic.

If we can create a set of pathpoints for a terrain component piece, we shouldn't have to repeat our work, can recreate these pathpoints based on the component piece, like we do with hookpoints and guards. I wouldn't worry about having to link pathpoints together at this stage, I would imagine it would just all be collected under 1 ID.

So 20 mb of db is too much? :-)

Only loaded into memory once, like the DLL.

<Coughs> at the other DOL dbs :-)
Last edited by Etaew on Sat Aug 26, 2006 1:19 pm, edited 1 time in total.
Retired DOL Enthusiast | Blog
User avatar
Etaew
Inactive Staff Member
 
Posts: 7602
Joined: Mon Oct 13, 2003 5:04 pm
Website: http://etaew.net
Location: England

Postby alex_speed » Sat Aug 26, 2006 1:18 pm

I'm wondering about map and z etc, why not use maps, or a tool which can reproduce usable maps by dol, this way we could get Z coordinates, out of view check, line of sight check etc.

[EDIT] I thought modifying the client is illegal, and discussing this on the board was forbidden (for users)
alex_speed
Inactive Staff Member
 
Posts: 691
Joined: Sun Nov 21, 2004 5:37 pm

Postby nor » Sat Aug 26, 2006 4:21 pm

The most user-friendly way of adding Z data is to put it all in .dll and make a folder which is read on startup. Can contain several .dlls. All Z data is found and loaded with help of meta-data. If no Z data exists server still should work, of course, the way it always worked.


About pathing... I always wanted to know how quake bots worked. Pathpoints is the most simple way to do it, but there was another way. For q2 I remember bots that generated .ass files from maps and it worked pretty good. id software even hired a guy who wrote decent bots for q1 (or was it q2?) to work on bots for q3, someone called "Mr Elusive (MrElusive@idsoftware.com)", which also has .ass files.

No details but maybe someone knows more or willing to do research.
nor
Inactive Staff Member
 
Posts: 1584
Joined: Wed Mar 03, 2004 3:56 am

Postby Etaew » Sat Aug 26, 2006 4:35 pm

Metty on Uthgard already uses a .dll for this, we can always use if we wish.
Retired DOL Enthusiast | Blog
User avatar
Etaew
Inactive Staff Member
 
Posts: 7602
Joined: Mon Oct 13, 2003 5:04 pm
Website: http://etaew.net
Location: England

Postby Smallhorse » Sat Aug 26, 2006 5:19 pm

I am really totally against having a 20mb dll full of meta data inside a compiled DLL. This is really really ugly stuff. I have looked at the DLL that passed around a long time ago and I really disliked it. The actual source code of the DLL was even bigger than 20mb because the source contained the data as array with numbers! int[] zone1 = {12312, 12312, 12312...
That is just ... ARGHL! ...

Sorry guys, I can't understand why you even think about doing this. Storing binary data in text-format which needs to be compiled to work... *sighs*

Can anyone here tell me why not incorporating the Z Code into the GameServer itself and using a simple binary data file for the actual storage?

If the file is there, fine, if the z-data file is missing, fine too, works like it does now. The difference is that a binary file can be generated/edited/read with different tools and does not need compilation and it can be edited or even removed/changed during runtime. And it can be read in partly. Zones without players would not need loading and could save memory for instance, etc. etc. etc. You can not do this if you stuff all the data in a DLL!


@alex_speed: Well, actually all the mapping software out there uses the same technique. They read the zone files and generate a more or less nice presentation of the heigh data. The only difference is that DOL does not need any beautiful data, it just needs the raw height data. It is quite easy to generate, so no need to use a different mapping software.
SmallHorse
Project Ex-Administrator with too little time to be of much use currently :)
Smallhorse
Inactive Staff Member
 
Posts: 2919
Joined: Sun Jun 22, 2003 5:54 pm
ICQ: 11718314

Postby nor » Sat Aug 26, 2006 5:28 pm

Okay, okay. Let's change ".dll" to "a file", the main idea stays - make it simple for end user and make it work without such data too. Just need to invent some way to identify to which zone data is for.
nor
Inactive Staff Member
 
Posts: 1584
Joined: Wed Mar 03, 2004 3:56 am

Postby Smallhorse » Sat Aug 26, 2006 5:34 pm

Well, making it work with or without the file is a snap. Perhaps the easiest way is to make several small files eg.

zdata/zone001.dat
zdata/zone002.dat
zdata/zone123.dat

Since we already know how a region looks like and what zones are in which reagion it is easy for the gameserver to read and assembly internal zone arrays. Would even make it easier to load/unload those arrays.

And perhaps we could even store all the data in a ZIP file /zdata.zip and the server could read files directly from the zip. The zip itself should be below or around 5mb for the whole overland zones I think. Quite easy to ship /modify and update this way.

About custom content. Well actually I think we might have thought about this the wrong way. Mythic might actually be more angry about DOL using the original content (as Etaew's post of the Sanya conversation suggests) since it is the most work to create (not the client to display it). Using custom self-made content should not be any reason for Mythic to be angry about a shard.

Actually if a shard is good, they might even ask if they can buy/license or get some models etc... or find good designers on shards this way...
SmallHorse
Project Ex-Administrator with too little time to be of much use currently :)
Smallhorse
Inactive Staff Member
 
Posts: 2919
Joined: Sun Jun 22, 2003 5:54 pm
ICQ: 11718314

Postby Etaew » Sat Aug 26, 2006 5:51 pm

We can try and talk to them again and make some inquiries maybe.
Retired DOL Enthusiast | Blog
User avatar
Etaew
Inactive Staff Member
 
Posts: 7602
Joined: Mon Oct 13, 2003 5:04 pm
Website: http://etaew.net
Location: England

Postby Etaew » Sat Aug 26, 2006 8:56 pm

Could we perhaps scan the zone files for the objects on it, i.e. the buildings and calculate the positions of doors? This would be great for filling the door database.
Retired DOL Enthusiast | Blog
User avatar
Etaew
Inactive Staff Member
 
Posts: 7602
Joined: Mon Oct 13, 2003 5:04 pm
Website: http://etaew.net
Location: England

Postby Malkavien » Sat Aug 26, 2006 9:17 pm

When i was developing a T4C (The Fourth Coming) with crystalin, i extracted coordinates (not Z, just collisions, its was a 2d game) and put it in a human reading format (bmp, in order to edit on the fly).
Its like to have zone01.dat, zone02.dat, ...
And our emulator loaded all this coordinates at startup.

So, i think the small's idea is great, and makes the futurs mythic's maps changes easier to adapt on DOL.
*Repars dans l'ombre....*

- Admin Amtenaël
- DOL Dev.

Amtenael, premier FreeShard français : http://www.amtenael.com
User avatar
Malkavien
Inactive Staff Member
 
Posts: 119
Joined: Sun Mar 28, 2004 1:53 pm
Website: http://malkasoft.fr.st

Postby Cisien » Sat Aug 26, 2006 9:32 pm

I've been working on trying to figure out how to use niftools in C# for a little while. I think corillian agreed to helping me with writing a managed wrapper, but he seems to busy/unwilling to spend some time on it...

Anyone up to the task of wrapping this dll? It would be useful in both dol and any other side projects.

If we could read the collision data from the nif's directly when the server starts, this would be the best option for dungeons, buildings, etc.
<img src="http://www.dolserver.net/portal/play/sig.php?char=Cisien&type=lait">
DAoCPortal
DOL Wiki! - Contribute!
ID List
#dolserver
#daocportal
Official DOL Test Server
Cisien
Inactive Staff Member
 
Posts: 1324
Joined: Thu Sep 25, 2003 7:46 am
ICQ: 13068487
Website: http://www.exoronet.net
Yahoo Messenger: Cisien123

Postby duff » Sun Aug 27, 2006 5:44 am

I think we can do a flexible solution that use client if installed to generate a dat file or use directely dat file if ever done.
And we can do a small tool to extract dat file.
With that, server have not to have client on the same pc but must have client somewhere ( I think all admin have daoc client on his own pc).
Vive DOL vive DAOC
Image
membre de MatrixTC :mappeur,codeur :) plus d info:http://www.halflifedesign.net
User avatar
duff
Inactive Staff Member
 
Posts: 1682
Joined: Fri Jun 20, 2003 5:27 pm


Return to “%s” DOL Development Discussion

Who is online

Users browsing this forum: No registered users and 1 guest