[Tool] edxNVMViewer Beta

[pushedx]

About

This is just a tech demo of a side tool I am working on for another project. It is not finished yet and it might have some bugs still (which is why it'd be nice if you can test it!). The camera placement code for new regions is not perfect as you will spawn looking under terrain sometimes. This is because the terrain center might be below the average height of the surrounding terrain. Also, it is kind of hard knowing where you are in the map since there is no GUI, so common locations have been provided to give you a point of reference. Only the terrain information from the NVM files are being displayed. I still have to add the other data.

What is special about this project is I have updated a lot of my old code to use PK2 data directly via my PK2API code so no additional data files are needed with the program. This is obviously a big benefit since there are thousands of NVM data files and trying to extract the contents of all into separate file and using them results in about 15,000 files or so. That is why you only need to specify the two PK2s used and no extra files for the program are needed!

This tool was made using:
* for the framework and OpenGL rendering
* for the DDJ(S) texture loading
* An updated PK2API from the past
* My new NVM library
* Camera class from a game programming tutorial website

The rendering logic is very primitive. The reason you see "tiles" and not the smoothed out final resulting texture like you do in game is because the NVM files are not the visual terrain you see in game; those are in the map file I believe. These files are more related to ground and entity collisions. More information on this will come later though.

Instructions

0. Please read the Readme1st.txt file.

1. Run edxNVMViewer.exe

2. Choose your "data.pk2" file first

3. Choose your "map.pk2" file second

4. Click OK to exit the program.

5. Rerun the program. You will not have to choose your PK2 files again.

Controls

Spacebar - Unlock mouse

W/A/S/D - Move

Mouse - Look

Numpad 4 / Numpad 6 / Numpad 8 / Numpad 2 - Change region (left/right/up/down)

Numpad 5 - Return to the default region

Escape - Exit

Screenshots



For more screenshots rendered with a previous version of the program:

Binary Download

Attached.

This has been tried and tested for iSRO. I've not tried it on the other versions, but they should work. The private server PK2 files are mostly not compatible though.

scan.

I'd be happy to hear if it works for you, because I'll be using some of these concepts for future projects. I hope this is interesting, even if it might not be too useful for most people right now.

[recking]

i only got one comment:

#sticked

[InvincibleNoOB]

Great project ,Drew!

[xxbrentonxx]

Very nice. Doesnt this also open the doors to map editors and isrobot style loop programs?

[BloodyUser]

Awesome 0.0
Your the best Drew.

[pushedx]

Thank you guys for the positive feedback as usual.

Originally Posted by xxbrentonxx

Very nice. Doesnt this also open the doors to map editors and isrobot style loop programs?

Yes, there are three main uses to this kind of work:

1. Pathfinding/Collision detection - So you have access to terrain data to feed into some 3D path finding algorithm, perhaps something like or use some A* variation for 3D. There are a couple of problems with this approach if you want to do it in real time though, so just having the data is not enough to come up with a solution that just works.

I'm currently doing some research to try and come up with such a system. There might be more information in the PK2s that would make this task easier, such as the zone linking information, but I'm not there yet. If worse comes to worse, you could just create some additional files by hand to link specific regions together to make the algorithm more optimized as you don't want to load it all into memory and run a search each time!

2. Emulators - I believe this is the data the server uses for their player height checking since the client visual height is used else where. Knowing how this data is laid out will allow you to create your own new terrain files and place objects and whatever other information is located in these files. I still have some work to do to figure out what the other sections are for, but they are starting to make sense.

Back when Joymax had some new event, like 8 - 10 months ago or so where they added banners in town and new light poles outside of Donwang West gate, the NVMs were updated but the map files stayed the same. I'm pretty sure the NVMs can be used for adding new entities and whatnot to the client but if you wanted to modify the terrain as well, you'd need to modify the other map files.

3. New clients - You could make an OpenGL driven client(less) that is a lot more primitive but would more easily run on other platforms or weaker computers. You are of course pretty much sacrificing a lot of functionality and would still have a lot of work to do, but at least you can be sure you can see some terrain!

I am also interested in this aspect to use the techniques Silkroad does in learning how to make my own game by studying an existing game's workings. Basically, by doing all this stuff, I can see one method that is actually in use that is working and I can visualize it in game, so hopefully one day I can make my own MMO, but that's probably years away and would be additional years of work, but it's what drives me to do this stuff.

I will be working on this stuff the rest of the week and will post updates later as I get them. I still need to update my other older map file works, but once I have everything done and cleaned up I think I am going to release the entire package for people to play within a couple or months or so, depending on how development goes for everything else. I don't think Joymax will be making any serious changes to the data files for the new update, but that could possibly cause a small setback, but nothing to worry about.

I know some other people are working on the Silkroad map files so I don't want to discourage them from continuing their own work just because I plan on release mine, but this is some of the last stuff for Silkroad that's not really just out there and common knowledge yet.

I know Cruor (of SRF, SRA, IGL) has published some very nice code for loading BMS files via SRF last year and I plan on making use of his work to handle the objects, so between , which was so kindly posted publicly and this, most of the data workings of Silkroad should be known.

So, I'm looking forward to making more progress with this as time goes on!

[pushedx]

Here's a small update, I'm making this a new reply since my other two replies are kind of long as is and aren't so friendly to edit. I've added the rendering for the rest of the data in the NVM so it's drawn alongside the terrain. There are still some flags I need to figure out as well as piece together the bigger picture meaning of it all, but it's certainly a lot easier in 3D than it was in 2D!

The view you are seeing is the area around Storage/Blacksmith/Herb Seller. The line of entities you see are trees / walls. You can see them in the two reference screenshots I've taken.







Now for some interesting observations:

* Layer 2 / Zone 2 Data - Looks to be entrance and exit positions of the region. I'm pretty sure this is what the data is, but I'd need to add more regions at once to be totally sure.

* Layer 1 / Zone 1 Data - Contains zones that house entities. Any green areas have no entities in the region (don't see many since I'm in town, but the other regions are mostly green). Included are the names of the entities, so perhaps this is some sort of BSP tree or SceneGraph data to help make checking more efficient.

* Layer 3 / Zone 3 Data - Seems to almost mirror the zones listed in Zone 1, but is the set subtraction of Zone 1 and Zone 2 data. So anything marked in Zone 2 is not included in this layer.

* The Entity Data is pretty simple. I just need to use the BMS code to try and get dimensions and I can use the other data to orient the models correctly. This might be a lengthy process.

So that pretty much shows most of the NVM data. It's not 100% yet, but it's certainly getting there. For now I will probably be moving into the BMS files to see if I can get them loaded and placed in the world. Figuring out an easy way to get the dimensions of the collidable objects is really the main thing left for being able to fully utilize most of the NVM data.for pathing related tasks.

[Ahmed_100]

Sry Draw i didn't understand Any THing ??

[Don1231]

Wow fantastic work!
I'm amazed how you were able to fit the files in the pk2 packs.
I've tried to do that and always came out unsuccessful with crashes, bugs, ect.

Keep up the good work.

[rampino]

Sry i'm really noob but i can't undertend, what is this?

[recking]

please dont ask questions, it is all said in the posts above. read and learn.

edit: if u know what NVM means, and u are in the material you can ask of course detailed questions. i mean only questions like "oh whats that" etc...

[Nova1337]

This is so nice

[latrinidad]

omg awesome
nice work
just w8ing 4 more updates..

[memoonlinenet6]

look great
gonna try this

[maxbot]

This looks great and promising. I've been working on the navmesh files too together with one friend, but I don't have time to look in those .bms files to get width and height of the object and besides that, I suck at reversing.