Unreal Tournament 469

[sektor2111]

Like I said, any future implementation will make mods incompatible with prior UT versions. Engine.u file is an important thing - other stuff can be wrapped without damaging anything. A custom mutator can deal with such call IF it has to, we don't need to screw stock structure. And MutatorTakeDamage is for pawns not for decorations...
Once again things can be switched and I don't get why not:

Code: Select all

if ( DamageType == 'shot' )
	DamageType = 'blasted';
...

Perhaps I have to practice some coding stunt for Slith class which I might want to kill with ut_biorifle without to screw immunity property, just turning damage into burned or such... or giving to LavaSlith immunity to damagetype "Burned" because it's LavaSlith not a SlimeSlith... . Of course immunity can be changed without even to call any TakeDamage thing...

[anth]

This is the current list of changes. Keep in mind that the list is in no way final or complete:

Release Notes

We're still working on a lot of things, but we're making good progress.

[PrinceOfFunky]

This is the current list of changes. Keep in mind that the list is in no way final or complete:

Release Notes

We're still working on a lot of things, but we're making good progress.

Dynamic arrays are now fully supported (UT v436 had only partial support for dynamic arrays).

Does it mean we won't need to use the map itself as an array anymore?

Added new Canvas functions to create arbitrarily-sized fonts on the fly. Please do not use these functions directly as they will cause your mod to be incompatible with earlier versions of UT. Instead, use the BotPack.FontInfo class to retrieve fonts that are appropriate for the client's screen size.

Does it mean that if new features are added unrealscript-side they are not compatible by older versions of UT but if they are new native-side features or just native-side fixes of existing features they are compatible?

[sektor2111]

Fixed an issue that caused the server to crash in AActor::execPlayerCanSeeMe in games with bots in them.

Check that well, server is crashing even is empty due to some false NetConnection without a player owner, I don't get what's the Bot problem here since the crash happens even in Player-Only servers - ask Hermskii (as btw)...

Fixed an issue that caused UnrealEd to crash during shutdown. This issue likely only affected Windows 10 users.

That's a default crash for everyone... see log.

Fixed an infinite recursion crash bug triggered when picking up an invisibility powerup while already invisible.

You might want to check UT_ShieldBelt vs UT_Stealth - that's a crusher because shield take in account invisibility based on class-name not ut_stealth both of them trying some overlay or such...

Added the -FORCELOGFLUSH command line option. This option makes the game/server flush the log file every time it is written to.

I gotta see this...

Unreal Tournament version 468 Release Notes...
...

Can I see that 468 or it's just a myth ?

[FXANBSS]

hello there

Will the bug where Bots don't attack ScriptedPawns be fixed?!
This will make my whole life! subclasses won't be ever needed, like MonsterSpawn does, I use it a lot, and SwarmSpawner too

[ShaiHulud]

This is the current list of changes. Keep in mind that the list is in no way final or complete:

This is enormously valuable. Very appreciative for your work on this project.

EDIT: Wow! I just finished reading through the document, this is a truly Herculean effort, astonishing and exciting.

[Chamberly]

This is the current list of changes. Keep in mind that the list is in no way final or complete:

This is enormously valuable. Very appreciative for your work on this project.

EDIT: Wow! I just finished reading through the document, this is a truly Herculean effort, astonishing and exciting.

Well there is much more to work on, it'll be updated in some times.

[sektor2111]

Will the bug where Bots don't attack ScriptedPawns be fixed?!

Bots are attacking ScriptedPawn depending on game-type declarations - use proper game-type...
If we talk about ScriptedPawn attacking Bot - THAT needs fixed... or using a better UnrealShare file, lol.

[EvilGrins]

Will the bug where Bots don't attack ScriptedPawns be fixed?!

Bots are attacking ScriptedPawn depending on game-type declarations - use proper game-type...
If we talk about ScriptedPawn attacking Bot - THAT needs fixed... or using a better UnrealShare file, lol.

I'm familiar with that issue, think I made a post about it in 2011 when I first joined this forum.

Bots on the red team, for whatever reason, don't seem to acknowledge monsters in team games. Outside of team games this isn't a problem, but in them only the blue team's bots even notice the monsters are there.

Red team bots get slaughtered because they don't acknowledge they're being attacked... except from monsters that can pick up UT-weapons, anyway.

[sektor2111]

Red team bots get slaughtered because they don't acknowledge they're being attacked... except from monsters that can pick up UT-weapons, anyway.

Like I explained already, if MONSTER would be SEEN as a bIsPlayer Pawn, MonsterHunt would never existed, monsters slaughtering each-other in a few seconds immediately after their AUTO STATE... this can be already seen in maps where are different classes in area and they were "started" in a way. I think you have already seen some Skaarj species committing suicide, in case that we do need to refresh our memory.

[esnesi]

When choosing a skin that is on the ''none'' team gets assigned to a team when entering a server with team based gametype, like it should.
After leaving the server, the skin remains on the assigned teamcolor.

It would be nice to see the skin get assigned back to the ''none'' team.
But not sure if that is as-designed.

[Chronelium]

The fact that nobody has mentioned this yet makes me think that it might only be an issue on my end, but regardless: how about fixing the random dodge bug? Before you say it, no, it doesn't have anything to do with the DodgeClickTime parameter; setting it to a value so low that you can't dodge normally still does not fix the bug. Reproducing it is easy: go into a match and press and hold two opposing strafe keys, such as W and S, or A and D. If you hold them for a few seconds, you'll notice your character will sometimes dodge in a random direction. Now, you might say, why is this a problem, seeing as you never really need to hold the opposite directional keys in-game? The thing is that when you rapidly strafe left-right-left-right in order to avoid enemy fire, there is usually a small period of time when you are holding them both concurrently, and that can result in an accidental dodge happening. This is obviously undesirable.

I have tried binding my mouse buttons to Strafe Left and Strafe Right and it still happens, so I don't think it's merely keyboard chatter. If I'm not mistaken, NewNet actually used to have a workaround for this by setting a minimum dodge click time, meaning if two key presses are registered in a very short window of time, they do not trigger a dodge. However, this variable either doesn't work anymore or is not included in Ultimate NewNet as I still get this bug on servers running that version. Either way, it would be nice to have this fixed in regular servers too. That is, assuming, of course, that it's not just my particular installation causing issues somehow.

[Chamberly]

Actually I do remember this but forgotten about it. Thanks for posting that, will look into it.

Edit as of 12/5/2019: I just tried to test it and it didn't work anymore.

[Chronelium]

Actually I do remember this but forgotten about it. Thanks for posting that, will look into it.

Thanks for looking into it. It also seems like it might be affected by FPS since it happens slightly less often if I cap my game to 30FPS.

Edit: Remembered another issue worth looking into. The Sniper Rifle sometimes zooms in all the way even if you only want to zoom in a little. It happens if you shoot the primary fire while the rifle is in the middle of zooming in. So, to reproduce the bug, you just need to right click and then left click in quick succession, or hold the right mouse button and left click while it's zooming. Shooting, then holding the secondary fire until the rifle begins zooming in, and then letting go of secondary fire also causes it to zoom to the highest magnification level. These don't seem like the intended behaviour.

[Berserker]

Actually I do remember this but forgotten about it. Thanks for posting that, will look into it.

Thanks for looking into it. It also seems like it might be affected by FPS since it happens slightly less often if I cap my game to 30FPS.

Edit: Remembered another issue worth looking into. The Sniper Rifle sometimes zooms in all the way even if you only want to zoom in a little. It happens if you shoot the primary fire while the rifle is in the middle of zooming in. So, to reproduce the bug, you just need to right click and then left click in quick succession, or hold the right mouse button and left click while it's zooming. Shooting, then holding the secondary fire until the rifle begins zooming in, and then letting go of secondary fire also causes it to zoom to the highest magnification level. These don't seem like the intended behaviour.

Oh yes, that happens with other weapons as well at random, definitely an annoying bug that happens once in a while. Here is a clip I did 2 months ago, showcasing the exact same bug with different weapons.



In this clip, I was charging my Hammer and at the same time I decided to switch to Sniper and then I immediately switched to Minigun. As I did that, the zoom bug happened and I zoomed all the way with Minigun out, getting myself killed because of it.