[Kyanos]

That's awesome that you run the HRP on SSD, I was just pricing out solid state drives for my OS and a few apps to run on.

I think adding in command line option functions to the launcher is a good idea, maybe an advanced settings tab to keep things clean. Till then I'm gonna batch it up.
PS. I swear my dos/win 3.1 rig had this autoexec.bat in 1996. Long live bat files.

cd duke3d
duke3d

[Hendricks266]

Drek, on 25 August 2014 - 01:18 PM, said:

I think adding in command line option functions to the launcher is a good idea

Nope. The average tard who doesn't know how to bring up cmd.exe wouldn't know what to do with that box either. Anyone who does know would likely know how to open the command prompt.

Drek, on 25 August 2014 - 01:18 PM, said:

maybe an advanced settings tab to keep things clean.

That's not necessary. Per-mod settings would best be distributed with the mod in a format that I am (still) planning.

[LeoD]

Drek, on 25 August 2014 - 01:18 PM, said:

That's awesome that you run the HRP on SSD, I was just pricing out solid state drives for my OS and a few apps to run on.

It's 120GB:
- 40GB for a shits, giggles, and rescue Linux
- 80GB for Windows, including ~8GiB for Duke related stuff
SSD really makes a difference for booting or letting TortoiseSVN search for local HRP repo modifications.

Quote

cd duke3d
duke3d

[Fox]

There is no shiftvarvar command? Lame.

[Helixhorned]

Fox, on 15 November 2013 - 01:55 PM, said:

From actors.c:

        if (dasectnum < 0 ||
                ((actor[spritenum].actorstayput >= 0 && actor[spritenum].actorstayput != dasectnum) ||
                 (spr->picnum == BOSS2 && spr->pal == 0 && sector[dasectnum].lotag != ST_3) ||
                 ((spr->picnum == BOSS1 || spr->picnum == BOSS2) && sector[dasectnum].lotag == ST_1_ABOVE_WATER)
//                 || (sector[dasectnum].lotag == ST_1_ABOVE_WATER && (spr->picnum == LIZMAN || (spr->picnum == LIZTROOP && spr->zvel == 0)))
                )

What's the reason for that line being commented out? That's what is causing the issue with Troopers and Enforcers walking in water sectors.

I can't answer the first question as the change was in r1044, but uncommenting that line does not solve the issue with the current state of things: a LIZMANJUMP in an ST1 sector stops moving altogether then. 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.

[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?