Map Editor

Hey CO guys :D

So basically I've been developing an app for editing spawn points in EO, and making a libraries along the way for future use for a map editor. My problem is that TQ seems to have changed how they load their DMaps, and I lost all my research I had for DMap/Pul files some time ago so I've had to start from scratch. I'm sure that TQ most likely implemented this change to dmaps at some point in CO too.

So here's my problem, some maps load no problem when others load skewed in some way, it looks like there is only a region of cells within the dmap for some files that are loaded. See screenshots app on left with passability map 1 pixel = 1cell on right is mini map of the map.

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

I have searched and I did find the library that already exists, but it doesn't really suit what I am doing, all I'm really asking is there any file structures for everything required to edit a map? I'm sure EO/CO are extremely similar and once making a map editor for CO I can then adapt it for any differences in EO.

Hope this thread actually gets some interest :(

p.s. I do have the skill to do a map editor, I've made plenty in my time programming with c#/XNA, I make them for games that I make all the time.

If you have the EO source, you can check the way the server reads them.

Also, I posted a somewhat similar thread a bit ago, it has some useful information by nTL3fTy, unknownone, and Korvacs near the bottom: [Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by Zeroxelli If you have the EO source, you can check the way the server reads them. Also, I posted a somewhat similar thread a bit ago, it has some useful information by nTL3fTy, unknownone, and Korvacs near the bottom: [Only registered and activated users can see links. Click Here To Register...]

Thanks, it's helped a little but sadly EO loads objects so much differently >.<
They are loaded on the fly
So you have the 6 bytes for each tile and if a tile has an object then it will have the added 2 bytes for the object :/

Quote:

Originally Posted by funhacker Thanks, it's helped a little but sadly EO loads objects so much differently >.< They are loaded on the fly So you have the 6 bytes for each tile and if a tile has an object then it will have the added 2 bytes for the object :/

Oh, wow. So not only are the files bigger, but I assume the lag on the client end would also be increased (on some systems, greatly.)

Quote:

Originally Posted by Zeroxelli Oh, wow. So not only are the files bigger, but I assume the lag on the client end would also be increased (on some systems, greatly.)

In-game, the maps are loaded on the fly and rendered for a rather big range. It's why you can't go over 14XX x 9XX when hacking the CO2 window. The engine will never render the whole map.

I was under the assumption that maps were precached on startup and accessed on the fly, but I guess not. lol

Quote:

Originally Posted by CptSky In-game, the maps are loaded on the fly and rendered for a rather big range. It's why you can't go over 14XX x 9XX when hacking the CO2 window. The engine will never render the whole map.

wow so TQ do have rocks in their heads...
When coding a tile based system mine never displays much more than 1 or 2 tiles outside the camera view, this is just incase of lag but an entire map's "raw data" is loaded into memory

As far as I know, the entire base-map is fully rendered, in its entirety. I believe this includes scenes and objects as well? It was their way of "not having lag" when displaying a scene or object (or tile, for that matter) when moving quickly through a map. The problem is that the amount of memory it takes up to do this is enormous (their files COULD use some compressing...)

Quote:

Originally Posted by CptSky In-game, the maps are loaded on the fly and rendered for a rather big range. It's why you can't go over 14XX x 9XX when hacking the CO2 window. The engine will never render the whole map.

What are you talking about? The map size or client window size?

So I've been working more on this, and as TQ have a rediculous file format I decided I will be making the editor use my own format and just convert between them. This just makes loading/saving maps much easier.

I've still got a lot to do, like tile placement, data layer editing.

But the plan is, this app will allow you to make a map of however many (within the program and computer's limitations) visual layers you want, here you can place tiles on top of one another to make new tiles, upon converting the map into a TQ map it will create new image files based on what is placed and spawn the DMap/PUL/ANI file for the map. Should remove the need having to create maps using existing complex tiles, as you'll be able to create the complex tiles using base tiles. Like a bit of road on layer 1 a wall on layer 2 and some vines growing on the wall in layer 3.

This will be open source one finished so it can be adapted to any of TQ's games and others might learn some new stuff from XNA like transformation matrix :) which is very handy when using zoom

Very nice :) That's pretty much what I intended to do but never got around to finishing it, but either way I know for a fact you'll get further with it than me. It's been a long time since I've even heard of a successful editor in this community.

Having a little memory issue though...
A 1,000 x 65535 map chews up 1.2gb of memory :/
However spawning a map that size on a i7 920 takes about 3 seconds (single thread)

Entire app operates on multiple threads,
1 Main thread for windows form
1 Thread for each XPictureBox

Having a little memory issue though...
A 1,000 x 65535 map chews up 1.2gb of memory :/
However spawning a map that size on a i7 920 takes about 3 seconds (single thread)

Entire app operates on multiple threads,
1 Main thread for windows form
1 Thread for each XPictureBox

Quote:

Originally Posted by funhacker Having a little memory issue though... A 1,000 x 65535 map chews up 1.2gb of memory :/ However spawning a map that size on a i7 920 takes about 3 seconds (single thread) Entire app operates on multiple threads, 1 Main thread for windows form 1 Thread for each XPictureBox Having a little memory issue though... A 1,000 x 65535 map chews up 1.2gb of memory :/ However spawning a map that size on a i7 920 takes about 3 seconds (single thread) Entire app operates on multiple threads, 1 Main thread for windows form 1 Thread for each XPictureBox

It's because your're loading the full map. You should redesign this part. If I'm editing at (500, 500), I probably don't need (0, 0).

Quote:

Originally Posted by CptSky It's because your're loading the full map. You should redesign this part. If I'm editing at (500, 500), I probably don't need (0, 0).

thinking of it, but to do so I'll have to make a temp directory or it will have to overwrite an existing map each change.

I should also note that was with 5 visual layers and 1 data layer

DataTiles: 65,535,000
VisualTiles: 327,675,000

Quote:

Originally Posted by funhacker thinking of it, but to do so I'll have to make a temp directory or it will have to overwrite an existing map each change. I should also note that was with 5 visual layers and 1 data layer DataTiles: 65,535,000 VisualTiles: 327,675,000

You don't want to store 400kk structures in memory. If you really want, you should do the same thing that the swap memory. Write a "memory" block to the disk. In Photoshop, you can easily edit a picture with a working space of several Mo. A little image will take at least 20 Mo. Photoshop is rendering the part you're viewing.

Just create a temp file that will be purged when closing the app (GetTempPath?) and write the unsaved part there. With memory for actual view, temp memory for unsaved change and the source file for the saved but unviewed parts, you'll have a low memory utilization. And, a map shouldn't be 1 Go based on what I saw in CO2. So, the disk speed will not be a big problem for reactivity of the program.