[DisgustedGrunt]

TerminX, on 06 July 2019 - 10:54 AM, said:

Yeah, that's not what it's for. Have you been reading the posts in this thread?

My bad, didn't understand. Just to be sure, is the alt-weapon key gonna be added back, as a separate key?

[TerminX]

Yes, it's added back now. Just wait for it to compile.

[Danukem]

TerminX, on 06 July 2019 - 10:54 AM, said:

Yep, that's the idea. No more having to hijack whatever random gamefunc closest to the top that you were willing to sacrifice to have the option actually visible in the menu.

Alt fire is also bound to the second mouse button by default.

That's definitely an improvement, then.

A bigger improvement would be giving the modder control over which gamefuncs appear in the key/mouse binding menus, and in which order. But I guess that's hard to do.

[DisgustedGrunt]

TerminX, on 06 July 2019 - 11:05 AM, said:

Yes, it's added back now. Just wait for it to compile.

Thanks.

[Danukem]

TerminX, on 06 July 2019 - 11:05 AM, said:

Yes, it's added back now. Just wait for it to compile.

I'm making the switch, but unfortunately the game still crashes when changing a gamevar through the console. That means that to test certain things, it's still useful to be able to run an older revision, but that's impractical now that I'm making the script changes to accommodate the new keys.


So please fix the crash

[Danukem]

Would it be possible to associate an input bit with the new altfire key? It's useful to be able to check on whether the key is being pressed in contexts outside of the event code. I could do that before with the key I had bound to it. I'll have to do a significant amount of moving code around and rewriting otherwise. EDIT: I could set a var when the event fires, acting as a proxy for an input bit. But I'm wondering if there will be something in the input structure.

[Micky C]

pogokeen, on 26 June 2019 - 04:55 AM, said:

Thanks for the heads up about that issue, Micky C.

I'll take a look & get that fixed. Once I have a solution in place, I'll let you know here.

Any update on this? Ion Fury has priority of course, and this is a non-urgent albeit critical bug.

I also see that Ion Fury will be released on Mac as well next month. Does this mean that eduke32 will have mod support on Mac that works largely out-of-the-box?

[Hendricks266]

Please let me know if r7794 breaks anything related to collision.

[Danukem]

Quote

r7815 | hendricks266 | 2019-07-21 20:24:35 -0700 (Sun, 21 Jul 2019) | 1 line

Don't lock out cheats in skill 4 if FURY

I've always hated that in Duke, too, but I guess you want to preserve the original behavior.

[Forge]

Micky C, on 26 June 2019 - 03:59 AM, said:

The slopes in classic mode are much more stable at extreme angles now, kudos to Nuke.YKT. They still become warped and fullbright at large distances though, not sure if that's possible to fix.

Using r7750 64-bit mode, the AMC TC crashes upon startup when using polymost but not classic. Using debug eduke32, the last line in the log reads as follows:

tilepacker: kdtree_reserveNode(): out of nodes

pogokeen, on 26 June 2019 - 04:55 AM, said:

Thanks for the heads up about that issue, Micky C.

I'll take a look & get that fixed. Once I have a solution in place, I'll let you know here.

any idea what may be causing this?
I get:

gltexinvalidateall()
gltexinvalidateall()
polymost_glreset()
tilepacker: kdtree_reserveNode(): out of nodes
tilepacker: kdtree_reserveNode(): out of nodes


windows10x64
fx 8320
nvidia gtx 650 ti
polymost mode
eduke32_win64_debug_20190724-7842

Pretty sure it has something to do with the number of art files.

Appreciate the juggling act the dev team is doing for us. Really.

[TerminX]

Do you guys still use that SVN repo we set up for you a long while back? Are the contents of that repository something we can use to test the breakage?

[Forge]

TerminX, on 25 July 2019 - 10:47 AM, said:

Do you guys still use that SVN repo we set up for you a long while back? Are the contents of that repository something we can use to test the breakage?

The AMC svn repo?
Yes. It is actively updated and has the most current content.
That is what I used to test & what gave me the error message in my last post.

[Paul B]

Hendricks266, on 15 July 2019 - 11:01 PM, said:

Please let me know if r7794 breaks anything related to collision.

Hi Hendricks, I've come across a collision problem that was never present in older builds and now is present. In my map The Rock I have a TROR sos stairwell. Duke is getting caught on an invisible white wall in one direction. Going down the stairs. Going up the stairs Duke doesn't get blocked. Bullets appear to pass through this invisible wall just not the player.

I'll try to collect more information for you about the problem and i'll post back here.

*** UPDATE *** Okay somewhere in download r7831 introduces the problem with Duke being blocked by an invisible wall. Or a wall that perhaps maybe overlapping due to SOS. This looks like an update by Terminx. My guess is the problem lays somewhere between R7826 - R7831

While I'm mentioning things. You guys might already be aware of this problem but climbing sprite ladders in these newer builds is no where near as good and sometimes not possible. This does impact the game play where levels rely on this function to work.

On the plus side I have noticed great improvements in FPS and game performance. As well improvements with TROR in Polymost and water surfacing SE 7 TROR sectors. Keep up the good work everyone! One day this engine will be able to handle my new overly used TROR map. Oops did I just spill the beans. =P

[Micky C]

The beans are spilled.

I have also been looking into a TROR clipping issue. This involves a TROR layer above the player that the player should (and normally can) jump through, where the ceiling is 11264 units above the floor. When the player is standing on the floor, or on a floor-aligned blocking sprite that is on the floor, the player can jump through no problem. However, if you lower the floor, and place either a floor-aligned blocking sprite or a view-aligned sprite such that the player is standing at the same height as before, the player cannot jump through.

I guess it's something to do with the player's height being exact that of the TROR ceiling? To simplify the above paragraph, the player can jump fine from a sector, but not from a sprite, if there's exactly that amount of room.

[pogokeen]

The issue with the tilepacker should resolved now with r7849 & r7851. Thanks to Doom64hunter for spotting the bug!

[Micky C]

Thanks for applying the fixes.

I see over at dukeworld that 7874 is still the latest. Any idea when the next release will be available?

[Micky C]

And I have finally learned to read! Ignore my last post

[Micky C]

A slope-related clipping issue.

The height of the ceiling firstwall seems to dictate the maximum height of the sector when you're trying to jump or jetpack into it. Looking at the image below, the player isn't able to pass above the red line. Ignore the TROR, this happens even without it. I've attached an example map. This is using 7885, currently the latest available.

Attached File(s)

•  CLIPISSUE.zip (2.78K)
  Number of downloads: 395

[Forge]

Maybe related, maybe not - to that non-tror "submarining" clipping issue I experienced using the boat in amc tc.

In a basic sos/ror situation - if the ceiling height of the room below is higher than the floor height of the room above, the player will clip into the lower sector simply by "boating" upon the upper room's floor and crossing a sector line of the room below.

it doesn't do it except under certain circumstances & there were submersible tror water sectors on the same plane not far from the basic sos/ror

I amended my post because I went senile with my description. It still probably doesn't make any sense

[Paul B]

Micky C, on 04 August 2019 - 05:22 AM, said:

A slope-related clipping issue.

The height of the ceiling firstwall seems to dictate the maximum height of the sector when you're trying to jump or jetpack into it. Looking at the image below, the player isn't able to pass above the red line. Ignore the TROR, this happens even without it. I've attached an example map. This is using 7885, currently the latest available.

This sounds like we all are explaining and experiencing the same problem. Well said Micky. I've submitted a sample map to the devs here: https://forums.duke4...599#entry326599

[DisgustedGrunt]

In r7885 only spacebar and enter skips the intro videos, the rest of the keys don't do anything. If this is intentional, could at least skiping with escape be added back?

[DisgustedGrunt]

Lazy Dog, on 04 August 2019 - 09:06 AM, said:

In r7885 only spacebar and enter skips the intro videos, the rest of the keys don't do anything. If this is intentional, could at least skiping with escape be added back?

Also, you can enter through the window in e1l1

[DisgustedGrunt]

Lazy Dog, on 04 August 2019 - 09:06 AM, said:

In r7885 only spacebar and enter skips the intro videos, the rest of the keys don't do anything. If this is intentional, could at least skiping with escape be added back?

Fixed in r7894, thanks.

[Sangman]

Micky C, on 04 August 2019 - 05:22 AM, said:

A slope-related clipping issue.

The height of the ceiling firstwall seems to dictate the maximum height of the sector when you're trying to jump or jetpack into it. Looking at the image below, the player isn't able to pass above the red line. Ignore the TROR, this happens even without it. I've attached an example map. This is using 7885, currently the latest available.

Haven't checked in-game but should be fixed as of r7918 if the commit messages are accurate

[Hendricks266]

r7919 updates our Windows version of SDL to 2.0.10. Please let me know if this introduces any new issues.

[Danukem]

Holy shit you are finally adding proper game controller support.

[Micky C]

Looking at the change for r7955 about the bug of standing on sprites underwater making the player act as though they are not underwater.

Some maps actually use that as a feature, and there was the alternate workaround added where if the sprite has a hitag, then it does not display this bug.

Is this the sort of thing which should be restricted to the standalone builds? It may make some maps unbeatable. Not many, sure, but some.

[Forge]

Micky C, on 11 August 2019 - 08:25 PM, said:

Looking at the change for r7955 about the bug of standing on sprites underwater making the player act as though they are not underwater.

Some maps actually use that as a feature, and there was the alternate workaround added where if the sprite has a hitag, then it does not display this bug.

Is this the sort of thing which should be restricted to the standalone builds? It may make some maps unbeatable. Not many, sure, but some.

BobSP4 uses the feature so the player can get to the bottom of an under water chasm quickly to preserve some oxygen in the player's scuba tanks.
This is just one map of many.

There is a map or two that also uses the feature to simulate spacewalks on the sides of crafts and across scaffolding between spaceships.

[HellFire]

Bugfixes like that should be enabled via an option in the menus (or a console flag, whatever), IMO.

[Hendricks266]

It would be trivial to change r7955 to only apply in FURY mode. Patches welcome because I can't mess with this right now.