FAQ Authors

How do you pay devs in a fair manner? The time spent differs each month and everybody has a different productivity level. We can't even quantify the outcome.
100$ have a different value for a student compared to a senior dev, same applies for a German dev vs a Spanish or Hungarian dev.

Let's say I earn 60k€ per year=5000€ per month (before taxes, social insurance etc., that's a medium German salary for an experienced dev and a simple number to calculate) for a 40h week. To take a whole working dev off every week for faf this would mean 1000€ per month.
Many students in Germany live from 400€ per month!

A realistic budget we could spend per month is 300€ max... you don't get an experienced dev not even 50% part time for this. Maybe you get an outsourced call center agent for that...

Here are the current loading tips. Anyone can suggest new loading tips in this thread. You can suggest specific tips with specific wording in quotes, or you can just describe what sort of tips you think should be added.

We discuss this once a year. Putting money on issues causes more problems than it solves.

There are 2 facts:

1. We lack and overall amount of manpower.
2. We have decided not to pay (core) developers.

People always want more features. So you put money on these features. Core devs don't have time for these features (otherwise we wouldn't need putting money on it), so potentially new people appear solve it and get money.
This leads to the situation that core developers who do not get money need to guide and review people who get money for their work. Also while they work on cool new features while core developers can still mop the floor. This is not a healthy situation.
Alternatively if you put money on groundwork issues it will most probably redeemed by core developers. Which we didn't want to pay in the first place. Also this wouldn't improve their work hours, just shift their direction.

I see no win scenario here.

@xiaomao
I am well aware of what I just posted. If there is a bug, it should be fixed. (If it just misses a lot due to its intended firing randomness value, I wouldn't consider that a bug. However, if, for example, they have an issue with their targeting where they consistently miss auroras by aiming way too high, maybe there's a bug...)

@xiaomao
Looking at the code, the sky slammer has 3 weapons:
1.

                        Damage = 9,
                        DamageType = 'Normal',
                        DisplayName = 'Nanodart Launcher',
                        FireTargetLayerCapsTable = {
                            Land = 'Land|Water|Seabed',
                        },
                        FiringRandomness = 1.5,
                        FiringTolerance = 2,
                        Label = 'GroundGun',
                        MaxRadius = 18,

                        Damage = 0,
                        DamageFriendly = false,
                        DamageType = 'Normal',
                        DisplayName = 'Targeting Laser',
                        FireTargetLayerCapsTable = {
                            Land = 'Air',
                        },
                        Label = 'TargetPainter',
                        MaxRadius = 32,

                        Damage = 16,
                        DamageType = 'Normal',
                        DisplayName = 'Nanodart Launcher',
                        FireTargetLayerCapsTable = {
                            Land = 'Air',
                        },
                        FiringRandomness = 1.5,
                        FiringTolerance = 2,
                        Label = 'AAGun',
                        MaxRadius = 32,

Since the unit was specifically given a weapon that's used against land and not air, and that weapon was labelled 'GroundGun', that was clearly intended. If they have a bug, it should clearly be fixed. It's really obnoxious for you to respond so flagrantly.

@thewheelie

Some people read jokes like that and take them literally. I'd suggest not making those sorts of jokes on the forums...

@Rowey you werent shut down, I simply did not have time for anything except paying bills (which is why I did not candidate again)

FWIW, the trailer contest seemed like it worked out pretty well. Different people have different tutorial styles, where a given tutorial might be more helpful for some players, while a different tutorial might be more helpful for some others. Alternatively, if we want to avoid multiple tutorials on the same topic, we could avoid repeats with a first-come first-served style, where the contestants sign up/reserve their tutorial topics before they make them.

@blackyps said in What would be an efficient use of FAF's funds to improve FAF?:

Where can I buy one?

FAF could fund a FAF tutorial creation contest. Would that be a good idea?

The current manual reclaim situation is undesirable:

1. When used properly, it gives additional artificial advantage to those with higher apm on top of the advantage they already get from high apm otherwise. Even if it's only from clicking during the first minutes of the game, that can result in large butterfly effects.
2. When used improperly, it's arguably a noob trap.
3. Many people find it annoying/frustrating to do, especially when low-value reclaim is densely mixed with high-value reclaim.
4. It contributes to bo-based advantage and perception of bo-based advantage, which is one of the leading reasons people stated they don't play ladder in this thread.
5. Feeling like you have to do it or are at a disadvantage contributes to ladder being more stressful/intense, which is one of the leading reasons people stated they don't play ladder in this thread.
6. While attack move is a viable alternative for many situations, there are many others where it's an inferior substitute that doesn't resolve the problem. Notably, if there is enough high-value reclaim mixed in with a lot of low-value reclaim, attack move gets the high-value reclaim much more slowly, while manual reclaim is more annoying/frustrating/sweaty/stressful/apm-consuming/etc.

I think this situation should be improved. I am open to different ideas for how that could be accomplished. For example, if someone knows a reasonable way to sufficiently adjust how engineers act when using patrol/attack move, there might be a solution there, but I am not aware of that being a realistic option atm. So, if you have a good idea, feel free to share it.

If no one has a better idea, I think we should add a reclaim brush, as I think that would improve the situation. Some details about how the brush could work:

1. It could be represented with a circle when being used, where the brush would give manual reclaim orders within the areas it's used on.
2. It could be restricted to only give manual reclaim orders to reclaim that is above a certain value threshold (ie: only >35 mass).
3. There could be different hotkeys that enable you to use the brush with different threshold levels (ie: there could be 1 for >10 mass, 1 for >100 mass, 1 for tree groups, etc).
4. There could a cap on the processing cost per unit time, a cap on the max number of extant orders that could be queued with the reclaim brush, and a small enough brush size to avoid technical issues.

PS: Many additional points and counterpoints regarding adding a reclaim brush were previously made here.