◄►469 Patch Discussions◄►

[Feralidragon]

XOpenGL is still the slowest regardless of the used card and drivers, but it's also the most future-proof one out of all of them.
It will still need a lot more iterations in future patches before it gets to the level of the older ones or better.

Whereas for UTGLR (OpenGL and D3D9) it's down to the card you use and drivers.
Theoretically, OpenGL should be faster on nVidia cards, and D3D9 should be faster on AMD cards, and that's simply because AMD OpenGL support sucks big time, their drivers are still quite terrible for OpenGL.

AMD is never going to improve it either, since there's Vulkan now, so the only way to satisfy both cards equally is through a Vulkan renderer, but that's unlikely to happen anytime soon (I know someone started to do one, but haven't heard any updates for a while now).

Of course, there are exceptions, that's why you should simply try all of them and use the one that works best for you.

[Eternity]

(I know someone started to do one, but haven't heard any updates for a while now).

It might be this one. It's been almost half a year with no updates.

What about a little script that checks for such duplicates?

I used find/sort/uniq combination to fix this problem:

Code: Select all

find * -printf '%f\n' | sort -f | uniq -id

[Barbie]

What about a little script that checks for such duplicates?

I used find/sort/uniq combination to fix this problem:

Code: Select all

find * -printf '%f\n' | sort -f | uniq -id

Yes, I know how to find duplicates. But I didn't know that I have to look for them. My suggestion was more to give the user a hint that there may be duplicate file names, either by a readme or a small script.

Another point: I noticed that the lever is not movable any more in map MH-Subway+SBFix1 (see pic) when this map runs on server with v469b, tested with client v436 and v469b. Has the interaction between movers and players also changed in 469 versions?

[Buggie]

My suggestion was more to give the user a hint that there may be duplicate file names, either by a readme or a small script.

https://github.com/OldUnreal/UnrealTour ... issues/256

--- EDIT ---

that the lever is not movable any more in map MH-Subway+SBFix1 (see pic) when this map runs on server with v469b, tested with client v436 and v469b.

Practice mode on v469b is fine.

--- EDIT ---

Dedicated server v469b also fine.

[Gustavo6046]

v469b wIth OldSkool does seem to screw with the lever in the lift to the execution room, at the start of the Vortex Rikers level. If you stepped at it, it would jitter in place and make a loud noise, instead of flipping like intended.

This has been a bit of a while ago, I don't like leaving OldSkool enabled because it screws with the music in UT matches (at least in botmatches), quickly fading them back to the UT menu song everytime I started a level, although that one in particular isn't v469 related since it happened in v436 too. Mostly just to say, I can't triple-check the lever thing right now, but I have double-checked already

[Buggie]

Another point: I noticed that the lever is not movable any more in map MH-Subway+SBFix1 (see pic) when this map runs on server with v469b, tested with client v436 and v469b. Has the interaction between movers and players also changed in 469 versions?

Test on your server. This mover can be pushed with cheat. But nothing happens. I think break something else. And related to your server because test on clear server is fine.

--- EDIT ---

Advice try with causeevent check chain of all events on your test server.

--- EDIT ---

Yep. Tried again. Results next: on your environment lever not pushed. So event not produced. "admin causeevent sub" do job, all fine.
If I start clean dedic v469b - all fine: I can push lever and all goes as must be. So definitely problem in your environment.

--- EDIT ---

scr_1616353916.png

This is side view for train. After see this I more wonder why this work for clean server, neither why this not work for you. This thing must not work because no any way to push this lever with player cylinder.

--- EDIT ---

Mover18 ready for your patcher. I think move for 2uu back is fine. Or maybe better fix map and make new version? Because I doubtful about this issue appear only for you.

--- EDIT ---

Gap is less from 1uu so v469b can be more strictly calculate allowed movement, rather from v451, so previously jitter allow you push this level. But this not explain why for my dedic v469 MH all works.

[Dr.Flay]

I have to point out that "UseHDTextures" is a misnomer and thus misleading.
The function has nothing to do with High Definition, as you could have uncompressed textures of the same resolution.
The only reason for the connection between HD and compressed textures is it makes it them smaller and more feasible to use.
For example you could also have a UTX file full of 16x16 compressed textures which needs the switch enabled, and at no point are you going to call it High Definition.

The original renderers started with the option to use compressed textures, the remade renderers changed the naming, now we rename again.
Why not just go back to the first name which was self explanatory?

[Feralidragon]

I was the one who suggested that name (the setting was already going to be renamed, I just suggested the actual name, which the team them accepted), and I do still stand by it, and I will try to explain why.

First off, the original name of the setting was no longer accurate: S3TC is one form of compression, however 469 supports multiple compression formats nowadays beyond S3TC, which was the main reason why it was renamed to begin with.
So, regardless, the setting needed a new name since it was now misleading and not completely representative of what it actually did.

Secondly, it was NOT self-explanatory at all.
When someone looks at a setting with "S3TC" in it, their mind does not go immediately to "oh, so this will enable those awesome higher resolution textures", not at all, although in practice that's what it really did, and still does.

People were only able to connect the "S3TC" naming with "higher resolution" when it was used together with "high-res" or "HD", including in the guide you put together:
viewtopic.php?f=6&t=12927
as well as the original setting description:

UseS3TC - [True/False]
Enables the use of high resolution S3TC compressed textures if they are installed.

which by your own argument is not accurate either, since, like you said, S3TC compression does not necessarily have to be "high resolution".

Therefore, if the setting had to be renamed anyway to better describe what it did, in a common way that players understood what it did, then it only stands to reason that it should be named after what it's intended to do in a manner that any player understands what it does.
And "UseHDTextures" seems the most accurate name for it, because compressed textures are normally used, pretty much exclusively, for HD textures.

There's really no one using uncompressed HD textures (no one who is sane, at least), nor compressed SD textures either (it would actually just increase file size needlessly, so it would be wasteful), so it seems to me that it's pointless to be pedantic with the naming, especially when all the explanations surrounding this setting (including yours) always refers to the setting as a way of enabling high resolution textures, so might as well give it name that actually represents what it's intended to do in practice in the context of the game.

Also, this setting was already renamed to "UseHDTextures" since the first 469 public release, namely 469a.
Just mentioning this last bit since you seemed to imply that it was renamed again in the latest 469b release (?), which isn't the case.

[chat sniper]

@Dr. Flay & Feralidragon:

I see both of your points, they're both valid perspectives.

I think Ferali is on the right path in trying to give a name that best describes what they actually do... however, I don't think either UseS3TC or Use HD Textures really means anything to the average person.

As someone who first played the game in 1999, I for one don't know what S3TC means or why I'd want to use it. Similarly, I've come across too many games which have come to use terms which in retrospect are antiquated and can actually mean negative things given the capabilities of modern computers - and UT99, being an old game, means I can't trust what the game's files say have anything to do with what are really HD textures.

Why not give the name "allow mod textures"? It's not entirely accurate, but from the sounds of things it might give the user the best idea of what the setting allows them to do.

[OjitroC]

Therefore, if the setting had to be renamed anyway to better describe what it did, in a common way that players understood what it did, then it only stands to reason that it should be named after what it's intended to do in a manner that any player understands what it does.

I agree with everything you say but I would point out that you can't rely solely on the setting name to convey what it does. The updated version of OpenGL has introduced a number of new settings such as UseDrawGouraud469 or UseSamplerObjects; I don't know what those mean, I have no idea what SamplerObjects are for example nor what a Gouraud might be (more importantly I have no idea of the impact of enabling or disabling those settings). Higor has explained these in another thread on this Forum but many people will be unaware of that.

My point is that new settings or settings with altered names need to be clearly explained (in a manner that the average player with no technical knowledge can understand) in documentation accompanying the new or updated renderers (and this appies equally to audio drivers).

[Shrimp]

I've never actually turned `UseS3TC` on or paid it much attention because I've never had a S3 Savage 3D card, and thought it only applied to those so I ignored it

[Barbie]

I also updated my client installation to v469b and now I often cannot rotate if I run maps from UnrealEd. Sometimes I can only rotate horizontal, sometimes vertical and sometimes not at all.

[Buggie]

Wow. Never faced that. Need more clear steps for reproduce if this possible for stable reproduce.

[1337GameDev]

I also updated my client installation to v469b and now I often cannot rotate if I run maps from UnrealEd. Sometimes I can only rotate horizontal, sometimes vertical and sometimes not at all.

I encountered this. I run ut99 in parallels on my mac and had an issue with parallels modifying input for smoothing.

I also had to fiddle with the raw input or direct input settings in ut99. Was odd, but eventually worked.

[Eternity]

I am not sure whether this is normal to have negative Yaw value at the client side, and have never seen this before until yesterday.
Had to fix it to "(ViewRotation.Yaw & 0xFFFF)" to get the correct client side value...

---
Edit:
Normal... No problem then...