[Helixhorned]

NightFright, on 06 August 2015 - 12:43 AM, said:

It appears that you cannot put the ART files into a zipfile, though, and renaming is required since usually, you will exceed the 8.3 specifications of groupfile contents (e.g. "cranium_00.art"). That means one would have to work with external ART files - unless you shorten map names.

That's a good point! I guess we could also search for <mapname>.aXX, but that adds more hard-codedness and potential file system accesses.

Quote

There is also still the issue with overlapping custom sounds and CON code. Sounds could be remapped partially, but if you have for example a custom shotgun sound that is only meant to be used in one map and not any of the others, you would start altering original gameplay. I guess in order for this to work completely, EDuke32 would also need to be able to load specific CON files for each map (e.g. cranium_game.con), and I think that's not possible.

This particular case could be hadled using EVENT_SOUND in a mutator, intercepting the start of the shotgun sound, I think.

Hendricks266, on 08 August 2015 - 06:14 PM, said:

The per-map ART feature only got in my way when I was refactoring the ART code recently to expand how it can be used from def. I appreciate how it, like the grpinfo feature, has its uses, but I find both to be under-engineered stopgaps that will need both replacements and indefinite maintenance for backwards-compatibility.

The original use of the per-map ART feature was more convenient usage of stand-alone usermaps that come with custom art, rather than a tool for modding. So yes, it's not (as we say in Germany) the "egg-laying woolmilksow" , but just enough to make such maps conveniently usabe on the player side.

[Jblade]

It is insanely useful though for per-map stuff because it means that each map can have unique textures tailor made for stuff in the map rather than being forced to use generic text and stuff (for instance I've already used it for water caustics as well as blending two terrain textures together) - it also frees up space for more art tiles for gameplay related stuff like enemies or weapons.

Still waiting for more sound space though since we've already gone past 3000

[NightFright]

When trying to merge Billy Boy's maps, following challenges come up (as a summary):

- Colliding .art files --> possible to solve (see above)
- Colliding soundfiles --> difficult, but probably possible (by map editing/redefinitions) - conflicts still not completely excluded
- Colliding CON code --> solution uncertain

Another thing about .art files:
Especially problematic if you merge episodes. When many maps share the same .art files, duplicating those for each map would bloat the groupfile quickly. Until now, I haven't really run into such an issue, and I don't know if this is too specific to justify being addressed (same with CON code problem above), but at least for my purposes it'd be extremely helpful if a solution were found and implemented.

I don't expect it to happen, for I am aware of the fact that there must be some kind of common demand for such things to be considered, but I have reached a point in this project where I rather focus on grouping together single maps of the same author(s) since most episodes that could be re-released are included by now.

[Fox]

NightFright, on 06 August 2015 - 12:43 AM, said:

Found it, introduced in build 4257:


That's kinda interesting info. This way quite some compilations I considered being impossible until now could be realized. I will see if I can figure it out.

It appears that you cannot put the ART files into a zipfile, though, and renaming is required since usually, you will exceed the 8.3 specifications of groupfile contents (e.g. "cranium_00.art"). That means one would have to work with external ART files - unless you shorten map names.

If there are two maps sharing the same ART, I guess the only way to make it work is to duplicate the files and do like map1_xx.art and map2_xx.art for the same file.

There is also still the issue with overlapping custom sounds and CON code. Sounds could be remapped partially, but if you have for example a custom shotgun sound that is only meant to be used in one map and not any of the others, you would start altering original gameplay. I guess in order for this to work completely, EDuke32 would also need to be able to load specific CON files for each map (e.g. cranium_game.con), and I think that's not possible.

Can it not look for all files within a directory with the map name?

[NightFright]

I don't know if it works this way now, but in that case, it wouldn't work with groupfiles... and for this project that would be essential.

Also note that I may have encountered a potential issue with per-map art files. Seems like if you load too many maps that use different versions of the same art file (e.g. tiles014.art), EDuke32 crashes to desktop - at least under certain circumstances.

[Helixhorned]

NightFright, on 10 August 2015 - 12:09 AM, said:

Another thing about .art files:
Especially problematic if you merge episodes. When many maps share the same .art files, duplicating those for each map would bloat the groupfile quickly.

I think a reasonable implementation of mapping ".map" files to arbitrary files for loading art from is to have a maphack command for that. That would also be in line with the "zero-configuration" philosophy of per-map ART files since ".mhk" files are auto-loaded based on the map filename as well.

[NightFright]

Something that currently prevents me from grouping some levels together is also different con codes, as mentioned above. However, I guess it'll remain wishful thinking to have map-specific con support since cons are loaded during game startup...

Besides that, it turns out that if EDuke32 finds definitions for the same variable, it would only use the first one and ignore the second. If you have for example something like define ALARM 357 and you want ALARM to be e.g. 400 for an addon or something, you basically have to include the whole defs.con with changed values instead of just writing a small patch con that only includes the lines that got updated. I see the purpose in this behavior, though, since it's also avoiding problems with accidentally redefined variables (and I guess more which I am unable to realize).

[LeoD]

Helixhorned, on 15 August 2015 - 11:52 PM, said:

I think a reasonable implementation of mapping ".map" files to arbitrary files for loading art from is to have a maphack command for that. That would also be in line with the "zero-configuration" philosophy of per-map ART files since ".mhk" files are auto-loaded based on the map filename as well.

Distributing a 'hack' with a map seems rather weird. And it would break/override the current system of loading archived maphacks based on the map's checksum. I assume that currently MHKs are loaded too late in the process,anyway. Something like mapname.def or mapname.ini seems more appropriate. As far as the Addon Compilation is concerned, you could implement something like:

definevolumename 4 XY EPISODE
definevolumeartmap tiles014.art XYEP_014.ART

definelevelname 0 0 E1L1.map 01:45 00:53 ADDON HOLOCAUST
definelevelartmap tiles015.art AD_HC_15.ART

NightFright, on 19 August 2015 - 02:59 AM, said:

Besides that, it turns out that if EDuke32 finds definitions for the same variable, it would only use the first one and ignore the second. If you have for example something like define ALARM 357 and you want ALARM to be e.g. 400 for an addon or something, you basically have to include the whole defs.con with changed values instead of just writing a small patch con that only includes the lines that got updated. I see the purpose in this behavior, though, since it's also avoiding problems with accidentally redefined variables (and I guess more which I am unable to realize).

You could ask for a redefine CON command...

[Hendricks266]

LeoD, on 22 August 2015 - 12:54 AM, said:

You could ask for a redefine CON command...

Place the dynamicremap (for art tiles) or dynamicsoundremap token at the beginning of DEFS.CON.

[NightFright]

It does the trick. Kindish. It's still only efficient with single maps, not when applying one .art file to several levels within a pack. But it'll do for my purposes. ^^

What to do with redefined quotes, though (e.g. when a mod replaces definequote 17 GOD MODE: ON)? Is there another way than having to provide the whole user.con again just with a few edited definequotes or can it be done as a patch, too?

[Hendricks266]

definequote can be issued multiple times.

[NightFright]

But isn't it like EDuke32 is only using the first define and ignores all the others with the same ID? It has been like that previously whenever I tried. I can check again now though, maybe something changed...

*EDIT Sep 21*
This is what EDuke32 shows me if I use a CON file with this content (among others). I guess re-issuing definequote for the same line/definition isn't a problem, however it is with define:

// Definitions

define GENERICIMPACTDAMAGE      15

define MAXPISTOLAMMO           120
define MAXSHOTGUNAMMO           40
define MAXCHAINGUNAMMO         200
define MAXRPGAMMO               20
define MAXHANDBOMBAMMO          10
define MAXSHRINKERAMMO          50
define MAXGROWAMMO              50
define MAXDEVISTATORAMMO       100
define MAXFREEZEAMMO           100
define MAXTRIPBOMBAMMO           5
define TRIPBOMBLASERMODE         1     

define PISTOL_WEAPON_STRENGTH            8
define HANDBOMB_WEAPON_STRENGTH        160

define RPG_WEAPON_STRENGTH              200

define SHOTGUN_WEAPON_STRENGTH          12
define CHAINGUN_WEAPON_STRENGTH         18

define TRIPBOMB_STRENGTH               140
define FIRELASER_WEAPON_STRENGTH        11 
define MORTER_WEAPON_STRENGTH           80
define BOUNCEMINE_WEAPON_STRENGTH      160

define LIZSTRENGTH             120

definequote 54        ASSAULT RIFLE!
definequote 63        AMMO FOR ASSAULT RIFLE!

Error:

EDUKE.CON:11: warning: ignored redefinition of `GENERICIMPACTDAMAGE' to 15 (old: 10).
EDUKE.CON:13: warning: ignored redefinition of `MAXPISTOLAMMO' to 120 (old: 200).
EDUKE.CON:14: warning: ignored redefinition of `MAXSHOTGUNAMMO' to 40 (old: 50).
EDUKE.CON:16: warning: ignored redefinition of `MAXRPGAMMO' to 20 (old: 50).
EDUKE.CON:17: warning: ignored redefinition of `MAXHANDBOMBAMMO' to 10 (old: 50).
EDUKE.CON:20: warning: ignored redefinition of `MAXDEVISTATORAMMO' to 100 (old: 99).
EDUKE.CON:21: warning: ignored redefinition of `MAXFREEZEAMMO' to 100 (old: 99).
EDUKE.CON:22: warning: ignored redefinition of `MAXTRIPBOMBAMMO' to 5 (old: 10).
EDUKE.CON:23: warning: ignored redefinition of `TRIPBOMBLASERMODE' to 1 (old: 0).
EDUKE.CON:25: warning: ignored redefinition of `PISTOL_WEAPON_STRENGTH' to 8 (old: 6).
EDUKE.CON:26: warning: ignored redefinition of `HANDBOMB_WEAPON_STRENGTH' to 160 (old: 140).
EDUKE.CON:28: warning: ignored redefinition of `RPG_WEAPON_STRENGTH' to 200 (old: 140).
EDUKE.CON:30: warning: ignored redefinition of `SHOTGUN_WEAPON_STRENGTH' to 12 (old: 10).
EDUKE.CON:31: warning: ignored redefinition of `CHAINGUN_WEAPON_STRENGTH' to 18 (old: 9).
EDUKE.CON:33: warning: ignored redefinition of `TRIPBOMB_STRENGTH' to 140 (old: 100).
EDUKE.CON:34: warning: ignored redefinition of `FIRELASER_WEAPON_STRENGTH' to 11 (old: 7).
EDUKE.CON:35: warning: ignored redefinition of `MORTER_WEAPON_STRENGTH' to 80 (old: 50).
EDUKE.CON:36: warning: ignored redefinition of `BOUNCEMINE_WEAPON_STRENGTH' to 160 (old: 150).
EDUKE.CON:38: warning: ignored redefinition of `LIZSTRENGTH' to 120 (old: 100).

*EDIT Sep 16*
In the meantime, time to show off some progress on my work for v2.0. I have recently added widescreen graphics to all addons which have customized statusbars. Here is an example of what it looks like in "Borg Nukem":

[FistMarine]

edit

[NightFright]

It wasn't exactly helpful to receive PMs like "When is it finished", "I want to play NOW", "Please add this, this and this" and so on. I think I am not the only one who would have reacted like this. I stick to my schedule, which is Christmas 2015, for everyone btw, and I will add what I can and what I am also allowed to add. And not everything is possible.

To return back to topic, the update is "feature complete" since one week ago. No further addons will be added. I have now shifted to playtesting and checking that everything works as flawlessly as possible. I am also still waiting for some potential EDuke32 issues to be checked, especially the mysterious problem with fake sprites in addons that use the sprite resizing bugfix. Also the menu fix for "Duke Hard" is on the list, but it must be done by the addon team, so nothing to do from my side other than wait.

The scale of this update has exceeded my own expectations and turned out to be so huge that it's actually gonna be a rerelease of the whole compilation. Pretty much every single addon has been touched somehow, sometimes less significantly, but in many cases more. After this, I expect this project to be finished for good. There may only still be updates in the future if problems pop up or new addons are released (provided I get permission to include them). As far as old stuff is concerned, the limit has been reached. Anything else that's out there is either too complicated to add properly, not allowed by the authors or simply garbage.

[FistMarine]

edit

[NightFright]

Status update:

After stopping to add more content, I have moved on to polishing. This included adding widescreen graphics where they were still missing (statusbars had been done before, now I moved on to weapons). This step is finished now as well. No more weapons being cut off in any addon of this collection (e.g. in Starship Troopers, Platoon, Borg Nukem and others) if you play in widescreen resolutions!

I will continue testing addons where I changed/fixed CON code to eliminate EDuke32 warnings.

What is still pending depending on others:
- Code fix for "Duke Hard" to display menu properly in newer EDuke32 snapshots (requested, can be delivered on demand)
- Investigation by EDuke32 coding team to check potential problem with sprite resize code (requested)

I am confident all issues get resolved till the third week of December which is when I intend to release.

[Kyanos]

I looked into WGR2 in your addon here, it's fairly broken with a few issues to point out.

1st, the key settings are gone. alt-fire, home for the pow menu, and r for pow don't work without being reset, you are missing the files wgr2.cfg and wgr2settings.cfg
(this one is almost insulting to the player, starting siege breaker axon tells duke using his new powers to destroy the rocks is his first challenge, but the keyboard isn't set up to do it)

2nd, the aiming of the shotgun zoom is off, it happened with a change within EDuke32 source code and has been fixed in our working svn. but it's broken very badly, worse over longer distances and sharper up/down angles.
(see this post https://forums.duke4...post__p__178040 , same issue as there, the fixed code is also in the knee deep cons)

3rd, the chest voxel is not coloured properly in the newest EDuke32, see pic


added: 4th, the best times show up in front of map names, only for one map episodes.

[NightFright]

The issue with the times showing up in level titles is already fixed in my local build. Apparently the game expects the format xx:xx for level times, but in the con it was only x:xx. Additionally, the skyboxes were broken (highres tiles had to be switched). This was corrected as well.

I am creating new config files from scratch in WGR2 and expected that all parameters needed would be added automatically - which apparently is not the case. I will add an autoexec.cfg to wgr2.dat with the following commands/vars that should fix it:

bind "R" "gamefunc_POW_KEY"
bind "Kpad7" "gamefunc_GAME_TIPS"
bind "Home" "gamefunc_GAME_TIPS"
cl_autoaim 0
r_size 0

I cannot see any problems with the chest voxel. It only works in classic (8-bit) renderer, btw (seems like voxel support in other rendering modes is still not available).

As for the shotgun zoom code, it would be helpful to know which code to replace and with what.

[Danukem]

NightFright, on 18 November 2015 - 12:51 AM, said:

As for the shotgun zoom code, it would be helpful to know which code to replace and with what.

Can you help him with that Drek?

[Kyanos]

NightFright, on 18 November 2015 - 12:51 AM, said:

I cannot see any problems with the chest voxel. It only works in classic (8-bit) renderer, btw (seems like voxel support in other rendering modes is still not available).

I'll get the model for the chest available for you. It does show in polymost, Ken wrote vox2poly for jfbuild which converts voxels to models when the game loads.

Trooper Dan, on 18 November 2015 - 02:32 AM, said:

Can you help him with that Drek?

Yeah, I just dug up the code changes, revisions 18-21 from 2011. It's pretty complex but shouldn't be hard as the work is already done.

[NightFright]

I already managed to implement the chest model from Knee-Deep, pal. Now the voxel is used in classic mode and the md3 model in Polymost/Polymer which is a fair compromise. All I still need is the fixed shotgun zoom code and pretty much anything you reported is solved.

In the meantime, another example screenshot of my widescreen update for the compilation - this time from "Starship Troopers TC". I added a widescreen statusbar and extended versions of the pistol and shotgun replacement weapons there.

[Kyanos]

NightFright, on 18 November 2015 - 07:47 AM, said:

All I still need is the fixed shotgun zoom code and pretty much anything you reported is solved.

Here it is.  WGR2GAME.2.zip (151.71K)
Number of downloads: 860

[NightFright]

Great! Checked ingame and works with latest EDuke32 snapshot (r5430). With this, all your four reported issues will be addressed in the upcoming release. Thanks a lot for your help!

[Danukem]

Drek, on 18 November 2015 - 06:06 PM, said:

Here it is. WGR2GAME.2.zip

I was trying to click + rep on your post and I accidentally clicked - rep, and I can't undo!

Anyway, thanks for your work.

[Kyanos]

You're both welcome.

[Kyanos]

NightFright, on 18 November 2015 - 12:51 AM, said:

I am creating new config files from scratch in WGR2 and expected that all parameters needed would be added automatically - which apparently is not the case. I will add an autoexec.cfg to wgr2.dat with the following commands/vars that should fix it:

bind "R" "gamefunc_POW_KEY"
bind "Kpad7" "gamefunc_GAME_TIPS"
bind "Home" "gamefunc_GAME_TIPS"
cl_autoaim 0
r_size 0

I looked into binding altfire to the right mouse button, I couldn't find a way to do it in autoexec.cfg. The engine wants wgr2.cfg and if it's not there it will make one with the mouse buttons from the standard eduke32.cfg.

I tried a lot of workarounds, short of just shipping with the original wgr2.cfg in the empty root folder the cleanest fix I found was this.

wgr2.cfg from seigebreaker goes into addons folder.
edit WGR2GAME.con on line 29 to hardcode in the addons folder.

setcfgname addons/wgr2.cfg

[NightFright]

It's not my favorite solution since I wanted to avoid having the game storing config files in the addons folder. However, I guess WGR2 is a special case that insists on this method, so I gotta implement it like that.

The only way it could work in another way maybe would be to include wgr2.cfg (possibly with a different name) in wgr2.dat and tell the game somehow to use this instead of eduke32.cfg to read from when creating a new settings file. However, I think EDuke32 doesn't offer such an option.

[Kyanos]

NightFright, on 20 November 2015 - 01:17 AM, said:

The only way it could work in another way maybe would be to include wgr2.cfg (possibly with a different name) in wgr2.dat and tell the game somehow to use this instead of eduke32.cfg to read from when creating a new settings file. However, I think EDuke32 doesn't offer such an option.

Inside the zip the config file is read only, it needed write access, I tried it that way too.

On another note, I noticed that the blue chests that use stashed gold needed a skin for the model, so I did a blue chest skin, it gets def'd in for pal 20.

[Reaper_Man]

I think I have some fixes to some bugs in the Grins of Divinity code somewhere. Let me try and dig it up over the holidays.

Quote

> I have not played this addon since level design seemed too confusing. Use at your own risk!

Yeah, ain't that the truth.

[NightFright]

I can provide you with the latest con file for Grins since I have removed some warnings in the meantime. Would save me some time if you managed to work with that one and add your fixes there.

I will give Grins another playthrough shot before Xmas, provided that a solution is found for that problem EDuke32 currently seems to have when applying sprite resize bug fixes.