[dandouglas]

Hi all, this feels like it should be a really easy thing to do and apologies if it's already been answered here but for Duke Nukem 3D i'm struggling to add .art files beyond TILES022.art (which contains World Tour assets) and get Mapster and Eduke to recognise them.

Due to the number of custom textures/animation frames in my project I need more slots than are currently available.

I have BAFed and DukeRes installed and I've been using them to add new textures to the existing .art files, and I can create new .art files, but I can't work out how to actually access them in Mapster.

Any pointers greatly appreciated - I'm only just starting to dip my toe into CON editing.

Cheers!

[Hendricks266]

The engine loads TILESXYZ.ART files in ascending numerical order until one is absent, then it stops there. If you don't have TILES020 through 022 present, it won't even try loading 023. If you want to keep compatibility with Atomic GRPs, which don't have those files, I would recommend using this def syntax:

artfile { file "whatever.art" }

[dandouglas]

Thanks so much for this, I've got two new .art files (TILES023 and TILES024) working in both the World Tour and Atomic versions I have installed.

Just to double-check (I'm a total novice at this, apologies), is this the correct way to get the Atomic GRP to recognise these .art files? They seemed to work fine without the def syntax being added but I just want to make 100% there's no compatibility issues if/when I release this mod.

Hendricks266, on 15 September 2021 - 05:31 PM, said:

The engine loads TILESXYZ.ART files in ascending numerical order until one is absent, then it stops there. If you don't have TILES020 through 022 present, it won't even try loading 023. If you want to keep compatibility with Atomic GRPs, which don't have those files, I would recommend using this def syntax:

artfile { file "whatever.art" }

Attached thumbnail(s)

• 

[Hendricks266]

If the ART files load with Atomic but without defs, that means it is picking up TILES020 through 022 from somewhere, possibly from your WT installation. You will need to launch with the `-usecwd` parameter to test running with only things in the current directory from a folder containing only the Atomic GRP.

Also, if you are using the artfile token, I would highly recommend naming your ART files something other than TILESXYZ.ART so there is no possibility of conflict or duplicate loading.

[dandouglas]

That's great, I've done some testing and the Atomic GRP is finding renamed .ART files fine.

Thanks again for your help with this, it's really appreciated.

Hendricks266, on 16 September 2021 - 12:53 PM, said:

If the ART files load with Atomic but without defs, that means it is picking up TILES020 through 022 from somewhere, possibly from your WT installation. You will need to launch with the `-usecwd` parameter to test running with only things in the current directory from a folder containing only the Atomic GRP.

Also, if you are using the artfile token, I would highly recommend naming your ART files something other than TILESXYZ.ART so there is no possibility of conflict or duplicate loading.

[Phredreeke]

It is also possible to have map specific tiles I believe by giving the ART file the same name as the map (except for extension of course)

[dandouglas]

Good to know! Cheers.

Phredreeke, on 17 September 2021 - 02:59 AM, said:

It is also possible to have map specific tiles I believe by giving the ART file the same name as the map (except for extension of course)

[Doom64hunter]

Hendricks266, on 15 September 2021 - 05:31 PM, said:

The engine loads TILESXYZ.ART files in ascending numerical order until one is absent, then it stops there. If you don't have TILES020 through 022 present, it won't even try loading 023. If you want to keep compatibility with Atomic GRPs, which don't have those files, I would recommend using this def syntax:

artfile { file "whatever.art" }

This is wrong for current eduke32 revisions, and also going back at least 5 years.

 //
 // loadpics
 //
 int32_t artLoadFiles(const char *filename, int32_t askedsize)
 {
     Bstrncpyz(artfilename, filename, sizeof(artfilename));

     Bmemset(&tilesiz[0], 0, sizeof(vec2_16_t) * MAXTILES);
     Bmemset(picanm, 0, sizeof(picanm));

     for (auto &rot : rottile)
         rot = { -1, -1 };

     //    artsize = 0;

     for (int tilefilei=0; tilefilei<MAXARTFILES_BASE; tilefilei++)
         artReadIndexedFile(tilefilei);

     Bmemset(gotpic, 0, sizeof(gotpic));
     //cachesize = min((int32_t)((Bgetsysmemsize()/100)*60),max(artsize,askedsize));
     g_vm_size = (Bgetsysmemsize() <= (uint32_t)askedsize) ? (int32_t)((Bgetsysmemsize() / 100) * 60) : askedsize;
     zpl_virtual_memory vm = Xvm_alloc(nullptr, g_vm_size);
     g_vm_data = vm.data;
     g_vm_size = vm.size;
     g_cache.initBuffer((intptr_t) g_vm_data, g_vm_size);

     artUpdateManifest();

     artfil = buildvfs_kfd_invalid;
     artfilnum = -1;
     artfilplc = 0L;

     return 0;
 }

The engine will iterate over all indices from 0 to 199 (MAXARTFILES_BASE is 200) and will not break at any gap. This is easily verified by taking any regular ART file and renaming it to something like TILES170.ART. The tiles within will appear at the same indices as if the file was named TILES023.ART for instance.

In fact, in AMC we've been using this for a few years to separate episode 5 art from the episode 4 art.