◄►469 Patch Discussions◄►

[Carbon]

Well, I can't say I've done 'extensive' testing yet, but so far, all is well.

I dropped the patch into my 20 year-old install (I've been migrating the same installation folder across many, many PC builds over the years), replaced the files it wanted to, fired it up and yeah...all went well.

Hardware-wise, I'm on a 10700k and 2070 Super, so pretty modern and with the new feature to limit frames, it ran smooth as silk.

Good stuff anth and the team...thank you for your work.

[sektor2111]

Confirming this way what I told before: ONLY for new hardware - an old game requiring a new machine - lol deal.

[Neon_Knight]

It's easy to be the one in the right by doing nothing to help improve the situation other than complaining.

[sektor2111]

AND it would be better from developers to post that crusher "History:Music" function around, perhaps other 3 - 4 people will figure what sort of sanity check would be needed...
The rest are not needed discussions... if the thing is not such a big secret.
If I'm not having too much knowledge about those C++ things, perhaps anyone else can drop an advice, that would be probably more helpful than anything like a "help".

[Carbon]

Confirming this way what I told before: ONLY for new hardware - an old game requiring a new machine - lol deal.

My post doesn't confirm anything....that's my computer and it runs it. A single sample proves nothing. The game also runs fine on my 2013 4770k (tested with both the onboard graphics and with a GTX 1070) and on a Q9550 from 2008.

While I realize that not everyone has access to the latest hardware, complaining about a game from 1999 being unplayable due to hardware limitations is a bit comedic at this point.

[sektor2111]

Yeah, an old game running in some random machine and after update won't do anything than crushing, that's the bigger comedy in stage, improvements improving nothing in such case - which it's not only one isolated case...
https://hofgamingclan.com/forums/viewto ... =507#p3425
Hardware on this Planet Earth it's not just one type, lol.
Simulating miss-understanding is useless, you know well what I mean here. - I mean new hardware and not latest hardware which is a problem too, exactly as... in Android case:
- Android 6 - OMG are you still using it ? It's too old... lol.
- Android 11 - Ooops, we do not have enough info and tests for that - it's too new... lol × 2.

Similar story:
- Old hardware has problems with 469 - Who uses that ? Users/Players/Mappers/Coders, what's the problem ?
- Latest hardware has problems with 469 ? Are you having such things ? Yes, and ?

And about providing feed-back story I think I was already saying "History:UpdateMusic". Debugging recommendations ? Let me see...
Who is calling that function ? What sanity check is needed here for preventing this call ? What if object Music is nowhere in Memory ? What if we Unload driver until things are ready to rock again or causing null samples during this time ? ETC. ETC. Driver having a latent state until something is calling it back to stage - like porn-stars, take a break and then get back again when stage 2 it's ready... Because... the rest of drivers are not even starting here...

I'm not sure if everyone is supposed to clap hands louder for this patch, not yet, guys, not yet... and Carbon... you forgot to explain how goes with mapping/compiling in UT469... Some words about that new Editing combo stuff and new features, outside of these hardware poems ?

[RocketJedi]

Yeah, an old game running in some random machine and after update won't do anything than crushing, that's the bigger comedy in stage, improvements improving nothing in such case - which it's not only one isolated case...
https://hofgamingclan.com/forums/viewto ... =507#p3425
Hardware on this Planet Earth it's not just one type, lol.
Simulating miss-understanding is useless, you know well what I mean here. - I mean new hardware and not latest hardware which is a problem too, exactly as... in Android case:
- Android 6 - OMG are you still using it ? It's too old... lol.
- Android 11 - Ooops, we do not have enough info and tests for that - it's too new... lol × 2.

Similar story:
- Old hardware has problems with 469 - Who uses that ? Users/Players/Mappers/Coders, what's the problem ?
- Latest hardware has problems with 469 ? Are you having such things ? Yes, and ?

And about providing feed-back story I think I was already saying "History:UpdateMusic". Debugging recommendations ? Let me see...
Who is calling that function ? What sanity check is needed here for preventing this call ? What if object Music is nowhere in Memory ? What if we Unload driver until things are ready to rock again or causing null samples during this time ? ETC. ETC. Driver having a latent state until something is calling it back to stage - like porn-stars, take a break and then get back again when stage 2 it's ready... Because... the rest of drivers are not even starting here...

I'm not sure if everyone is supposed to clap hands louder for this patch, not yet, guys, not yet... and Carbon... you forgot to explain how goes with mapping/compiling in UT469... Some words about that new Editing combo stuff and new features, outside of these hardware poems ?

Agreed. Maybe system requirements might help? A lot of people don't read instructions as well. For instance make a backup/copy of your UT folder and install the patch to the new copied folder. I bet half the regular non technical players didn't do this. Then you need to experiment with renders. Then ask yourself do you have an AMD card or Nvidia? If NVidia try OpenGL or XopenGL. AMD card? Then try D3d 9, 10. Prior to playing open the console and type preferences. Then go to render options and reset to default. The Person on that Hof thread didn't mention any specifics of what they did and why it happened. saying it didn't work for me doesn't help anyone. Would be nice to know her full system specs..video.. etc. Just my 2cents

[Virgile]

Maybe I was too confident, but this sh*ty patch broke my UT setup. Wonderful.
No more Oldskool : when activated no menu, just the wallpaper without any menu so must be turnoff with unrealtournament.ini to made the game playable again (without oldskool)...
No more executable mods : SpatialFear.exe,AirFightUT.exe,etc -> "The procedure entry point ?CallDefaultProc@WWindow@@UAEHIIJ@Z could not be located in the dynamic link library [...]"
Everything is ruined, I'm furious.

[OjitroC]

No more executable mods : SpatialFear.exe,

Yeah, I can't run SpatialFear either, plus another executable mod, TeamOrbit.exe, no longer runs.

[Feralidragon]

Executable or native mods may indeed be broken by this patch, and there's really no way around that since in order to do some of the fixes and improvements, the native side had to suffer deeper changes.
Asking a patch to fix all issues and improve performance, while at the same time expecting executable and native mods from 10-15 years ago to keep working is unreasonable.

So yeah, if you want to keep playing with those kinds of mods, you have to keep yourself with the 436 version.
This is why even things like XC and ACE needed to be updated (older versions of XC and ACE do not work with 469).

Some UScript mods may also become broken, although this should be a more rare occurrence, and although most of the time these happen to be bugs in the new patch and thus should be reported, there are some cases where the problem is actually with the mod itself, in cases where the mod only works due to an actual bug or problem with the engine which was fixed with the new patch.

So before considering shitting on the devs, perhaps consider reporting these issues so they can be fixed instead.
It's very hard to make a patch that works for everyone and with everything already released with just a couple of people as developers, and only a few more actively testing it during closed beta.
The real beta testing started with this first public release.

[Virgile]

In fact I just found a solution for spatial fear mods: make a copy of the new UT exe and rename it to SpatialFear.exe
On the other hand, the fact that Oldskool is incompatible is unacceptable, many people use it ...

[OjitroC]

Asking a patch to fix all issues and improve performance, while at the same time expecting executable and native mods from 10-15 years ago to keep working is unreasonable.

Yes, sure - that's fair enough, agree with all of that. I have no desire to be critical of the developers, appreciating the difficulty of satisfying everyone. I added TeamOrbit more for information so that, perhaps, a list of mods that won't work with 469 can be added to the release notes or readme, just so that people are aware.

I have adopted your suggestion of running certain mods, etc in 436/451 and playing UT itself in 469 (basically by having two copies of my System folder).

[Feralidragon]

Well, mods that have their own executable generally do not really have their "own" executable per say: what they generally did was to copy the UT.exe executable, rename it and tweak it slightly to launch the game in a slightly different way.
Any of these types of mods will of course not work at all, because with a new patch the game executable will always be different.

For these cases, those interested may check alternate ways to make them work across versions, like maybe having a shortcut or a different exe that executes UT.exe with different parameters, and then let the dev team know so they can add these to the patch notes.

On the other hand, the fact that Oldskool is incompatible is unacceptable, many people use it ...

I was going to suggest for you to report the issue you found, but then I found this:
https://github.com/OldUnreal/UnrealTour ... /issues/95
... and this is no way to report an issue, it's not even the proper way to speak with another human being.

You're wrongly assuming that the devs broke OldSkool on purpose or for fun for some reason, and also wrongly assuming that "many people use it", when that's something you cannot really state as a fact, especially when you're the first one having issues with it apparently, and voicing them over, meaning that everyone else doesn't have it installed, or it works for them which could suggest a more isolated problem with your own install or configuration.

So, please, take a step back, calm down, and try to articulate what exactly the problem is, without assuming that the devs acted in bad faith.

Like I said above, we're talking about pretty much 2 devs actively working on this completely alone most of the time, on their free time, for free, and with a RL of their own, so if you want a good patch, please contribute back by providing good reports without any assumption of malicious intent, because there wasn't any.
If you don't want to do this, then keep using the previous version you were using.

[Diego_HoF]

I will be honest, i want to see this version to evolve and improve, so i going to keep it and hope all bugs got fixed pretty soon, in someway, when gets more stable, some maps will need to be redone for improvement, that's how i see mine atleast.

I was going to suggest for you to report the issue you found, but then I found this:
https://github.com/OldUnreal/UnrealTour ... /issues/95
... and this is no way to report an issue, it's not even the proper way to speak with another human being.

Damn people, i use oldschool and it's working nice with my custom music too
Lucky i guess

[sektor2111]

Yeah... again: go to GitHub...
And again: Me one, NO, I won't go anywhere for one thing, as Leo specified already and Perhaps at GitHub are not needed other 3000 accounts only for ONE thing, UT99.ORG is an UT community not GitHub.

And UT469 - Editing task - sometimes is crashing when ViewPort is switched at Top View from another "RT view" (where ambientsounds are audible) while I was trying to use some actor replacement with TrashLord (aka MapGarbage) which never crashed any UT-UGold Editor, but here was something about audio breaking or something like that. I'm not bother to recreate scenario and losing lasts map changes, I just switched Editor back to 440 + XC stuff and all was fine...

Of course, no one wants to add damaging things to newer patch - some features are extremely useful in Editor - RESPECT for them, but they do that out of will due to compilers and dependencies used for compiling + environment.

Some of these 469 audio drivers won't load - in "preferences" menu they trigger the same messages about un-existent procedures/functions which old UT never needed them. At a moment it comes to testing music - Editing Environment, after pressing stop button, music it's still running at slow volume in background - driver does not seems to stop when it should be STOPPED. It keep running music and... issue is coming up at Map-Switch when Level's Music is removed - Run-Time environment.

Code: Select all

Critical: UpdateMusic
Critical: UGalaxyAudioSubsystem::Update
Critical: UGameEngine::Draw
Critical: UWindowsViewport::Repaint
Critical: UWindowsClient::Tick
Critical: ClientTick
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop

Editor-Log Window has already parameters saved in Main INI it doesn't need a duplicate configuration in UnrealEd.ini, it needs READING STUPID CRAP from there instead of making another file access.

bTwoWay is a parameter involved in CTF matches for AlternatePath and FLAG Carrier

for ( N=Level.NavigationPointList; N!=None; N=N.nextNavigationPoint )
if ( N.IsA('AlternatePath') && (AlternatePath(N).bTwoWay || (AlternatePath(N).team == Holder.PlayerReplicationInfo.team)) )
{
if ( AlternatePath(N).bTwoWay && (AlternatePath(N).team != Holder.PlayerReplicationInfo.team) )
TotalWeight += 4000;
TotalWeight += AlternatePath(N).SelectionWeight;
}
selection = TotalWeight * FRand();

NOBODY can see it directly without ADVANCED ACTOR EDITING (Why Not ??) - it should be accessible normally - you should allow FULL OPTION at CTF mapping in XXI century, and... remove that dumb thing LevelInfo -> TimeDilation from plain Editing option - that's not for mapping or mappers, it just ruins old net games set in classic game setup.