Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
chungy

DeuTex 5.1.0 is released

Recommended Posts

4 hours ago, Doctor Nick said:

So, regarding 1), you'll be happy to know that deutex already includes this feature. "-overwrite -extract".

 

However, the feature was broken in the latest release. We will create a new release shortly with this feature fixed.

deutex -doom2 doom2.wad -levels -overwrite -extract rand.wad
deutex -doom2 doom2.wad -levels -overwrite -extract rand2.wad

It seems the -overwrite command does not work. nothing changed. He does everything the same as before

 

Tell me how the -overwrite command works

Share this post


Link to post

Tell me how the -overwrite command works


When -overwrite is selected, COMstroy is executed. This changes the default value of WSafe to false and clobber's value to CLOBBER_YES. When -xtract is also run with -overwrite, all the checks for WSafe come up as false, whence it doesn't give you a "can't overwrite file" error and just plain overwrites it.

It would seriously help if you could be a bit more clear about your purposes.

Share this post


Link to post
4 minutes ago, Voros said:


When -overwrite is selected, COMstroy is executed. This changes the default value of WSafe to false and clobber's value to CLOBBER_YES. When -xtract is also run with -overwrite, all the checks for WSafe come up as false, whence it doesn't give you a "can't overwrite file" error and just plain overwrites it.

It would seriously help if you could be a bit more clear about your purposes.

And why do I need a function? I need to save all levels of two files, even if the levels in the two files have the same level name.

I just suggest adding a function so that it retains all levels, for example, changing the file name to a number or random number

Share this post


Link to post

aahhhh so I was right. But it seems unorthodox. Why not just rename the first extracted map01.wad to something else then extract the second WAD?

Share this post


Link to post
15 minutes ago, Voros said:

aahhhh so I was right. But it seems unorthodox. Why not just rename the first extracted map01.wad to something else then extract the second WAD?

Because I do not do it myself but my project. I have code that will do the following

It will write data to the bat file and then this bat file will be launched. And if I have several files with one level, then deutex must coerce them all

Share this post


Link to post
6 hours ago, kop9000 said:

deutex -doom2 doom2.wad -levels -overwrite -extract rand.wad
deutex -doom2 doom2.wad -levels -overwrite -extract rand2.wad

It seems the -overwrite command does not work. nothing changed. He does everything the same as before

 

Tell me how the -overwrite command works

It's currently broken in the latest release, we will release a new one soon that fixes this problem.

Share this post


Link to post

kop9000: Good news, we just created a new build. I added in some special features (like detecting GL_nodes) and your first suggestion to make working with oblige easier.

 

I took a look at implementing your second suggestion, and it looks like that will require some serious architecting to get deutex to build without a WADINFO.txt. However, it should not be difficult to script generating a wadinfo.txt; just get the directory contents minus the extensions and put them into a text file.

deutex-5.0.0-HEAD-w32.zip

Share this post


Link to post

generating a wadinfo.txt


I was just going to mention that. It's a feature that should've been in Deutex from the beginning. Manually writing down all the lumps in wadinfo.txt is a PITA, especially when we're dealing with texture packs.

And as an extension to that, generating a wadinfo.txt of a WAD without extracting said WAD is just as useful.

Share this post


Link to post
9 hours ago, Voros said:


I was just going to mention that. It's a feature that should've been in Deutex from the beginning. Manually writing down all the lumps in wadinfo.txt is a PITA, especially when we're dealing with texture packs.

And as an extension to that, generating a wadinfo.txt of a WAD without extracting said WAD is just as useful.

Hey, if you wanna take a crack at it, be my guest ;)

Share this post


Link to post
20 hours ago, Doctor Nick said:

kop9000: Good news, we just created a new build. I added in some special features (like detecting GL_nodes) and your first suggestion to make working with oblige easier.

 

I took a look at implementing your second suggestion, and it looks like that will require some serious architecting to get deutex to build without a WADINFO.txt. However, it should not be difficult to script generating a wadinfo.txt; just get the directory contents minus the extensions and put them into a text file.

deutex-5.0.0-HEAD-w32.zip

It seems that the new version did not help me. Do not create two different levels with the same name but only unpack one

Share this post


Link to post

Do not create two different levels with the same name but only unpack one.


That's exactly what it does. Unless you use -overwrite.

Example:
rand1.wad has MAP01
rand2.wad has MAP01 and MAP02

I extract rand1.wad and get MAP01.wad in my /levels folder.

I then extract rand2.wad and only get MAP02.wad extracted, because a MAP01.wad already exists in my /levels folder.

So in the end, my /levels folder has rand1's MAP01 and rand2's MAP02.


Hey, if you wanna take a crack at it, be my guest ;)


When I get the time, I just might ;)

Share this post


Link to post
3 hours ago, kop9000 said:

It seems that the new version did not help me. Do not create two different levels with the same name but only unpack one

I just tested this new build on windows, and when using -overwrite -extract, it does work. 

Share this post


Link to post
12 hours ago, Doctor Nick said:

I just tested this new build on windows, and when using -overwrite -extract, it does work. 

Still does not work even if I use -overwrite

 

But what does the new function GL_nodes do what does it do? I'm not talking about -overwrite I'm talking about GL_nodes

Share this post


Link to post

oh, that's not a new function, that automatically happens during -extract. It just recognizes GL_nodes in the level data when extracting them. I noticed in the latest version of Oblige that it always generates GL_nodes for each level; if you previously attempted to extract Oblige wads with deutex, it would not retain that data. 

Share this post


Link to post
3 hours ago, Doctor Nick said:

oh, that's not a new function, that automatically happens during -extract. It just recognizes GL_nodes in the level data when extracting them. I noticed in the latest version of Oblige that it always generates GL_nodes for each level; if you previously attempted to extract Oblige wads with deutex, it would not retain that data. 

But here's the thing. In any case it's good too.

In any case, I already have my own system for unpacking the levels. So my project or rather the new version should be released in the nearest time

Share this post


Link to post

Levels without nodes work normally in ports that have a built-in nodebuilders so that they can create the missing nodes.

Share this post


Link to post
18 minutes ago, Gez said:

Levels without nodes work normally in ports that have a built-in nodebuilders so that they can create the missing nodes.

And in zdoom there are built-in nodes?

Share this post


Link to post

Yes, ZDoom has a built-in nodebuilder, ZDBSP, and it can create the GL nodes if needed.

 

On the other hand, GLBoom+ does not have a built-in nodebuilder, and it needs GL nodes.

Share this post


Link to post

Found an old (and awesome) thread on Deutex out of curiosity

Click here

I haven't checked it out yet, but the changes mentioned in the changelog most definitely sound promising and we should probably try to merge those changes (after cleaning up) :) if the code is available though.

Edited by Voros

Share this post


Link to post
10 hours ago, Voros said:

Found an old (and awesome) thread on Deutex out of curiosity

Click here

I haven't checked it out yet, but the changes mentioned in the changelog most definitely sound promising and we should probably try to merge those changes (after cleaning up) :) if the code is available though.

That's interesting. I'd be interested to see a diff between that and the last official release. (4.4.902 or something)

Share this post


Link to post

This is interesting: "Default insertion point set to (width/2,height-5) because that is what is used for wall patches and that is what these really are."

Is that true?

Edited by Doctor Nick

Share this post


Link to post

From what I can tell, this already is the case in Deutex if you look at IDENTinsrX and IDENTinsrY.

Share this post


Link to post
7 hours ago, Voros said:

From what I can tell, this already is the case in Deutex if you look at IDENTinsrX and IDENTinsrY.

Yeah, from the looks of things, most of the stuff he lists is already in there; either way, the link to the archive with the source code is broken.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×