◄►469 Patch Discussions◄►

[Buggie]

This is not related how you produce message.
keyboard or mouse, or both of them - sometimes voice not played.
Hardly speak it must be pronounced or not, because I not know exactly rules as this must go.

But yes, sometimes, sound not hear. it can be valid case (for example you make few voice messages in short time) or not.

[OjitroC]

but sometimes when I activate BrasilTauntV1 using both the mouse and the keyboard, only the text comes out and the voice does not come out...

The sounds all play normally when using the voice menu so no error with the Voice Pack. You may not hear certain sounds because other sounds in the game are playing at the same time, like Announcer sounds.

There's a few things with the VP
1 the VP has 16 FF sounds but the property 'numFFires' is set at 15 - this means one FF sound won't be played;
2 the VP has 32 taunt sounds but the property 'numTaunts' is set at 31 - this means that one Taunt sound won't be played;
3 there are 32 Other sounds - all of these play BUT you only need 17 - each number from 0 to 16 means something in-game (so the sound number 0 means 'Base is uncovered', for example) - sounds beyond number 16 will have no meaning to the bots;
4 the VP doesn't have any text in the Abbrev fields - this text is used for what appears for each sound in the Voice Menu - so the text that appears in the Voice Menu is the same as the text that appears in the talk area at the top of the screen (the text for Taunts in the Voice Menu is being read from the TauntString fields for example).

I tested all the sounds in-game - after a 10/12 minute 'game' I got a log of 27MB - this issue with 469b has already been noted - but, if you don't want a very large log, don't use the Voice Menu in-game very often.

[[rev]rato.skt]

OjitroC hi man,

I say that any taunt provocation is random, sometimes only the text comes out ...


that's the reason?

Code: Select all

I tested all the sounds in-game - after a 10/12 minute 'game' I got a log of 27MB - this issue with 469b has already been noted - but, if you don't want a very large log, don't use the Voice Menu in-game very often.

[1337GameDev]

Yes, it was introduced in 469a:

Code: Select all

native(238)	static final function string Locs	( coerce string S); // -- rjp

Although I don't know what it does, and you cannot really use it, as 469 checks if any of the new functions are being used in custom packages, and refuses to save any custom package with them.
At least until a way is implemented to safely include functions like this without breaking previous client versions.

Why? Is this because a method doesn't exist to reliably detect a package expects a new version, and then reliably handle ignoring those calls / denying execution?

Why is this?

I thought 469 was meant to be backwards compatible -- but mods could be "forwards compatible only" and need a newer version to work?

This seems odd to require all NEW mods, to work on older versions... I totally understand having OLD mods / maps working on newer versions, but NEWER ones? That seems very odd to me, and seems like a hinderance.

Was that an agreement with Epic when making the patch?

[OjitroC]

OjitroC hi man,

I say that any taunt provocation is random, sometimes only the text comes out ...

that's the reason?

Code: Select all

I tested all the sounds in-game - after a 10/12 minute 'game' I got a log of 27MB - this issue with 469b has already been noted - but, if you don't want a very large log, don't use the Voice Menu in-game very often.

Hi - Sorry, I don't know what the reason is. It doesn't seem to be related to that Voice Pack, as it seems to work OK for me in-game when there are no other sounds being played. Does the same thing happen if you use another Voice Pack?

[Feralidragon]

Why? Is this because a method doesn't exist to reliably detect a package expects a new version, and then reliably handle ignoring those calls / denying execution?

Why is this?

I thought 469 was meant to be backwards compatible -- but mods could be "forwards compatible only" and need a newer version to work?

This seems odd to require all NEW mods, to work on older versions... I totally understand having OLD mods / maps working on newer versions, but NEWER ones? That seems very odd to me, and seems like a hinderance.

Was that an agreement with Epic when making the patch?

At the moment that method does not exist, no.
The game will simply crash if you use a package with implemented functions which do not actually exist in an older version.

What you're arguing for I also already did before, but Anthrax does not feel very comfortable on that, understandably so when you consider that most of the community won't be able to handle that, meaning that one could do a mod using the new shiny 469 functions, and then many folks would just use it in 436, it would crash, and eventually this could get to the hears of Epic, at which point Anthrax would have to explain the situation, which although could be cleared up at that point, it could still fragilize the relationship and trust with Epic in the end.

Considering the huge amount of effort and how many years it took for Epic to finally grant a few more people to maintain the game and patch it, the last thing you want to do is to do anything that could remotely rub them in the wrong way.
So although it was never explicitly agreed between the parts, it still is a gray area, which can quickly turn to black or white depending on Epic's stance on this, because they still hold all the rights and they can pull the agreement at any given time if they wish to, so the devs have to tread carefully on that regard.

So for the time being the safest thing to do is to simply not allow any custom package to use these new functions, until a proper way of doing it is figured out, if it ever is a path to pursue to begin with.
Because the focus of the patch was never to necessarily bring new versions and features to the game, but mostly to actually fix the problems it has and to make it work in modern systems without problems.
New features are pretty much secondary to that, and have very low priority at the moment.

Having that said, there are a few ways to get around this in the future, but which will require some more discussion.
I may eventually move my own proposal from the private repo to the public official one, just to show a possible way this could be addressed (given that this subject comes every now and then), although I would prefer to keep it under wraps for the time being since it might not ever be pursued due to the work it implies in the compiler itself.

[[rev]rato.skt]

Hello man,

Changing the subject, you could make a change in the next update, so that the UnrealTournament Server Browser is saved when pulled to the side to enlarge your window? and also other better layout options....

Whenever we need to see the information from the servers we have to keep stretching the window every time...

[Buggie]

This thing too complicated for simple save/restore approach.
I suggest next change: https://github.com/OldUnreal/UnrealTour ... issues/307
Possible it fits for your needs.

In short, you can not blindly save/restore splitter position, because resolution can be changed, window size can be changed an d so on. Too many things make influence on this stuff, so hard set specified number of pixel from top or bottom is not a good solution.

[[rev]rato.skt]

Nice man big thx!!

[Acoma]

if you ever get the chance can you add some map list tooltips from ut2004 to the new patch? i mean the ones that allow you to add and remove all maps and maybve even a shuffle maps button to make it easier to setup map lists via ui
attaching pics for references

[Buggie]

Make issue on github with this info.

[sektor2111]

I doubt to see things solved even if are posted at github, things are changed motivating me to forget updating my repositories.
Let's see VISIBLE things and "updates".
This a sort of mesh lamp/object with dynamic lightning intended to do some shining/burning - working with/without my coroner mutator...

A lamp with a corona inside looks pretty much normal.

Let's see the same stuff in 469b

Nice, huh ? It's fixed... Did I say that my work goes into ruins with the newer "patch" ? Yes, I did... I was right...
Proof ? Here you go...

DM-NotThatSmall_440_469.7z

(455.07 KiB) Downloaded 8 times

I'm not responsible for your UT install paths and what "names" are you using there.
Does it worth writing more lightning stuff if it's all useless ? Definitely not.

[OjitroC]

I doubt to see things solved even if are posted at github, things are changed motivating me to forget updating my repositories.
Let's see VISIBLE things and "updates".

You haven't said which renderer you are using there but ... that's a renderer issue - that light doesn't work in 436 with OpenGL as well as not working in 469b with OpenGL - it does work in 469b with D3D9. So not a 469b issue per se.

[sektor2111]

it does work in 469b with D3D9

Actually NO, end of story. It's exactly what I captured and identical as in game... If I recall your over-whited light cone posted elsewhere, definitely here are done changes... I don't understand for which reasons, and no in 436 440 all is visible and does what it has to do... flickering textures.
I don't have plans out of D3D9 so THIS IS what I'm showing.
I glad to find out that for you it works... because for me it's the same "NoCorona" even in OpenGL. No differences.

[OjitroC]

]Actually NO, end of story. It's exactly what I captured and identical as in game... If I recall your over-whited light cone posted elsewhere, definitely here are done changes... I don't understand for which reasons, and no in 436 440 all is visible and does what it has to do... flickering textures.
I don't have plans out of D3D9 so THIS IS what I'm showing.
I glad to find out that for you it works... because for me it's the same "NoCorona" even in OpenGL. No differences.

So it's probably down to the way different machines/OS/video cards handle the UT renderers? Rather than anything inherent in the 469b renderers?

Possibly the over-whited light cone was due to me having to lighten certain screenshots taken with certain renderers in particular UT versions as they don't always turn out the way I see them in-game - again down to my machine/OS/video card, etc probably.

But if you feel it's an issue to do with 469b, then the only way it's going to get solved is by posting an issue at GitHub (as other people on this forum do).