Posts made by Jip

I don't know how difficult it is to solve this, but maybe @MarcSpector can give us insight on that.

That would be possible - yes. But it feels like an interaction that doesn't fit this game. Toggling things on individual units is an apm / attention sink.

@e33144211332424 said in Jamming ability should reset when vision of unit is lost:

though again having 100's of frigates do it every 5-10s sounds like a small tactical attack aimed at performance.

It is not.

The complexity (with respect to the input) is linear. We denote that as O(n) . Linear algorithms are usually a good candidate when you're on a budget (and we are).

Some of the performance improvements that we've been having is because there were operations implemented using a complexity O(nlg(n)) or O(n^2) while there was an O(n) or even an O(1) implementation possible. To give you an idea of the growth, see these graphs:

See also on desmos

To pick one x coordinate on the graph: if we have 100 (n = 100) units then it takes the algorithm:

• O(n) = 100 steps
• O(nlg(n)) = ~664 steps
• O(n^2) = 10.000 steps

This is by all means a simplification - there's still a constant factor that can make things expensive. But jamming is not one of those.

I think this topic has served its purpose. Considering that both the balance lead and the game lead has objections I see no reason to keep it going. Can a moderator lock this topic?

For those that came in after, here's a tldr:

If manual reclaim matters, then it is only in the first few minutes of the game. At that point there is nothing better to do with your apm / attention. At any other point during the game you need to use your apm / attention to make decisions on the battlefield. As the higher rated players show, the current features that are available (patrol / attack move / attack move from factory) are reliable and sufficient to automate the task. There's no need for an additional, fourth option as it won't solve any actual problem that isn't solved by all the features that are already available.

May be fix factory attack move and introduce proper area reclaim so people wouldn't waste half of their life clicking every stone on the map?

As numerous people have stated in this other topic that is about area reclaim - the better players among us rarely use manual reclaim with the exception during the first few minutes of the game because there's literally nothing else to do.

At all other moments of the game it is better to use patrol or the regular attack move, as you need your apm to do your decision making on the battlefield.

Anyhow - I'm asking moderators to delete future posts that reference the area reclaim discussion in this topic. This topic is not about that, it is about scouts being visible through the fog and scouts being able to be used to seriously impact your opponents economy without firing a single shot.

You have one number of trees, why do they give different amount of resources if they groupped of separated? All tree groups should automaticly break once game starts.

See the original post, in particular:

The tree groups are a product to safe on performance. They are simply put more efficient to render

We'd destroy your fps if we'd break them all at the start .

Is it also possible to "refresh" the icon of initial unit once the vision is lost on it?

I'm looking into this - but that is not going to be part of this suggestion. That would be a separate suggestion once I've confirmed that it is possible .

Curious about making this an in game option.

We can not have UI options for code that runs in the sim. It is a massive desync bomb waiting to happen.

bump

We can use this topic to discuss the feature. It is fully functional on the main branch. One issue that we noticed is that there is no clear indication as to how many fabricators are turned on / off, we're looking into that.

Identify a Problem

A unit with a jammer produces (radar) blips that are fake. These radar blips can be used to trick enemy weaponry. The radar blips disappear when you have vision over the fake radar blips.

At the moment the radar blips do not automatically respawn when you lose vision over the unit. What a lot of people do not know (including me up to a few weeks ago) is that they do respawn when you manually toggle the jamming ability on / off. They also respawn when you lose / gain power.

This is a manual interaction that is unintuitive as it is impossible for you to know whether the blips are gone or not: they are only visible to your opponents.

Showcase the Problem

The current behavior can be sandboxed using a radar, a few scouts and a few sparkies. You can switch between armies using the cheat menu. Once you've scouted the sparkies the blips disappear and they do not come back. If you disable / enable the jamming device then they are back again.

Find a Solution

We can automatically reset the jammer once the unit is out of vision. This has been suggested seven years ago:

• https://github.com/FAForever/fa/issues/968

I'll make sure that this is done such that it is responsive, but that it doesn't impacting the performance of the game.

Justify the Solution

It automates a behavior that is only possible to do manually, without knowing when you should do it.

Post the replay id

@ftxcommando said in Scouts and labs should not break tree groups:

By that logic wouldn't reclaim changing because of enemy bombs without you scouting the result of the bomb hitting the reclaim also be a bug?

Technically - yes .

But that is a bug that is very difficult, if not impossible, to fix with the engine limitations.

FAF Develop was pushed - everything should be good now.

Adaptive Tartarus

It is a well polished 3v3v3* that uses map wide decals. One of the most beautiful maps I've seen - I can highly recommend everyone to give it a view.

I've asked Balthazar to help you with this. You can also try the #modding-general channel on the official Discord. Make sure that you have given yourself the mod maker role in the #role-selection channel or it won't show up .

All of the animation appears to work fine for me. I agree that the animation speed is off, but that is up to the author / maintainer to fix.

You can try looking through the logs for errors. These should be warnings or errors right after spawning the unit. This is usually somewhere at the bottom of the log.

You can few these in game using this hotkey:

Or afterwards via the client:

And then find the log with the corresponding replay id.

@ftxcommando said in Scouts and labs should not break tree groups:

If it were added I’d rather it kept to a simple rule of “t1 units don’t break trees” than anything else.

Also it is pretty much functionally impossible to catch spirits on sentons before they get to trees regardless of player skill.

What if we add an additional unit property here:

That indicates that the unit doesn't break tree (groups)?

I agree that the situation is unintuitive - streamlining this would be my preference too.

Identify a Problem

A lot of maps have tree groups. In comparison to trees they are beyond measurable more effect to reclaim. Tree groups can be broken by units walking through them.

Scouts and labs are fast units used for raiding. They also break tree groups. This is a two-sided problem:

• (1) You can see through the fog when tree groups break, while these units should be 'low key'
• (2) These units are relatively fast and hard to catch, allowing them to be used to purposefully break tree groups of your opponent

The issue with (2) is that it is extremely effective: it is a low investment with almost no setback, while if successful you deal serious damage to someone's build order / early economic progression and you didn't even need to shoot at anything.

Showcase the Problem

Here is a replay for (1): https://replay.faforever.com/17061951

Tree groups breaking by your own scout, notice the sudden change

Tree groups breaking by some unit you can't see (it is a scout), notice the sudden change through the fog of war

An example replay for (2): https://replay.faforever.com/15963787

It is not uncommon for a mid player on Seton's Clutch to send one scout with the sole purpose to destroy the tree groups of the opponents air player. It feels frustrating as it is difficult to counter (especially an Aeon scout that is going across the water) and it doesn't feel like a technique that you should expect to be part of the game.

Find a Solution

I propose that scouts and tech 1 labs should no longer break tree groups. We can do this by giving them a new category NoTreeBreaking, and when a unitcollide with a tree group we check for that category. If they have it, then the tree group won't break.

This is a simple solution that is cheap on performance.

Justify the Solution

The tree groups are a product to safe on performance. They are simply put more efficient to render. Tech 1 scouts and labs are supposed to be 'low key' units used for raiding. Yet, they are visible through the fog by them breaking tree groups (1). And they can be used for anything but scouting by intentionally breaking the tree groups of your opponent (2). It is a dominant strategy on some maps (Seton's Clutch / Dual gap), it is difficult to see coming / to counter and it feels frustrating when it happens.

@black_wriggler said in Weapon target check intervals:

I'd say this would be a rather large balance change so I would definitely want this added to all the secondary AA at least, over bombers or gunships

Don't worry, that is what the balance team is for to make a compromise with .

And on another note, we already have a solution made by @Strogo that makes manual reclaiming a lot less painful:

• https://forum.faforever.com/topic/3372/random-ui-improvements-ui-mod?_=1652741156996

I'd love to integrate that at some point, but I recall there were some issues with it. All of the changes Strogo suggests with that UI mod are improvements to existing features, he doesn't introduce new features.

No double standards please. Allowing (1), (2), (6), (7), and (10) but not this seems silly.

I wasn't involved with FAF when (1), (2), (and (9)) were integrated. (6) and (7) are UI mods, they are not integrated. (10) is a response to (7) to guarantee stable performance for something that was already possible. I'm not sure why it is in your list.

Calling me out for having double standards is inappropriate and closely resembles a personal attack. Don't do that.

but not this seems silly.

Using this argumentation (we have x, so why not y too) means we can allow anything. I'm quite confident that it is a logical fallacy, but I can't find the name. It is also what got us to the performance we had in May 2021, before I started my performance crusade.

Also, based on the numbers you listed, I think you're imagining a larger brush size than I am, and a smaller brush size would result in faster processing the way I'm imagining implementing this. Regardless, the brush size (or max brush size, if adjustable) could be tested in FAF develop and set to a sensible value.

A brush means painting. Painting means you can include any amount of reclaim you desire. To quote you from your first post:

Imagine it like a brush in a visual editor (ie: paint), where you manually apply a circular brush, but instead of painting the terrain, it shows a visual circle where the brush would give manual reclaim orders within if used there.

If that is not your intend then you should've been more clear on what this actually means in practice. Add a picture with a clear interaction. The video and topics that Sheikah linked talks about a more generic area reclaiming, which is what the majority of us will be thinking about.

The user already has to deal with numerous arbitrary limitations to the game

Same logic used earlier that I think is a logical fallacy: just because there are already existing issues doesn't make it more legitimate to add more of them.

Don't get me wrong - I'd love to have a feature like this. But if we're not careful then we just introduce more stutters. It is also the same reason why my example here is on hold because I haven't figured out how to do it properly yet.