[Freudstein]

Hi, I'm continuing to experiment with modding Duke3D. I wish to insert custom .png and .ogg files to replace an existing expansion's menus and music. I managed to do this by making a .DEF file as follows:

// Set MY_BG.PNG as 'betascreen' and 'menuscreen' tiles.
texture 2493 { pal 0 { file "MY_BG.PNG" nocompress nodownsize } }
texture 2456 { pal 0 { file "MY_BG.PNG" nocompress nodownsize } }

// Set MY_LOGO.PNG as 'ingamedukethreedee' tile.
texture 2499 { pal 0 { file "MY_LOGO.PNG" nocompress nodownsize } }

// Set a dummy 0-sized tile instead of the "ATOMIC" menu logo, so that only the
// 'ingamedukethreedee' tile is shown.
dummytile 2503 0 0

// Replace Grabbag intro with custom music.
music { id "intro" file "MY_MUSIC.OGG" }

This all works fine. However, now I'd like to package everything into a single .GRP, so that I can have only that and a .GRPINFO to avoid having lots of files scattered all over the place. I used Group File Studio 3.1 to place the .pngs, .ogg, .DEF, and the modified .CON (which does setdefname for including the .DEF) inside the .GRP. However, when I run the game with eDuke32 I see that neither my .png nor .ogg files are being used; the menu background and music are all the original ones. The .DEF file is being processed, though, since I don't see the "ATOMIC" menu logo (i.e. the dummytile change is being applied). Is there no way to package .png and .ogg files reliably inside a .GRP?

Note that the png and ogg files are about a couple MBs in size each.

[Hendricks266]

Use a zip file instead of a GRP. Everything else works the same, including grpinfo files. You may need to rename the .zip file extension to .grp.

Is there a reason you're not using tilefromtexture rather than texture so that your assets palswap and shade correctly alongside the original ones?

There is a token named undefinetile that you should use instead of a 0x0 dummytile.

You should also remove "nocompress nodownsize" from your texture definitions unless the situation actually calls for it, which this does not. Where did you find that? I've seen people blindly follow this pattern too many times and it needs to be rooted out at the source.

[Danukem]

The "nocompress nodownsize" tokens being overused goes all the way back to around 2008 --I may be wrong about the year but it was a long time ago and I started modding in 2006 so it was roughly a few years after that -- when there absolutely were serious bugs with compression and downsizing. Someone showed it to me and I started using it on all tiles that would go on the HUD or otherwise directly to the screen (e.g. fonts) because otherwise they would be randomly low resolution or glitched, and also it did seem like load times were significantly higher when compression was allowed. I guess it just became a standard and people started using it on all tiles, and now they just copy and paste those tokens to all texture definitions whether called for or not.

[Freudstein]

Hendricks266, on 10 July 2026 - 03:21 PM, said:

Use a zip file instead of a GRP. Everything else works the same, including grpinfo files. You may need to rename the .zip file extension to .grp.

Hi, thanks a lot for the response. I didn't know about the extension renaming, though to be honest at this point I've decided that it's best for my sanity to keep all new files unpacked and stored into separate folder instead

A .zip could be good for distributing, though this is all done for my personal usage.

Quote

Is there a reason you're not using tilefromtexture rather than texture so that your assets palswap and shade correctly alongside the original ones?

The .png I'm using as a background is 1400x1050, which happens to be the resolution I'm running the game in. If I use tilefromtexture I end up with a "zoomed in" version of the image, which also has broken colors. It also takes longer to load the game, presumably due to some internal conversion being done. I don't know what "palswapping" is, but for my intended usage texture works just fine.

Quote

There is a token named undefinetile that you should use instead of a 0x0 dummytile.

Ah yes, I had found this later on when trying to solve a different problem but didn't think about using it here too. Thanks!

Quote

You should also remove "nocompress nodownsize" from your texture definitions unless the situation actually calls for it, which this does not. Where did you find that? I've seen people blindly follow this pattern too many times and it needs to be rooted out at the source.

I've been using an old version of the Alien Armageddon mod as source for many of the patterns I'm following, since the .DEF files documentation in the eDuke32 wiki is very poor. Had there been a proper step-by-step guide or at least a good reference for these things I'd have gladly followed it, but unfortunately it seems all we have is ready-made examples which have been hacked together into working.

[Reaper_Man]

I would love to see some sort of micro-mod or micro-TC that implements the most common types of effects or utilizes features, and does so using best practices. Clearly everyone just copy-and-pastes from existing projects, and if all of those projects have poor practices, then it's just going to be perpetuated for eternity. People copy-and-paste this stuff because "it just works" and don't even know what these attributes are doing. At best it becomes superstition, at worst nobody ever learns anything.

[Freudstein]

Reaper_Man, on 11 July 2026 - 10:27 AM, said:

I would love to see some sort of micro-mod or micro-TC that implements the most common types of effects or utilizes features, and does so using best practices. Clearly everyone just copy-and-pastes from existing projects, and if all of those projects have poor practices, then it's just going to be perpetuated for eternity. People copy-and-paste this stuff because "it just works" and don't even know what these attributes are doing. At best it becomes superstition, at worst nobody ever learns anything.

Unfortunately it is impossible to learn best practices if there's no good documentation to follow, short of looking at the eDuke32 code itself. Take the wiki page for Texture (DEF) for example; the description states:

Quote

Defines a Hightile texture to replace an ART-file tile. <tilenum> may be a number, or a defined label.

What is a "hightile"? Where in the documentation is this concept defined? How is texture different from tilefromtexture, and where is that difference explained?

Look at the description for the pal argument:

Quote

Replaces the palette <palnum>. If a palette has no pal definition palette 0 definition will be used. Tint will not be used on palettes defined with this instruction.

What is a palette in this context? How does a texture replace a palette? What is a "pal definition"? What are the definiton numbers? Where is this all documented?

Scrolling further down you can see short descriptions of nocompress and nodownsize, neither of which have any indication of them not being needed anymore. There are also a few other arguments with a placeholder "DESCRIPTION", so good luck if you wish to use those.

A micro-mod/TC would be nice as an example, but it's no replacement for good documentation since users will simply resort to copying whatever that mod does without reasoning about it, as you said, because it becomes superstition.

[Danukem]

Freudstein, on 11 July 2026 - 03:06 PM, said:

Scrolling further down you can see short descriptions of nocompress and nodownsize, neither of which have any indication of them not being needed anymore.

For what's worth those are harmless to use and I think they still do have some use cases. I have run into texture compression issues sometimes with the latest builds causing textures to appear as glitched.

-----------

"hightile" I guess means a tile of a number higher than the numbers used in the original game (so 5120 or higher). But the texture command can be used to define a texture on *any* tile number in the allowable game range, whether high or low, so the use of "hightile" there is erroneous and confusing.

[ck3D]

FWTW, I wasn't sure what hightile was myself so just looked it up on the EDuke32 Wiki and, of course, got a response immediately (it redirects to the 'Polymost' page that explains it): https://wiki.eduke32.com/wiki/Polymost

Quote

It includes the hightile feature which allows true-color textures to replace 8-bit art, and support for 3D models.

Seaching for 'palette' also immediately returns three pages ('Palette', 'Palette data files', 'Palette (environment)').

'Define' also not difficult to put together, even spontaneously just using basic deduction no Wiki. (But there also is a page for the command.)

In case that would be the root problem, in general when using the Wiki or Infosuite (for the mapping side), one should not expect cleanly dedicated pages that would do all of the work, that would be impossible due to how much overlaps, instead should get used to searching/Ctrl F'ing around pages like crazy and then realistically should piece together exactly what they needed/wanted to understand quite fast.

From my experience it is true that some links return dead or empty pages in which case I just assume (sometimes wrongly I am sure) that the command is outdated/deprecated or something and an alternative must exist. If not then would ask about it but personally am more focused on the mapping side for which all of the documentation one needs is available in some shape or form except you do need to know sources that actually are credible on the topic (EDuke Wiki and Infosuite are some, but there also are lots of bogus ones spreading misinformation for clicks on YouTube, Reddit etc.)

[Reaper_Man]

"Hightile" is more a colloquialism referring to high def external textures, like the Polymost page more or less says. It's not a definition or term used by the engine.

Quote

in general when using the Wiki or Infosuite (for the mapping side), one should not expect cleanly dedicated pages that would do all of the work, that would be impossible due to how much overlaps, instead should get used to searching/Ctrl F'ing around pages like crazy and then realistically should piece together exactly what they needed/wanted to understand quite fast.

I completely disagree. One *should* expect clean dedicated pages, and we should *NOT* "get used to searching around like crazy" and having to "piece together what is needed". A system like that - to put it gently - completely sucks. If you think that it's normal, or good, or "should be expected" for people to spend a ton of time searching around for answers, it's clear you've never interacted with any sort of modern software, engine, or - really - community. Making things difficult to find isn't a good thing.

In any case, people can ask things and get things answered, sure, but the point is that this information basically evaporates if people aren't actively watching forum threads (or, god forbid, using discord). It's great Hendricks is telling us now that you don't need to use those 2 attributes when defining textures. What happens 6 months from now when someone else posts a new thread asking about it? Sure, someone else can repeat that information, but now we're getting into territory of creating superstition where we do or not do things "because I heard so-and-so said to do this-or-that". That can be avoided if the wiki was kept up to date (or allowed to be kept up to date, since apparently nobody has edit privileges).

[ck3D]

Reaper_Man, on 12 July 2026 - 08:37 AM, said:

I completely disagree. One *should* expect clean dedicated pages, and we should *NOT* "get used to searching around like crazy" and having to "piece together what is needed". A system like that - to put it gently - completely sucks. If you think that it's normal, or good, or "should be expected" for people to spend a ton of time searching around for answers, it's clear you've never interacted with any sort of modern software, engine, or - really - community. Making things difficult to find isn't a good thing.

In any case, people can ask things and get things answered, sure, but the point is that this information basically evaporates if people aren't actively watching forum threads (or, god forbid, using discord). It's great Hendricks is telling us now that you don't need to use those 2 attributes when defining textures. What happens 6 months from now when someone else posts a new thread asking about it? Sure, someone else can repeat that information, but now we're getting into territory of creating superstition where we do or not do things "because I heard so-and-so said to do this-or-that". That can be avoided if the wiki was kept up to date (or allowed to be kept up to date, since apparently nobody has edit privileges).

I will not disagree with any of that, you are making nothing but great points except for assuming that I am defending the current way or implying it is any good. I am sure the Wiki could be modernized even with just more abundant redirections and hyperlinks... were more people available to spend time updating it as much as they are busy updating the port itself (which I suspect is why the documentation is so 'far' behind). My intent really was to say, or warn, get ready for this type of strange organization because the engine itself functions in a way that is completely but fittingly antiquated, that is a curse but also a strength in that it makes it what it is with all the quirks and fun possibilities. It is relatively difficult (really just an extra step) to find and amass the knowledge but once you have you will need to dilute and distill and combine precise little bits of this and that and also this other basic principle... to craft exactly what your vision dictates instead of relying on superstition like you put it (really well). Eventually you will need to deconstruct and so why bother with constructions at all if they are just getting in the way of articulating fundamentals, then maybe as long as said fundamentals are out there the rest is quixotic? TL;DR to put it simply. Let's say tomorrow either a miracle or a catastrophe happens, and hyper specific Build engine tutorials are trending on Tiktok. Does this place gets less questions asked, or more? (Obviously the engine, game, port... are still the same)

Perhaps on the coding side is less of a thing than on the mapping side since ideally one wants clean code that is optimally organized regardless and that in itself is a form of structure. But so is what the level editor expects and the main block to it I see newcomers run into is they search for separate, detailed, well-structured 'Advanced FX' tutorials everywhere that either do not exist for a reason, or only cover constructions as specific as copy-pasted blocks of code would be, then once they've followed the tutorial is when they make a thread or ask what the heck isn't working in the context of the larger picture (e.g.. don't understand fundamental sector activation principles, etc., so in the end maybe made one Star Trek door to clone around but really learned nothing important). Literally feel free to ask any advanced mapper what section of the Infosuite is the most useful between the centralized 'Advanced FX' one, and the 'References' one that covers the same teachings except not neglecting the fundamentals but at the expense of spreading out over multiple pages. I've even heard advanced EDuke programmers spontaneously express the same preference.

Also am speaking from Wiki user standpoint myself, I do seem to see it updated from time to time hence why I wouldn't be so quick at ruling out there is effort spent on it to this day at all. (Which does make reports regarding what may be missing, deprecated... relevant)

TBH I think everything learning Build, be it code or map wouldn't benefit from either old-school or more modern documentation style more so than it would from a lateral approach that would be tailor-suited to its behavior and expectations. Let's call it postmodern as joke but come to think of it as such a timeless oddity, the engine itself kind of genuinely is. Thus makes sense to learn as such or would erect walls and be counterproductive.

Also I am critical of modern communities because I have studied the model from way too closely and know exactly where it doesn't work and just means different problems. For instance presents legitimate concerns and questions on the same level as tides of personal psychosis expressed under the same format resulting in more noise and not necessarily efficient problem solving (and yes I am self-conscious that's how most people who aren't hyperspecialized will read this and am totally fine with it). And there's more!

People have mentioned a mod that ideally could become a standard for edits. As far as mapping possibilities go, I know Ledsbourne/Aleks has been working on something like that, it is looking great and I wish that project the best. But in the most absolute newcomer's reality most any such effort would just look like all the more information to absorb all at once and (ironically) modernity has it that that is now a deterrent to most. Perhaps is a big reason why every time someone has tried to set a new standard, e.g.. Lezing with ExtClut, LeBuild... it never really picked up on the user side. It really is just like the meme, you just end up with one more standard out of n available standards. That of course is not to say it is not to be appreciated trying, I think every sincere attempt is fantastic in its own right and just means it will speak to whoever it should speak to, just like the engine and also learning it.

[Reaper_Man]

I think we're now talking about 2 separate things - documentation, and tutorials. I am only talking about (and I assume Freudstein also) documentation of features, not necessarily tutorials in how to use them.

I don't think scripting tutorials really make a lot of sense, but I think having a working example is easier for creators to pull from, hence the idea of some sort of example micro mod/TC. I don't think it's possible to tutorialize every possible way to use every possible command or feature.

I'm not sure this is comparable to mapping resources, since that stuff is effectively etched in stone. There's a reason the InfoSuite hasn't been updated in over 10 years, and correct me if I'm wrong, but also doesn't need to be updated.

However, I am reminded of the discussion talking about "mask wall" and "overpic" and how these are the same thing that just goes by different names. Mappers know the term "mask wall" but that actually isn't a term used anywhere in the engine, which refers to it as the "overpic".

[ck3D]

Reaper_Man, on 12 July 2026 - 11:23 AM, said:

I think we're now talking about 2 separate things - documentation, and tutorials. I am only talking about (and I assume Freudstein also) documentation of features, not necessarily tutorials in how to use them.

I don't think scripting tutorials really make a lot of sense, but I think having a working example is easier for creators to pull from, hence the idea of some sort of example micro mod/TC. I don't think it's possible to tutorialize every possible way to use every possible command or feature.

I'm not sure this is comparable to mapping resources, since that stuff is effectively etched in stone. There's a reason the InfoSuite hasn't been updated in over 10 years, and correct me if I'm wrong, but also doesn't need to be updated.

However, I am reminded of the discussion talking about "mask wall" and "overpic" and how these are the same thing that just goes by different names. Mappers know the term "mask wall" but that actually isn't a term used anywhere in the engine, which refers to it as the "overpic".

It's possible I jumped three sharks ahead by simultaneously preparing the terrain for scripting and mapping but it all telescopes ultimately, no? Most features overlap and are just triggered through a different interface. Your mention of overpic actually is the perfect bridge, no mapper is going to go very far with maskwalls at all if they do not know nor understand overpic and overpicnum. From time to time I have to explain it to people whenever they mess up and spread pandemic forcefields around their levels so that they can fix it in 2D mode (recognize the term in the wall data menu). 'Maskwall' has to be a term that comes from somewhere original though, seeing as the key to make them is 'M'. If not inside of the engine itself then either a term that was exclusive to dev or something the earliest Build FAQ's made up and spread which would be funny.

Infosuite is especially decent now that it is complemented by the EDuke Wiki for more advanced/technical knowledge re: modern features (post 2015...). I am not sure it is valid to dissociate both platforms in relation to practice (mapping/scripting), I think it is the same pattern and thus result, technical info centralized somewhere and just because it is technical and a lot to read, study and filter means some brains will follow and some won't, eventually in both fields you simultaneously can find people who get stuck seemingly forever on every step, contrasting with people who can output excellent material from the get-go, all have had access to the same web pages. At the end of the day the experienced users all get the same kind of DM's from the novices regardless of speciality, there is no need for a split that just complicates things, it is all EDuke, one big central chicken to eat, some start nibbling away at the wing, some others at the thigh, same difference once we reach the core.

If anything the separation is the problem; I think an ideal, optimal Build method would teach all of the right fundamentals of the engine and its expectations, indiscriminately of which category one might want to label them under ('scripting', 'mapping'...), eventually would result in a generation that immediately would be competent at 'both' (really just at Build). There shouldn't be a thing such as specialization that supposedly would rule out the larger scope of reality, especially EDuke is too small.

Example of micro mod/TC that would (theoritically) tutorialize every possible way to use every possible command or feature... is the same as the modern Build mapper's wet dream of, 'what if there were simple sector asset packs I could just clone away from?' (a recent concern; it used to not exist). The impracticalities too, e.g.. go ahead and clone a door from a map into a different one and make it fit there if you've never touched or studied the editor at all and do not understand what a wall is doing, what a (wall) loop is, how activation, tags and sector Z work. It is just like copying blocks of code around and instilling/perpetuating superstition. Concept itself is interesting (sector pre-builds effectively can be convenient/practical/fun) but otherwise a naive chimera, eventually all it would be doing is giving the users the illusion that they are making something, when they really would just be rearranging foreign blocks of work all the while bringing the scene a step closer to A.I. standards or lack thereof.

[Freudstein]

Hi guys, I appreciate all the insightful responses

Since we're discussing tile/texture-related topics, could I ask you to take a look at the question I posted in https://forums.duke4...436#entry387436 and point me to the relevant documentation (if any) which could help me solve that problem? Thanks again.

[ck3D]

Freudstein, on 15 July 2026 - 02:16 AM, said:

Hi guys, I appreciate all the insightful responses

Since we're discussing tile/texture-related topics, could I ask you to take a look at the question I posted in https://forums.duke4...436#entry387436 and point me to the relevant documentation (if any) which could help me solve that problem? Thanks again.

This exact problem someone else will have to fill in the details, but I can confirm that specific image and a couple of others exist in the game in that state with the wrong colors. What makes them display correctly in the game is it knows when they are supposed to display and is hardcoded to temporarily switch to a unique palette/mode just for them to look right, and then back to normal game palette. Thus by extension, using them 'out of sequencing' will result in no automatic correction happening. I wouldn't doubt you can manipulate and edit that in some way with EDuke but an actual programmer would have to chime in. My own understanding is a bit of a simplification. Naively I suspect you might run into a conflict by nature anyway just trying to run that image as background of another game event (the menu) that operates in normal game palette. Your best bet probably is to reimport a corrected image (to fit game palette) that also would be exempt of any funny behavior chained to it.

Those tiles are particular also for mappers because (since they need a game side correction to look right) means you technically can use them around levels as textures on the same level as any other game art, but seeing as it looks downright broken no one is ever really doing it, which is remarkable given every other available visual asset in the game by now has been rinsed and tweaked by generations, but those seem straight up unsalvageable (solely relying on the mapping side).

[Freudstein]

ck3D, on 15 July 2026 - 02:38 AM, said:

This exact problem someone else will have to fill in the details, but I can confirm that specific image and a couple of others exist in the game in that state with the wrong colors. What makes them display correctly in the game is it knows when they are supposed to display and is hardcoded to temporarily switch to a unique palette/mode just for them to look right, and then back to normal game palette. Thus by extension, using them 'out of sequencing' will result in no automatic correction happening. I wouldn't doubt you can manipulate and edit that in some way with EDuke but an actual programmer would have to chime in. My own understanding is a bit of a simplification. Naively I suspect you might run into a conflict by nature anyway just trying to run that image as background of another game event (the menu) that operates in normal game palette. Your best bet probably is to reimport a corrected image (to fit game palette) that also would be exempt of any funny behavior chained to it.

Those tiles are particular also for mappers because (since they need a game side correction to look right) means you technically can use them around levels as textures on the same level as any other game art, but seeing as it looks downright broken no one is ever really doing it, which is remarkable given every other available visual asset in the game by now has been rinsed and tweaked by generations, but those seem straight up unsalvageable (solely relying on the mapping side).

Thanks a lot. I will copy this response on the other thread so as not to further derail this one.