[Hendricks266]

CraigFatman, on 22 February 2014 - 01:45 PM, said:

But can we use this with rotatespritea command?

We are planning to pack the blend member into upper bits of the alpha parameter for rotatespritea and screentext. Probably bits 8-15 (shiftvarl 8).

CraigFatman, on 22 February 2014 - 01:45 PM, said:

Doing "setactor[THISACTOR].blend 1" on EVENT_GAME makes all the HUD to use this blend mode too.

That's weird.

[Fox]

Would it be possible to automatically remap all lookup tables to transform color 255 into 0? That would effectively solve some problems. It would fix the glitch involving translucent textures over a wall/floor textures that uses the transparent/magenta color. Also any wall/floor textures that uses the transparent color would be properly displayed as black in the map editor, while it would still be magenta in the tile browsing.

[MetHy]

About the feature that makes enemies with palettes other than the original one tougher, has that been disabled in any recent eduke32? and if not, when will it be disabled? In the meantime, can you tell me WHEN that was implemented so that I can download the last old eduke32 without that 'feature'?

That was really a terrible idea. Each time I want to play a map and it has enemies with different palettes, the whole balance is ruined and it pisses me off. Tons of maps are unplayable because of that. They take forever to die (more than any 'enhanced' enemy should anyway) and they seem to deal more damage, too. When you're facing even only 2 or 3 enhanced enemies at once that weren't supposed to be like that, it's already too much and shouldn't be like this... not to mention that some maps use DOZENS of those.

If anything the idea of having a super enemy is cool, but it should be left as a decision to the mapper instead of making it mandatory for every non original palette. It should be a feature a mapper can able on any enemy regardless of palette (and if the map is played in non-eduke32 duke3D or in an older eduke32 version they would remain normal enemies, and not make the map eduke32-only just for that one enemy).

[Jblade]

It was like that in the original V1.3D version of Duke, which is why it was added back in - it hasn't proved popular of course, but it would of been nice if Eduke could detect what version the map is made for and amend it that way.

[MetHy]

What? Are you kidding me? I don't believe that at all until I see it with my own eyes. Or perhaps it got taken out in 1.4 and 1.5 which is what most maps are made for anyway. So, it should only happen in maps made for v1.3D.

What's weird is that I do not remember red teleporting liztroops act like that in the original game. Then again, I haven't played v1.3 in more than a decade.

[Jblade]

IIRC it only did it to Pigcops, but I am not fucking with you - I'm fairly sure it only did it to pigcops with a spritepal of 13 or 14 though. Look up an old map called ARMYCAMP, the author makes a brief mention of it there. I played with V1.3D for many years before I got my hands on the atomic edition.

[LeoD]

MetHy, on 23 February 2014 - 03:41 AM, said:

About the feature that makes enemies with palettes other than the original one tougher, has that been disabled in any recent eduke32? and if not, when will it be disabled?

All requests to change that back have been ignored so far.

MetHy, on 23 February 2014 - 03:41 AM, said:

In the meantime, can you tell me WHEN that was implemented so that I can download the last old eduke32 without that 'feature'?

I took a note that it was r3102, so r3101 should be your choice.

[MetHy]

James, on 23 February 2014 - 04:49 AM, said:

IIRC it only did it to Pigcops, but I am not fucking with you - I'm fairly sure it only did it to pigcops with a spritepal of 13 or 14 though. Look up an old map called ARMYCAMP, the author makes a brief mention of it there. I played with V1.3D for many years before I got my hands on the atomic edition.

If it only happened to pigcops, what eduke32 has implemented is completely different as it works on every single enemy. Should be disabled or at best like I said, make it so that mappers decide. This single feature succeeded in ruining the balance of hundreds of maps and renders tons of them unplayable. It's like "Hmmm, how could I ruin 10 years of effort making this port while at the same time ruining hundreds of mappers effort?". I'm not even exagerating.

[Fox]

Yes, it was like that in v1.3D and was removed in Atomic Edition.

[Jblade]

I was the one who requested it I think, although I don't know who added it in. It was never intended as a malicious gesture and I didn't put much thought into it at the time (such is the benefit of hindsight) I just remember thinking it was cool that you could make stronger pigcops in V1.3D without con edits and thought it was a shame they took it out in v1.5.

[Fox]

Nonetheless, Eduke32 should prioritize Atomic Edition above v1.3d in case of conflict like this. Or at least apply such hack only to v1.3d...

[Danukem]

I think this is what James posted that spurred the change: http://forums.duke4....post__p__139246

Then shortly after, TerminX posted this: http://forums.duke4....post__p__139294

Apparently this major change was implemented without any other discussion or fanfare.

[MetHy]

How it should be : pigs with pal 13 and liztroops with pal 21 should be tougher in v1.3D

How it was implemented : every enemy of every non 0 palette of every version is made tougher

[Helixhorned]

CraigFatman, on 22 February 2014 - 01:45 PM, said:

Doing "setactor[THISACTOR].blend 1" on EVENT_GAME makes all the HUD to use this blend mode too.

Are you using the most recent build? This sounds like the bug that James reported earlier and was fixed with r4338.

[MusicallyInspired]

Yes, I remember that from 1.3D. It was the only version I had for years and I ran into that while experimenting with creating maps. There's one palette that makes the pixels around certain monsters' mouths red so it looks like they're bloodthirsty and really dangerous. Quite effective with the added difficulty.

[Hendricks266]

James, on 23 February 2014 - 03:51 AM, said:

it would of been nice if Eduke could detect what version the map is made for and amend it that way.

No such thing is possible. However, it would be possible to only implement the effect when a v1.3D GRP is selected.

[Helixhorned]

Fox, on 22 February 2014 - 06:56 PM, said:

Would it be possible to automatically remap all lookup tables to transform color 255 into 0? That would effectively solve some problems. It would fix the glitch involving translucent textures over a wall/floor textures that uses the transparent/magenta color. Also any wall/floor textures that uses the transparent color would be properly displayed as black in the map editor, while it would still be magenta in the tile browsing.

What we do now is to tweak the main translucency table if a Duke3D 1.5 or LameDuke translucency table is detected: for every i, 0 <= i <= 255, we set

transluc[255][i] = transluc[0][i]
transluc[0][i] = transluc[255][i]

This fixes the first issue you mention: a background color index 255 blended with a foreground color will yield a result as if the background had been color index 0.

What's left for vanilla Duke3D 1.5 is that in Mapster32, color index 255 is displayed as magenta for solid walls (in the game, the base palettes are modified shortly after being loaded, setting index 255 to a black color for the default, water and slime base palettes). In Mapster32, the Lunatic 'engine' module functions like engine.setblendtab and engine.setshadetab allow registering the tables as many times as desired (for the game, we error if an already registered one is attemted to be set again). So, the tweaks you mention can be easily implemented in Lua code and the command running them added to m32_autoexec.cfg.

We don't modify the translucency table if the loaded one differs from the Duke3D 1.5 one because mods may be using row/column 255 for their own purposes. The LNGA page for example states:

Quote

LNGA uses a table of color addition. The last row and column correspond to the transparent color (0xFF); they are dedicated to non-linear conversions.

Edit: so a solution would probably be allowing re-registering tables 0 in the game for the engine.* functions? Otherwise, there's no way to change palookup/blend 0 programmatically at startup.

[Helixhorned]

MusicallyInspired, on 23 February 2014 - 09:08 AM, said:

Yes, I remember that from 1.3D. It was the only version I had for years and I ran into that while experimenting with creating maps. There's one palette that makes the pixels around certain monsters' mouths red so it looks like they're bloodthirsty and really dangerous. Quite effective with the added difficulty.

Interesting. The only difference between 1.3D and 1.5 lookups is for pal 2 though, in the fourth-to-last 16-tuple of consecutive indices, the orange ramp with a "bend" in the middle when plotted. The default base palette and shade table are identical. This leaves the tiles themselves, might be interesting to compare them byte-wise.

[Hendricks266]

Pal 24:

[Helixhorned]

About sprite rotation-fixing again. I think I'll hold EVENT_ROTFIXSPRITE for now. It should be possible to rotation-fix CAMERA1 by declaring it a type-4 useractor. Since it doesn't have actor CON code on its own, its functionality will not be lost. If people realize that this trick isn't enough, for example because they don't want the hard-coded rotation-fixing for particular sprites, that's when EVENT_ROTFIXSPRITE will come into play.

[Fox]

Hendricks266, on 23 February 2014 - 10:03 AM, said:

No such thing is possible. However, it would be possible to only implement the effect when a v1.3D GRP is selected.

Instead of checking the bytes of the GRP, wouldn't it be better to detect the version of the CON files? The number of entries in gamestartup command is a giveaway.

[HellFire]

Hendricks266, on 23 February 2014 - 10:03 AM, said:

No such thing is possible. However, it would be possible to only implement the effect when a v1.3D GRP is selected.

I think a better idea would be: add a "Gameplay options" menu which would behave in a similar way to the one with same name from G/ZDOOM. In there, options like "1.3d monter's pal behavior", "1.3d kick behavior" (you know, being able to kick with both legs at the same time) as well gameplay changes introduced by eduke32 could be toggled by the user himself, if he likes.

[Plagman]

Quickly go through the walls and sprites to check for tile numbers that correspond to Atomic Edition would maybe be a good first approximation?

[Hendricks266]

Fox, on 23 February 2014 - 03:07 PM, said:

Instead of checking the bytes of the GRP, wouldn't it be better to detect the version of the CON files? The number of entries in gamestartup command is a giveaway.

The code would be using the existing game-mode check, so (!PLUTOPAK) or something like that.

[MetHy]

HellFire, on 23 February 2014 - 03:13 PM, said:

I think a better idea would be: add a "Gameplay options" menu which would behave in a similar way to the one with same name from G/ZDOOM. In there, options like "1.3d monter's pal behavior", "1.3d kick behavior" (you know, being able to kick with both legs at the same time) as well gameplay changes introduced by eduke32 could be toggled by the user himself, if he likes.

I love this idea!

[Cage]

The idea is nice, but is it really needed? Besides the kick and palette/strength behavior, I can't think of anything else from the top of my head - then again, it's been 10+ years since I've played 1.3d. Besides, those pretty minor, since they're not exactly game braking - the biggest use of such a menu would be, if there are any bigger engine changes, like the behavior of map/sector effector effects, texture or collision handling, etc. which could potentially break the gameplay or looks of the older releases.

Zdoom has so many options, since it incorporates a lot of changes from the strict vanilla behavior, both of it's own as well as of the Boom port which features are incorporated in, plus it run multiple games, so it has toggle switches for Hexen/Heretic related stuff. This is to unsure that old mods are perfectly playable.

[MetHy]

Cage, on 25 February 2014 - 12:58 AM, said:

The idea is nice, but is it really needed? Besides the kick and palette/strength behavior, I can't think of anything else from the top of my head - then again, it's been 10+ years since I've played 1.3d. Besides, those pretty minor since they're not exactly game braking

Pretty minor?! The palette behaviour literaly makes tons of maps unplayable. I don't know how to call other than game breaking.
Also, another change that menu could do is being able to disable independent sprite shading behaviour for people who want everything to look like in the original game.

[Cage]

Okay, I did test this and shit, it really is terrible! Returning honor then.

Although I think that doing a new menu set will require time/effort, so I would just revert back to the old behavior until the Eduke devs will have time to implement a compatibility flag menu (If they choose to do so.)

[Helixhorned]

I don't have a strong opinion about non-zero pals making enemies thougher, but that may be simply because I haven't experienced it in action yet (or I didn't notice). Judging by the responses though, it breaks the balance of many user maps made in the 1.5 era. So maybe rather than hard-coding it, it could be provided as a CON mutator? After all, the effect is easy replicate in EVENT_SPAWN. You could even detect the presence of 1.3D versus 1.5 CONs by e.g. checking the value of SHRINKERBLASTRADIUS (650 vs. 680). TX, what do you think?

A menu is out of the question until menus.c gets de-uglified.

[MetHy]

The idea of having tougher versions of enemies is in essence pretty good. If it was something a mapper could activate at will, it could add something to the gameplay. The problem here is that people used palettes because they thought it looked cool, not because they wanted twice as tough aliens, they never intended it. Even only 2 or 3 tougher enemies can completely ruin the balance of a map as many usermaps tend to be very tight in ammo and health. Now, try a map where half of the enemies use those palettes, but still with ammo/health ratio made for normal enemies... (and that's without mentionning maps in which EVERY enemy used a non default palette)

But now, as for tougher enemies themselves, even if their presence is intended and the map thought around it, they still have one issue : they make the shrinker even more overpowered than it already is (because the shrinker will still let the player kill them in one hit, as tougher as they are)