Developers Iteration I of 2023

[Jip]

The behavior you describe is what happens when you apply terrain deformations, regardless of how you apply it. We just reduced the amount it deforms the terrain. As an example:

Terrain deformations on FAF Develop

Terrain deformations on FAF

Note how on the second image there are several power generators floating, where as on the first image there are none. The old method was a lot more prone to cause structures to float, depending on the order you build them.

[Jip]

@thomashiatt said in Developers Iteration I of 2023:

It will require a lot of testing to make sure all the buildings can still be shot properly, especially under construction aeon buildings. There's been problems in the past with certain buildings, and now this adds more degrees of freedom that probably were not taken into consideration before.

This problem has been fixed a while back, see also this pull request and in particular the pull request it links to. The changes proposed here do not impact aeon structures any different than other structures. As an example: the aim bones and the collision box moves with the structure as it is being tilted.

@cheeseberry said in Developers Iteration I of 2023:

There is also the nice "feature" that indirect fire units, e.g. t1 arties, on sloped ground sometimes refuse to shoot enemy units inside their range circles because of some arcane turret rotating reasons.
When this happens is super unpredictable for a human, probably making heavily sloped maps anything but fun

This problem has nothing to do with the slope, it has to do with the weapon of the artillery being set to lead the target. This can cause the artillery to prevent firing because the target solution is outside of the attack radius of the artillery. The slope can amplify this slightly - but the problem itself is not related to the slope. For example, this is also noticeable with Zthuee (on a flat water surface) and moving frigates: because frigates move too fast the Zthuee just look. They usually never shoot at moving frigates, especially if they are moving themselves too.

The solution is to prevent tech 1 artillery to try and lead the target. The up side is that it would always fire. The downside is that it would be as useless to moving targets as tactical missiles are. But I'd argue they'd still be a lot better because t1 artillery has a lot more splash damage.

If it were up to me I'd prefer units that always shoot over units that don't. But this particular change is very balance related, and the balance team doesn't like the solution.

[CheeseBerry]

@jip said in Developers Iteration I of 2023:

@thomashiatt said in Developers Iteration I of 2023:

It will require a lot of testing to make sure all the buildings can still be shot properly, especially under construction aeon buildings. There's been problems in the past with certain buildings, and now this adds more degrees of freedom that probably were not taken into consideration before.

This problem has been fixed a while back, see also this pull request and in particular the pull request it links to. The changes proposed here do not impact aeon structures any different than other structures. As an example: the aim bones and the collision box moves with the structure as it is being tilted.

@cheeseberry said in Developers Iteration I of 2023:

There is also the nice "feature" that indirect fire units, e.g. t1 arties, on sloped ground sometimes refuse to shoot enemy units inside their range circles because of some arcane turret rotating reasons.
When this happens is super unpredictable for a human, probably making heavily sloped maps anything but fun

This problem has nothing to do with the slope, it has to do with the weapon of the artillery being set to lead the target. This can cause the artillery to prevent firing because the target solution is outside of the attack radius of the artillery. The slope can amplify this slightly - but the problem itself is not related to the slope. For example, this is also noticeable with Zthuee (on a flat water surface) and moving frigates: because frigates move too fast the Zthuee just look. They usually never shoot at moving frigates, especially if they are moving themselves too.

This can also happen when both the arty and the target are standing still which, I would assume(?), means no target-leading attempts are being made.

See e.g. here: https://forum.faforever.com/topic/2282/fervors-zthuees-and-pds-can-t-shoot-down-hills-lobos-and-medusas-can?_=1674060312416

[GoodRaptor]

This post is deleted!

[GoodRaptor]

@jip I've kinda realized that I was overthinking things again and that no one even plays zoomed in typically anyways

When it comes to RTS, gameplay always comes first and after reading some of these posts I've realized how stupid my argument was xD

Honestly after trying out the beta, I think it would be highly effective and stylish compared to the floaty PD and bad pathing we get at times with enough work

[Jip]

@cheeseberry said in Developers Iteration I of 2023:

This can also happen when both the arty and the target are standing still which, I would assume(?), means no target-leading attempts are being made.

See e.g. here: https://forum.faforever.com/topic/2282/fervors-zthuees-and-pds-can-t-shoot-down-hills-lobos-and-medusas-can?_=1674060312416

That is a valid example, see also the angle of the turret:

In order to fire it needs to have a 90+ degree pitch, which they can't physically have. If you increase the firing tolerance to an absurd number (3 -> 100) then they can fire, but fire all over the place:

But that is not a solution.

[Sprouto]

I would imagine that any tilt to a TML will impact the flight time mechanics of the missile to some degree, if nothing else, at least in some of the AI code for predicting lead-time.

[Jip]

With thanks to @phong we managed to play the first representative game on the FAF Develop branch. See also the first post. You can find the replay 19044295 in the vault.

Performance

It clearly shows the performance improvements, where we now have a new record of 1500 units + a battle being processed in 17ms, and 3000 units + a battle being processed in 40 ms.

For those unaware: the game is processed in ticks. Each tick has a 'budget' of 100ms. If we can't meet that budget, the game starts slowing down.

To put that into numbers: my computer has a Ryzen 5 3600. You can buy one of those brand new for 100 to 160 euro CPU. This relatively cheap CPU is now able to process games up to 6K units without any problems, which is where it would start slowing down the game on the current release branch.

1500 units at 17ms / tick

2900 units at 38ms / tick

Terrain deformations

There are no visible terrain deformations, even at places where there used to be factories. I'll post a few screenshots.

Air base at a slight slope

Various units at a slight slope

There used to be a full base here, but there's no trace of it when you look at the terrain

Destroyed air base at a slope, but the terrain is not deformed

Full array of SAMs with no terrain deformations whatsoever

Entire base with air grid build on a slight slope, no issues with terrain

But moreover:

• During play, nobody noticed that structures were slightly tilted
• During play, even I did not notice structures were slightly tilted

And looking at the terrain: there are basically no noticeable deformations even though entire bases got destroyed and rebuild. I'd say this is a grand success. And with a bit more tweaking for individual edge cases (like a radar) we can make it even better.

[Jip]

I've added the third section about improved controls and commands, see also the second post starting at 'Control ...'.

[magge]

Unfortunately, the game desyncs at ~14m, tried it several times. But looks super promising so far.

[Jip]

@magge said in Developers Iteration I of 2023:

Unfortunately, the game desyncs at ~14m, tried it several times. But looks super promising so far.

Can you be more specific, along with replay IDs?

You are probably referring to the replay: that is correct. Replays in FAF Develop can desync as soon as new changes are pushed towards the branch.

[Saver]

I love this function

[Jip]

For this patch we've made significant memory reductions, which in turn reduce the stress on the garbage collector and reduces the memory footprint in general. I'll write a post with more details about it later this week. But for now - we need more test data! In particular surrounding the intel and veterancy system, as they both have been re-implemented from the ground up.

You can choose the FAF Develop game type when you host a game:

A lot of people have been hosting on FAF Develop and I've been looking at every representable replay to read your messages on possible bugs, checking the logs and gathering performance statistics.

[Jip]

A few people played games on FAF Develop, you can find the replays here:

• https://replay.faforever.com/19244340 [stable]
• https://replay.faforever.com/19242923 [stable]
• https://replay.faforever.com/19242614 [stable]
• https://replay.faforever.com/19244597 [stable]

With thanks to the hosts for choosing the faf develop game type. The game is stable, as it has been the past few weeks. For those wondering how they can contribute: host your next game on the FAF Develop gametype instead of FAF.

[Saver]

small question about the monkey lord, is this in the developer also undetectable for a granny or was it the patch? If so, I have overlooked the point or not found it.

[Saver]

granny - radar ^^

[Jip]

@Saver could you elaborate?

[Saver]

I only noticed in one game. Short version: I already have an Omi-sensor, but the Monkylord was only revealed during scouting and used again from sight as soon as the scout's vision ended. This even though the Monkylord was in the Omni function range.

[Saver]

Here's an example. Picture 1- I own an Omni and my opponent has a Monkylord + energy.
Image 2: I let a scout appear over the monky lord.

[Jip]

@Saver do you have a replay id for me?

Found out: i'll tackle it