[Fox]

Quote

a LIZMANJUMP in an ST1 sector stops moving altogether then

Doesn't it work like that in the vanilla game?

Quote

The block that runs if the condition is true returns early from the function, thereby not reaching TROR-related code, so keeping the line commented out seems sane.

I think it's more important to make the original maps work first.

[Fox]

So I noticed this in the source code:

        if( sprite[spritenum].xrepeat > 60 )
            retval = clipmove(&sprite[spritenum].x,&sprite[spritenum].y,&daz,
&dasectnum,((xchange*TICSPERFRAME)<<11),((ychange*TICSPERFRAME)<<11),
1024L,(4<<8),(4<<8),cliptype);
        else
        {
            if(sprite[spritenum].picnum == LIZMAN)
                cd = 292L;
            else if( (actortype[sprite[spritenum].picnum]&3) )
                cd = sprite[spritenum].clipdist<<2;
            else
                cd = 192L;

            retval = clipmove(&sprite[spritenum].x,&sprite[spritenum].y,&daz,
&dasectnum,((xchange*TICSPERFRAME)<<11),((ychange*TICSPERFRAME)<<11),
cd,(4<<8),(4<<8),cliptype);
        }

Essentially the clipdist value is override when the game is processing the sprite collision, and the size of the hitbox that controls the collision of one sprite with others may be different (from other sprites collision with it).

The huge problem here is that the value is hard-coded and there is no access to it right now.

Edit: I think the best solution would be if you could manually set the sprite width with the movesprite command.

[Fox]

I was wondering, would it be possible to change the size of an array when a map is loaded? It would be great for optimization.

Right now I am using stuff like this:

gamearray sectormusic 16383

But it would be great if I could do this:

gamearray sectormusic NUMSECTORS

[Hendricks266]

...resizearray?

[Fox]

NICE.

Edit: It seems to not be working for the current map.

For example:

onevent EVENT_LOADACTOR
  ifvare THISACTOR 0
    resizearray <array> NUMSECTORS

This will only have effect after you die or load another map (and it keeps the value of the last map).

[Jblade]

Is there any info I can read up about the reverb effect in the game? (or is it simple enough that a rough glimpse at the source will do) I'm just curious what the values do (from what I tested stuff under 100 doesn't seem to do much) would it be possible to add further things to it like increasing the sound delay so we can have echos and stuff as well?

[Jblade]

Voxels appear to be broken in the latest snapshot and don't appear at all ingame (I switched to latest snapshot, they were gone, went back to an earlier one (21st August 2014) and they appeared again so it's nothing on my side)

[Fox]

Classic aspect ratio (left) vs new aspect ratio (right):


With the new aspect ratio the game world is stretched vertically, note how some pixels are not visible on the top of the parallaxed sky. Wouldn't it be better to change the width instead of the height, since the screen width already varies depending of the screen size?

That would be changing the default FOV to 92.34º instead of 90º.

[MetHy]

I've been playing some Duke3D in Dosbox lately, and I keep having the feeling that in some situations the player can switch weapons faster in EDuke32 than he could in the original game.

It's a bit hard to explain and it's not something I can record (because you wouldn't know when I press the key), but basically I feel like in the original game when you press the key of another weapon while the reloading frames of the weapons, it takes longer to switch weapons in DOS than in EDuke32. Sometimes if you press another weaopn key and then the shoot button, it will even keep firing the weapon you're currently handling before switching weapon. It seems to be the more noticeable when you're switching from shotgun to something else (try shotgun to pistol for instance).

Does anyone have that feeling as well or is it just me? If it's true it is quite a big deal as it makes EDuke32 MUCH easier than the original game in some cases (you'd have time to kill an enemy before he'd shoot again in the original game).

[Kyanos]

It's not just you, it's default EDuke32 behavior and does differ from DOS.

[Hendricks266]

 MetHy, on 24 September 2014 - 10:59 AM, said:

I've been playing some Duke3D in Dosbox lately, and I keep having the feeling that in some situations the player can switch weapons faster in EDuke32 than he could in the original game.

This was done so that binding next/previous weapon to the mousewheel isn't completely useless.

[Micky C]

Does he mean that's it's faster to switch between weapons in eduke32 as in you can switch to another weapon while you're still selecting the current weapon, or does he mean that the raw weapon switching time is faster?

If it's the former, then it's what Hendricks said, and IMO it's very useful and convenient, even if it does make the game ever so slightly easier. Megaton doesn't have this feature and it's noticeable in a bad way. If it's the latter, then there may be a bug?

[MetHy]

 Micky C, on 24 September 2014 - 04:04 PM, said:

Does he mean that's it's faster to switch between weapons in eduke32 as in you can switch to another weapon while you're still selecting the current weapon, or does he mean that the raw weapon switching time is faster?

If it's the former, then it's what Hendricks said, and IMO it's very useful and convenient, even if it does make the game ever so slightly easier. Megaton doesn't have this feature and it's noticeable in a bad way. If it's the latter, then there may be a bug?

It's the former, and I think it's pretty bad. It's not accurate at all, and it means that in a situation when an enemy would have shot you, he wouldn't have time to do so if playing in EDuke32. This may not sound like a big deal when you put it this way, as in 'one enemy shot', but multiply this by every enemy, or worse, think of it in situations when you're surrounded by enemies, it can lead to situations when you should be dead but aren't. It can easily become a big balance issue.

Also, there are plenty of instances when playing where I start hitting an enemy with the shotgun, but switch the pistol to finish him (to save ammo), and I'm sure plenty of players do this. It's a very viable tactic in EDuke32, while it shouldn't be that viable since switching to the pistol should take longer.

Whether it makes gameplay 'better' is not the question. At best it should be an option that is turned off by default and that you can turn on in the settings.

I don't see how the 'mouseewheel' change the matter. It just means that if you're turning the mousewheel during a reloading frame, the game will wait a bit before switching weapon, just like when you're pressing a weapon key in the original game.

[MusicallyInspired]

As far as the mousewheel is concerned, I think he meant that you can switch between multiple weapons at once before the weapon select animation finishes. Otherwise you'd just be scrolling once per weapon which would suuuuck. It's the same as selecting the weapon by number in DOS on the keyboard, really. Actually, technically scrolling and selecting the right weapon would actually be a bit SLOWER unless you were very good at it.

[Hendricks266]

 MetHy, on 25 September 2014 - 05:06 AM, said:

Whether it makes gameplay 'better' is not the question. At best it should be an option that is turned off by default and that you can turn on in the settings.

Maybe it could be a cvar that is on by default. But that's it.

[MetHy]

Funny how that's not how you react at all when we're talking about Megaton accuracy.

[Hendricks266]

Wait a minute... I misread your post. Canceling a reload by weapon switching is a bug. I'll run it by TX.

The mousewheel behavior should probably be a cvar anyway... it might help the original demos run in sync.

[Fox]

No, there IS something wrong with how Eduke32 handle switching weapons. If you select another weapon while the current one is being raised, it will magically disappear. Instead it should work the same way as ZDoom: the current weapon being raised will begin to lower.

From a technical point of view, you should never force the value of weapon_pos. Instead, if the value of weapon pos is greater than zero, multiply by -1.

Edit: There are other problems with how Eduke32 handle weapon switching. It stops the weapon animation/realoding completely. Also you cannot switch weapon while holding the quick_kick button, but it does with the firing button (in the vanilla game it will never switch if you hold the firing button).

[MetHy]

Why can't I use both Mighty Feet at the same time even with an 1.3 grp ?

Spoiler

[The Commander]

[Lunick]

 MetHy, on 29 September 2014 - 05:35 AM, said:

Why can't I use both Mighty Feet at the same time even with an 1.3 grp ?

Spoiler

Because EDuke itself doesn't run on that code, it is just running in compatibility mode for older GRPs.

[MetHy]

But being able to use both feet is like the only reason to still use an 1.3 grp...

What about coding it so that it's only possible if EDuke32 is using a 1.3 grp ?

Though personally I believe that an extra settings menu for this kind of behaviour would be very nice. The player could turn on/off at will things like being able to use both feet, custom palette enemies being stronger, etc etc

[TerminX]

Didn't you see Commander's videos? Showing Duke's third leg is not OK!

[MetHy]

In my point of view, what matters isn't whether or not it's okay, but how it was in the original game. I see both feet as part of the gameplay of the 1.3 version, and the only reason why anyone would bother to look for a 1.3 GRP.

[TerminX]

Don't some of the maps have differences that allow the sector collision checking glitches to be exploited more freely?

[Fox]

 MetHy, on 29 September 2014 - 11:21 PM, said:

But being able to use both feet is like the only reason to still use an 1.3 grp...

What about coding it so that it's only possible if EDuke32 is using a 1.3 grp ?

Though personally I believe that an extra settings menu for this kind of behaviour would be very nice. The player could turn on/off at will things like being able to use both feet, custom palette enemies being stronger, etc etc

Eduke32 is v1.5 but it can also load v1.3d GRP. Besides, as far I know the source code for v1.3d was never released, so it would be based purely on guesswork.

And in v1.1, Duke Nukem would lower his weapon, kick, and raise his weapon back (that's why it show the "Mighty Boot Engaged" message). That style is as valid as v1.3d.

[Hendricks266]

 Fox, on 30 September 2014 - 05:13 AM, said:

Besides, as far I know the source code for v1.3d was never released, so it would be based purely on guesswork.

We've found it among the beta assets. Haven't done anything with it, or looked at it really.

We also found some interesting code suggestive of ROR...

[MetHy]

I just reinstalled v1.3 in DOSBox, and I really didn't remember that you can't kick slimers trying to eat you in v1.3. I actually kind of like that, it makes them more dangerous and annoying enemies rather than how useless they are in 1.4.

Anyway, my point is I would love it if you used that 1.3 code you have and made a sub-menu in the settings of EDuke32 where the player could turn on/off 1.3 behaviour at will (double kick, being able to shoot or not slimers eating your face, etc).
You could even use that menu for other behaviour like making enemies with custom palette stronger....

Speaking of that, I recall people saying that red Liztroops had more HP in 1.3. I just tried it and they die just as fast as in 1.4....

[Hendricks266]

 MetHy, on 30 September 2014 - 09:06 AM, said:

Anyway, my point is I would love it if you used that 1.3 code you have and made a sub-menu in the settings of EDuke32 where the player could turn on/off 1.3 behaviour at will (double kick, being able to shoot or not slimers eating your face, etc).
You could even use that menu for other behaviour like making enemies with custom palette stronger....

Novelty crap like that would at best be a cvar. Someone wants to be a power user? They need to learn how to use the damn console. The menus are getting cleaned out and simplified; adding a ZDoom-esque trash heap of "compatibility" options just looks messy and is unnecessary for someone looking to just play the game.

 MetHy, on 30 September 2014 - 09:06 AM, said:

Speaking of that, I recall people saying that red Liztroops had more HP in 1.3. I just tried it and they die just as fast as in 1.4....

You're thinking of Pig Cops with alt-pals.

[MetHy]

 Hendricks266, on 30 September 2014 - 10:32 AM, said:

Novelty crap like that would at best be a cvar. Someone wants to be a power user? They need to learn how to use the damn console. The menus are getting cleaned out and simplified; adding a ZDoom-esque trash heap of "compatibility" options just looks messy and is unnecessary for someone looking to just play the game.

I don't understand, 1.3 is just as valid as an official DN3D release as 1.4/1.5. If anything, I don't have the sales numbers to prove it, but I'm sure more people played 1.3 than they did 1.4/1.5.

The "2 feet" thing can be considered a fix, but the slimer thing is very arguable whether it improves the game or not; but in any case "which is better" shouldn't be the question.

With the menu, people who'd see it and don't understand what it does would simply leave it be. That's what people do with Zdoom. 1.4/1.5 behaviour could (should) be the default.