[Idea] Modern editing tools for Daikatana?
Issue #103
resolved
Daikatana is really in need of modern editing tools. IONRadiant is ancient and feels like it's barely functioning at times. Even a modified GtKRadiant for DK would be a huge step up.
This is a really small thing, considering how few people play DK these days, but it could be nice as a far-flung goal after wrapping up 1.3. :O
Comments (23)
-
-
reporter
It's not something that needs to be done RIGHT NOW; just a little project to consider working on after work on 1.3 is finished.
-
There are actual technical hurdles beyond just adding a profile. Daikatana uses modified versions of Q2's file formats, which would have to be supported in GTKRadiant. The .pak format is the worst, it has the same extension and header as Q1/Q2's .pak files, but is internally different to a degree that Radiant would have to know beforehand that it's loading a pak for Daikatana to not have errors. Even the .map format has extra fields for surface color, and I don't think GTKRadiant supports those, either.
As far as "barely functioning", do you mean that IonRadiant's camera is slow? Its drawing code uses really ancient OpenGL calls, so there's a lot of room for improvement there.
-
Would it be easier to look at someting like quark to see if it can handle loading both daikatana and quake 2 paks and found some way to differentiate between them? Or would it be easier to merge gtkradiant changes into ionradiant?
There must be some sort of data after the header and such as a way to test what it is.
-
How about Jackhammer editor? It already supports Quake1/2/3/HL maps editing.. Is it better or worse than GTKRadiant? I've never worked with these apps, so I don't know. Maybe it would be the best to persuade developers of Jackhammer to add support for Daikatana, but donations would be probably needed from comunity...
-
reporter
Hmmm, that would be interesting to pursue.
-
trenchbroom would be even more awesome
-
Trenchbroom would be awesome. It can produce really beautiful geometry. But the core issue with Daikatana's technical differences would stay. I'd probably argue that it's more difficult to implement Daikatana support for editors other than GTKRadiant.
However all things considered... I still don't see a burning need for better tools. The existing ones still work well enough. However it would be nice to see some minor improvements in IONRadiant (like fixing the camera movement sensitivity issues when using Hi-DPI mouse).
Larger changes like backporting updated code from GTKRadiant to IONRadiant (technically should be possible since they share the QERadiant base if I remember correctly) require a lot of work and time. Committing actual support for Daikatana in GTKRadiant or some other editor would be a "nice to have" but, like Knightmare pointed out, apparently takes lot of time and would required expertise from people who know the editor e.g. GTKRadiant inside out like e.g. TTimo. It would be still interesting to hear opinion of GTKRadiant's developers regarding Daikatana support in the GTKRadiant. GTKRadiant is supposed to be game engine independent after all.
I'm not expecting Daikatana's toolchain to be ported to Linux but it would be another "nice to have". GTKRadiant already runs on Linux too.
-
I'm the author of TrenchBroom. I would like to add support for Daikatana to TrenchBroom, but I'll need some help with testing and, most importantly, with specs for reading game assets such as pak files, models, skins, and textures. From what I understand, the latter two are identical to Quake2's files, but paks and models are different. A quick google didn't turn up much, though. If you would like to help out, let me know at https://github.com/kduske/TrenchBroom/issues/1304
-
For the pak files I'll try to write a specification of the format or maybe an open source (un)packer in the foreseeable future.
Regarding the models, http://charles.hollemeersch.net/node/41 has a tool + sourcecode to convert q2 models to Daikatana models, maybe that'll help? If not we should probably also try to write specs for it..
Does anyone know about the other formats? Are the .wal textures the same as Q2? Is the .sp2 (sprite) format known?
-
The .wal textures are different from Q2, as they have additional mip levels (9 instead of 4) and have an additional palette field, not to mention per-texture set palettes. The .sp2 sprites are the same as in Q2.
The .map files are slightly different from Q2 in that they have optional RGB color values for each brush face added at the end of each face line. These are used for surface lighting and volumetric fog.
Supporting DK's pak format alongside Q1/Q2 paks will be tricky, as the format is different, but the file header and extension are unchanged.
-
Supporting DK's pak format alongside Q1/Q2 paks will be tricky, as the format is different, but the file header and extension are unchanged.
I don't think that's a problem: If the editor is in Daikatana mode (I guess you select somewhere which game you wanna create maps for?), it uses the Daikatana format, else the Quake format.
-
@DGibson Yes I saw that tool also. I reckon I can also look at the Quark source to find code for reading all of those files.
-
@kristianduske:
Description of pak format: https://gist.github.com/DanielGibson/8bde6241c93e5efe8b75e5e00d0b9858Description of wal format: https://gist.github.com/DanielGibson/a53c74b10ddd0a1f3d6ab42909d5b7e1
Does Quark support the Daikatana specific formats? It probably supports .sp2 though.
-
Great, thank you so much! I thought that Quark had Daikatana support, but it seems that I was wrong.
-
https://github.com/yquake2/pakextract/commits/daikatana this branch of pakextract extracts daikatana .paks, incl. compressed files (Yamagi implemented the decompression according to my description linked above).
It's under BSD license, so it can be used by others as long as they mention the authors somewhere.
-
I analyzed the .wal textures shipped with Daikatana (in pak1.pak) and found out the following:
- textures/e2dm2/ contains Quake2 .wal textures, that are not actually used (e2dm2.bsp uses the E2M5 texture set)
- all other textures are in the Daikatana format as expected (and the game can only read that anyway)
- most textures contain the right colormap, i.e. the same as in colormap.bmp in the same folder
- e4dm1 has 14 textures that do not contain the same colormap as e4dm1/colormap.bmp
- e2dm1/freeze1b.wal also has the wrong colormap
It was similar with community maps from pak9.pak - seems like most of the textures contain the right colormap, but some don't.
Probably it's really best to use the colormap of colormap.bmp. -
Here is some public domain code I wrote for parsing Daikatana .wal files and 8bit BMP files (which are very suitable to be converted to .wal textures and are also used for colormap.bmp): https://gist.github.com/DanielGibson/2ceeba3fb6141e839c4aaf141b649762
Some of the code is kinda hacky, but I think the parsing functions are okayish.
Feel free to use that for your editor or whatever other tools :-)
Credit (at least in the Sourcecode) would be nice but is not necessary. -
Hi there. I'm working on Daikatana support for TB2 right now, but I have hit a problem. It seems that the entity definitions are hard coded into IonRadiant, but I need a separate file for TrenchBroom (a .def file or, preferably, a .fgd file). Creating a proper file requires good knowledge of the game and its entities, so I can't really do it myself? Would anyone here be interested (or know someone who might be) in helping out?
Sorry for the double post, I only found out after the move to this repository after I had posted.
-
We have a .h file that contains all the key-value pairs as strings, I'll generate a .def or .fgd file from that soon (just have to figure out the correct output format first)
-
Great, though if you make the .h file available to me, I could do it myself. FGD would be preferred as it's more flexible and better supported by TB2.
-
This makes things a lot easier for me, as I'm not very familiar with Quake .def format and not at all with .fgd, thanks a lot! :-)
I sent you an email with the file
-
- changed status to resolved
- edited description
We now have Trenchbroom support.
- Log in to comment
It's probably possible to add a Daikatana profile to GtkRadiant. But at the moment you can do a map in GtkRadiant and then bring it over to IONRadiant for running it through the Daikatana's toolchain.
With that said, I've been doing maps with IONRadiant and it's actually not that bad or archaic. It does the job given to it and it does it fairly well. Of course more up to date tools that work better in modern operating systems would be preferable. But I don't see immediate need for them at the moment. But it's certainly something to consider in future.