I think the intent is to demonstrate that the user owns a legal copy - and that intent is to clear their obligations - not the legal obligations of someone seeking to get around that. Of course it can be circumvented. So, technically - that's correct - it doesn't make YOU legally compliant, but it unbinds FAF from you in the legal sense by discharging their responsibility.

Rather than blaming the factory for the issue - you might wish to simply consider the scaling of naval units. There is a LOT of room to decrease the size, especially of the largest units - and I can say, having done this years ago in LOUD, ships rarely have issues leaving the yard now.

@Deribus Not sure - we've had the d3d_windowscursor command in-line at LOUD for more than a week now, but a couple of days ago, we had some new users showing up that continued to have the problem - using the absolutely latest drivers. The task manager services did the trick, which was good for the users - but the services restart themselves, and not too many users are comfortable with altering core services.

I sincerely hope that this problem gets a proper NVidia resolution, sooner than later, as it's driving people off of FA entirely, especially new users that already have to deal with surround sound issues.

We addressed this issue several years ago in LOUD - it was a rather simple fix - and it hasn't made the HARMS, or other T3 torpedo defense units, awesome or unkillable. What it has done is properly framed the submarine, torpedo and anti-torpedo units in a way that makes them viable, and a meaningful portion of the naval game. If you don't properly compose your fleets with the appropriate units, you should expect to be defeated.

It's an unintended side-effect of AOE which can easily be addressed either by altering the elevation value of the subs (which won't work on maps that have ultra-shallow water) or by having AOE range reduced whenever such projectiles impact water (which is a natural behavior).

@vanifica said in Questions about performance:

I would be totally into this. I guess I assumed LOUD worked by graphical changes, but I never tested it extensively since it didn't have an online client as far as I could tell.

They claim 5000 units without any simspeed issues IIRC. That does imply there's some "magic bullet" somewhere in the code they figured out?

This has long been a myth - LOUD never gained any real performance boost from suppression of graphics. We did toy with this several years ago, and it stuck for some reason. There are certainly some graphical things we simplified or tied to the SIM speed, but over time, most of the pretty was returned to normal.

As Jip rightly points out - there was never a 'magic bullet' - just a lot of patient work going thru almost the entire code base, implementing the techniques that Jip is encouraging FAF to adopt now. The gains are real, but the work is extensive, but not difficult.

Water depth is one of the factors that is involved here, but the effect is mostly related to AOE effects. A lot of weapons, strat bombs, battleship main guns, etc - all have great AOE range - and it's perfectly normal, above ground. However, the game mechanics don't know the difference, so these AOE effects reach down below the waves, to full effect.

For shallow waters, these are perfectly understandable, as many units are quite tall, and often, the water just isn't that deep - but - when we talk of submarines, the issue is one of their standard depth, which is specified in each submarines blueprint, and in most cases that depth is only 2 - which is insufficient to protect them from these surface-based AOE effects.

The correction, is a combination of things - first, make the submarine depth a bit greater, and second - introduce a reduction to AOE range when normal projectiles impact water.

@deribus said in Stronger ASF:

This is the approach LOUD takes.

That's not true - ASF stats are essentially identical except in their relative cost/firepower relationship to other units.

You can experiment with the FiringRandomness values directly - in game - via Shift F6. This will give you access to the units data - and if you expand the appropriate weapon, you can directly adjust the randomness values and see them take effect.

This tool is useful for many values (but not all) and FiringRandomness is one that allows active changes.

Over short ranges, it will be hard to discern randomness at work - so you may need some rather significant values to really see it - but for long range weapons, it's very clear.

The thorough design, with solid OOP principles, and the simple fact that almost every feature of the game is exposed to modification, makes it the most extensible code I've ever personally had the pleasure to work with. It's almost 100% true - if you can dream it - you can do it. That's unique and that's what keeps me at it.

The roll-off time for engineers, built from an air factory, is going to have to be maintained, otherwise all of the issues that roll-off time solves are going to come right back again.

The gameplay portion of FAF, it should work there as well - but the FAF client isn't built for it that I'm aware of. And yes - it works quite well in both the Steam and GOG versions - provided you observe the previously mentioned limitations - no alt-tab operations. Despite claims to the contrary, I've used it since the advent of the game, and it's been entirely stable.

@Tagada I'm not trying to propose anything directly - but more I'm trying to affect a change in perspective of how to have these conversations and base them on something concrete instead of conjecture. I'd assume that the simple stats are already involved, considering the way they are repeatedly mentioned, but - It's the relationships between them that you have to add to the mix.

Let me make a really simple example - two 'tank' units, from the same tier. One has more armor, more gun but less speed.

Now - modern tank design operates within a narrow performance curve, in any given general weight class. So, for the sake of keeping this simple - let's assume our two tanks are built on the same general 'frame' with common performance characteristics. At that point, the cost, firepower and mobility performance is equal.

How can we quantify the additional armor, and better gun of the one versus the other ?

Armor is dead simple - mass is pretty directly responsible - but - as you add more - you have to somehow account for what that might do to mobility - so a math function is required to describe that effect - for example, 12% more mass = 20% more HP = 10% reduction in speed/turn/acceleration. As you push the armor up - that return becomes less and less - and mobility drops quickly.

Likewise, the gun - but the gun is not so much mass as it is fine crafting - and fine crafting takes E. You want the standard pew-pew gun for that class - no problem - it's built into the base. But, you want more range ? That takes a lot more E to accomplish, and a small amount of extra mass. You want a bigger shell - that's a little different requirement - perhaps more mass. Likewise, as you push range and payload, accuracy may suffer. You want both more range and more bang - well, you see where this goes.

In the end, you get functions that let you play with any specific variable you like - and will give you a corresponding impact on related parameters - and/or - the additional costs you need to incur to make it where you want it to be.

There's a reason that Leopard tanks are far more expensive in the end, than a T-72 - and understanding the above relationship informs you as to why that is so.

I suppose, my point has really been this - we have a lot of real world examples of just how certain choices in any vehicle have an impact on the other performance factors - which implies the relationship I've been talking about. So - at the most basic level - simple relationship metrics like HP/mass, DPS/E, DPS/totalcost can help you identify 'outliers' within a unit 'type' - and if you extend that analogy, between tiers (which goes back to the T3 ASF discussion). Each unit type will have it's own variations - like shield tanks, or artillery - but they all start from a common basis - which is what is currently lacking.

As for the point about arriving at some definition of overall 'power' - it is possible - but it's complicated, not hard - you must break down the components, and evaluate each one, before you can recombine them and say 'this is power'.

No, it's not meant to be definitive, or answer every edge condition - but it's a more focused approach that just tossing around comparisons from one unit to another, or vague moving terms like 'Alpha' strike. No one talks about 'Alpha strike' in the real world, because no one constructs one-shot vehicles, DPS is DPS - whether it's delivered in 10 seconds or 1. If a unit has a weapon that can deliver such a massive punch - but only once every 10 seconds, your function will describe what it took to get that weapon to that point.

Balance comes from the whole picture - and needs to have a firm footing at some level (like T1) which will define the progressions that come afterwards. Along the way, you get to sync that with the lore - and start making sense of things like shields, sniper weapons, bombs and artillery, and how much power it takes to make a certain sized 'boom' have a certain amount of AOE around it when fired at a certain range. And why some factions seem to be more capable in one aspect, while sacrificing something else to make that possible.

I'm not advocating any kind of change - but I do think it's important to get these discussions out of the rut of 'guesswork and conjecture' - so start simple. Do some of the suggest math on the most basic units, and see where they sit.

lol - if only we had that level of control. We don't see anything about the transport process.

I would counter that by saying that these repeated roundabouts would happen far less if someone just did the work instead of openly conjecturing about it. A lot of folks, that might have an interest in the subject, have zero point of reference to the numbers that are often talked about - and even less understanding of how those values might impact the multiple relationships.

It's not something that creates a hard and fast rule about how units are set - but it does provide a stable platform to build changes on, and increases the level of trust that the community has in the work that is done by the those who do it. That's an important aspect to consider.

That's an honest sentiment, thanks for putting it that way instead of being dismissive about it.

My goal in saying anything in this thread is that there is a way forward, to making informed decisions about how to make changes to units, and address all perceived issues in a way that doesn't come across as 'shut up noob'.

If you want a certain condition to exist with a certain unit, or set of units, you should at least have a way of telling all those who feel disabused by it - as to why it is. That's the best situation, all around. Not everyone is going to like it - that's a given - but at least when changes are made, there's factual premise to it and not just theories based on anecdotal observation. FAF is littered with many changes that have fallen into that category over the years - many rescinded or revisited due to undesired consequence. Most of that can be avoided.

That's ok that you seem to content with the status quo.

I believe it does work, when in the actual game - it's just not part of the FAF client.

I wish there was more information to give on the subject - but there simply isn't. Unlike many games, a great deal of the code base is exposed for us to work with, but not this part.

@zeldafanboy And again - you can't do one without the other.

You and I seem to be on the same page - and you even use the phrase I coined so many years ago.
'Holistically'. It's completely true. It is complicated - but it's not hard. If the torp bomber is carrying a payload so huge that it dominates - then you have to examine that - and the AA on the naval units, which is, underpowered - almost across the board.

As for the 'not going to lead to a fun balanced interesting game' - you seem to imply that all those things are mutually exclusive. And the debate above would infer that you don't have those things now.