◄►469 Patch Discussions◄►

[sektor2111]

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).

As long as all my 436/440 versions are working properly I don't have issues for posting at HitGub GibHut GitHub... it's only my note around patch.

[[rev]rato.skt]

Hi,

in relation to the old bug, shooting does not come out where your aim is, can you fix it?

the correct thing would be for the shot to come out exactly where it was aimed...

OBS: i posted thanks!!!

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

[papercoffee]

Hi,

in relation to the old bug, shooting does not come out where your aim is, can you fix it?

the correct thing would be for the shot to come out exactly where it was aimed...

Please post any bugs here https://github.com/OldUnreal/UnrealTour ... hes/issues

[sektor2111]

After crawling through settings and time passed, I finally got corona... through walls too...

Another position...

But after restarting match it was once again invisible going slowly more visible - but through walls too... OpenGL in stage...
That's all... I'm not going to waste too much time with these... Such sort of light is in map MH-BattlingLottery, I'm not going to answer at any rendering issues if player is "updated".
Edit: D3D9 does the same delayed always visible corona until I'm changing brightness, moment when it's getting vanished and then slowly coming back Always visible.

[OjitroC]

A further test, this time in 451 - with OpenGL, the corona doesn't work - with D3D9 the corona works. In none of my tests (436, 451, 469b) have I seen it through the walls.

[TankBeef]

Ok, I have a question. I am getting this line on the log, sometimes just once, sometimes flood: OpenGL Error: GL_INVALID_ENUM (please report this bug).
The thing is, my OpenGL works great, you may have seen some of my screenshots, or maybe not, I am still the new guy around here. On 469b, btw. So, should I really "report this bug" like it says? Does it affect the game in any way?

[OjitroC]

Ok, I have a question. I am getting this line on the log, sometimes just once, sometimes flood: OpenGL Error: GL_INVALID_ENUM (please report this bug).
The thing is, my OpenGL works great, you may have seen some of my screenshots, or maybe not, I am still the new guy around here. On 469b, btw. So, should I really "report this bug" like it says? Does it affect the game in any way?

It's difficult to know if it affects the game or the way you see the game since, if it is not doing something it should, you won't know. So it's probably a good idea to report that bug so that people will know whether it is important or not.

[TankBeef]

Ok, thanks OjitroC, I will then. Btw, I am also seeing the light cones you mentioned on many maps, on both OpenGL and D3D9, and both 469b and 436. And they do feel out of place, this is so odd. I would switch them off if there was a renderer setting like the coronas one.
Oh, and what about the Orion's Curse Part 1 bot loop bug crash? How is that going? I have played so many different maps since then, including plenty of FNB's, and no freezing so far. Only on that particular one. So what is happening there? What was done different? There is the animation sequence once you complete the objectives, but I don't see how that is related.

[OjitroC]

Ok, thanks OjitroC, I will then. Btw, I am also seeing the light cones you mentioned on many maps, on both OpenGL and D3D9, and both 469b and 436. And they do feel out of place, this is so odd. I would switch them off if there was a renderer setting like the coronas one.

Yes, it is odd - I don't know if there is a particular renderer setting which might control that - I haven't experimented as I am reluctant to mess too much with the settings since, in general, they are all working OK for me and altering settings coud give rise to other problems.

Oh, and what about the Orion's Curse Part 1 bot loop bug crash? How is that going? I have played so many different maps since then, including plenty of FNB's, and no freezing so far. Only on that particular one. So what is happening there? What was done different? There is the animation sequence once you complete the objectives, but I don't see how that is related.

Looks like there is a difference in the way 469b searches the navigation network since the bug doesn't happen in 436. The report is marked 'bug' so will have to see if the devs can identify the precise cause and come up with a fix for it.

[Gustavo6046]

I haven't experimented as I am reluctant to mess too much with the settings since, in general, they are all working OK for me and altering settings coud give rise to other problems.

Just make a backup copy of your ini file! >_>

Btw, I am also seeing the light cones you mentioned on many maps, on both OpenGL and D3D9, and both 469b and 436. And they do feel out of place, this is so odd. I would switch them off if there was a renderer setting like the coronas one.

Nono, they're part of the game, there are light cone decoration actors, that's why they're there. It's intentional.

I don't know what you mean "out of place".

[TankBeef]

Nono, they're part of the game, there are light cone decoration actors, that's why they're there. It's intentional.

I don't know what you mean "out of place".

Really? Ok then, I will leave that alone. What I mean is that to me it looks too "solid" to be light. Sort of like cardboard coming out of the bulb, maybe? I guess it is because of the limitations of the engine.

[OjitroC]

Just make a backup copy of your ini file! >_>

Yes, indeed - it was more the time and effort that I was thinking about.

Nono, they're part of the game, there are light cone decoration actors, that's why they're there. It's intentional.

I don't know what you mean "out of place".

I can only echo what TankBeef says - to me they look distinctly odd, too solid/thick and they don't go right to the ground. Still I can live with them or I can use the renderer which just shows the light and not the cone (can't remember which renderer that is now).

[sektor2111]

Oh, and what about the Orion's Curse Part 1 bot loop bug crash? How is that going?

Wooow, I could not resist to check what is about (Usually I don't play Assault...).
Ahem... maybe... this new DevPath shows the reality... even stock Assault maps are doing funky things here...

Code: Select all

DevPath: 1000 navigation nodes searched from PathNode617!
Log: Breadth path list overflow from PathNode610
DevPath: 1000 navigation nodes searched from PathNode617!
Log: Breadth path list overflow from PathNode618
Log: Breadth path list overflow from PathNode260
Log: Breadth path list overflow from DefensePoint23
Log: Breadth path list overflow from PathNode257
XC_Engine: === Last line repeats 2 times.
Log: Breadth path list overflow from InventorySpot874
DevPath: 1000 navigation nodes searched from PathNode256!
ScriptWarning: FNBASTeamTrigger AS-FoT-OrionsCursePart1.FNBASTeamTrigger30 (Function AS-FoT-OrionsCursePart1.FNBASTeamTrigger.IsRelevant:00D9) Accessed None 'PlayerReplicationInfo'
XC_Engine: === Last line repeats 5 times.

We have 1000 nodes grinding teeth and "Brad Pit" with his overflowed list... I would not count on this network... Ah, no, these are Original Bots not my Bots, as a matter of fact...
Then...

DuhOrionCough.PNG (3.05 KiB) Viewed 326 times

And total number...

Code: Select all

MaxNumFound: I found a sum of 11413 reachspecs defined in map, from 0 to 11412.

Surprised ? Did I say UE1 = 3000 Specs ? No ? My bad then...
It's a miracle that 436 can stay alive here - perhaps it caps somewhere...

For me it's surprising to see the same errors as in above versions: 1000 and 500. A strong machine now days can go for 2000 3000, there should be some settings allowing DevPath to go into next Level - user defined performance. Ah, no, this is server problem, it won't affect 436 client guaranteed - replication is not needed here, it's A.I. after all... Eh... maybe someone else can write an extension capable to replace these with next level ones...

[OjitroC]

It's a miracle that 436 can stay alive here - perhaps it caps somewhere...

It is indeed - stay alive it does - the point though is that 469b doesn't - playng that map in 469b soon results in a crash/freeze.

There is something rather odd about the map in the sense that my bots completed the assault in a little over 3 minutes which seems rather quick given the 30 minutes allowed?

[sektor2111]

I did not study spam-log in 436, but... definitely when DevPath shows a message Pawn goes nowhere until devs are resuming something internally - perhaps that ClearPath called somehow is helping. That custom trigger... it's a game with non-players too after all .
All I have to say paths-net here is badly messed up - map has design and it's a waste. But I'm not sad, Assault it's not my game, if I well recall I deleted all stock Assault maps from my private playground. If some day I'll turn this into a DM all Navigation will be reconstructed in a limited range.
MapGarbage it's the story teller

Code: Select all

Jerks: Node swJumpPad5 generates a very small path.
Jerks: Node LiftExit10 generates a very small path.
DistancesListing: ====== Paths lenght report reachSpecs based ======
RangeInterval:  	- Length 50-200 UU    = 577 Paths;
RangeInterval:  	- Length 200-400 UU   = 1593 Paths;
RangeInterval:  	- Length 400-600 UU   = 776 Paths;
RangeInterval:  	- Length 600-800 UU   = 387 Paths;
RangeInterval:  	- Length 800-1000 UU  = 245 Paths;
RangeInterval:  	- Length 1000-1250 UU = 0 Paths;
RangeInterval:  	- Length 1250-1500 UU = 0 Paths;
RangeInterval:  	- Length 1500-1750 UU = 0 Paths;
RangeInterval:  	- Length 1750-2000 UU = 0 Paths;
RangeInterval:  	- Length > 2000 UU    = 0 Paths.
ScriptedDeduction: Interval 600-800 UU having 387 paths might be desired Scan Range.
ScriptedDeduction: Missing paths can be covered with intermediate Nodes.
OftenSeen: From 3578 paths checked, the most of paths were in range 200-400 UU with 1593 paths.
Desc: Current stats data won't be accurate at all in maps with custom paths having various user made reachSpecs or
Desc: using a wide range of paths lengths. Decreasing Range in certain cases will gain lost links.
DescJunks: Short paths under 50 UU aren't very useful. 2 paths might need to be moved or excepted.
DescJunks: The presence of many such paths shows overcrowded spots which might need to be optimized because this
DescJunks: is producing useless junk data.
Skipping: 464 paths were skipped being LiftCenters always having 500 UU and InventorySpots which usually are having
Skipping: really small paths and results are not very relevant from them for establishing Scan Range.

I would go for 600-700 UU losing this way a lot of processing and looking well which inventories can be excepted from being linked.
Either way removing nodes very closer having same reachable options and covering map mainly with 1200 UU paths. Extra paths can be wiped manually with PathsLinker if map supports a trip through 227 without to ruin textures...