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.

There are several moving parts at work here.

First off, the GC is not on the Land layer, it's still technically on the seabed - and you don't have Water Vision, so to you, it's not visible. If you had WaterVision, in your blueprint, you'd be able to see him. Even though the GC is underwater, it still has normal Vision, so it can see you.

Second, your weapons are not likely allowed to hit units that are on the seabed AND below water. Whereas the GC's Eye beam weapon is allowed to fire when it's above the water level at targets that are above the water. This particular situation, might be improved by insuring that the bone, on the GC, that is above the water, is listed as one of it's 'Target Bones', as found in it's blueprint. In this way, your weapons would have a bone, that they can target, when it gets above the waves.

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

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

Map size has little to do with it - the real issue draws in two aspects - unit count (which is directly responsible for the SIM slowing down) and traffic issues (unit collisions).

While a smaller map does reduce the memory requirement a bit, it has no impact beyond that. Unit count (and the complexity of those units) has long been recognized as the largest influence on performance, and memory consumption - and this 'unresponsiveness' that you're seeing is related to that.

It can impact players at different times, as it's really a measure of CPU 'saturation' - and if the problem is severe enough, it can impact multiplayer games for all players.

Unit collisions play a very big role in this - so anytime you have a situation with a large number of those (like clumps of engineers all crowding around a factory), or traffic jams caused by really tight and complex terrain, you're going to see a very big upswing in CPU activity - which manifests as 'unresponsiveness'.

Currently 62.

@Szasz Map markers are still important for many things such as defensive points, expansion bases, etc. Some of the FAF AI take advantage of a method which makes pathfinding free of markers, using a zoning method - but that's where it stops.

Pathfinding is important, and the marker method is very effective - but - only if the map maker understands how the AI uses the markers, and places the markers with that knowledge. That's the missing part for most AI, as it's not a very interesting subject.

The placement of the many other marker types has a dramatic impact on the AI's gameplay, but again, it requires a thorough understanding of how the AI uses those, and the intelligence around how they are evaluated, that makes all the difference. It's a subject that also requires a real understanding of how the particular map plays - there simply is no universal rules that work for any large segment of maps out there.

Historically, map marking has been neglected, with many map authors either doing nothing but the bare minimum, which brought about the creation of the zone method as a way of getting around the sheer number of maps that were badly marked.

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.

I do believe that the original reason for removing the ability for T1 transports to carry the ACU was to curb exactly the kind of behavior that's being suggested. While it may seem like it would be interesting, it really encouraged a death-wish behavior that brought a spectacular number of games to a rather early and abrupt end.

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.

Black Ops Unleashed introduces teleport jammers.

This is a MUCH more visual application of the effect - very nice.

The key performance issue with Cybran build bots is rather simple - unit count. Every one of those drones is a unit - and they are being created, and destroyed, at a rather fantastic pace. This has two long term side effects - each drone creates a new entity (unit) which has to be initialized just like any other unit - and when it's finished a task - it is destroyed. This process, of itself, is not very hard on the CPU except for the intangible effects of garbage collection.

The garbage collection process of SCFA can, by the time a game is more than 30 minutes old, consume almost 20%, or more, of all the clock cycles available to the SIM. Why ? Because the creation of new units, and new tables and variables in the code are too intensive - and the memory used must be reclaimed - only to be used again - in very quick succession.

The largest of all memory allocations in SCFA is the creation of a new unit. Anyone who has ever examined a blueprint for any unit knows just how many variables are involved - and that is the problem in a nutshell. If you reduce the creation of drones down to a modest level, you minimize this problem quite a bit. Now - in the end - it becomes a simple matter of aesthetic versus performance.

Safety from surface guns is the entire reason for submarines. That's why torpedoes were developed. The idea that you can sink submarines, under the water, with any kind of surface gun is bizarre, and makes the entire class pointless. If you support that kind of thinking, simply removed the subs from the game - and just have 'water' units - and go the final yard towards simplicity.

Actually, map size has almost no impact on performance except when it comes to AI pathfinding, and that's mostly due to the number of pathing points a larger map will have, in general. Map size does consume more memory, up front, which can be a limiting factor for very large games due to the maximum memory available, but performance is pretty much all about TOTAL unit count - more than any other factor.

Both situations - damage from surface detonations and getting decent sonar from aircraft, are relatively easy fixes - simply limit AOE range when a projectile hits water, and you'll get a rather realistic simulation of the natural mechanic without taking ground fire completely out of the picture - in about 3 lines of code.

As for getting sonar from aircraft - it's actually already there - but - due to the elevation of the aircraft that have it - and the range of the sonar they carry - it actually doesn't penetrate a whole lot of water area. Either the sonar range would have to be adjusted for the elevation, or the sonar would have to emit from an invisible bone that hangs well below the aircraft. The proper solution would be to create an intel entity which drops from the aircraft, every few seconds, and if it lands in water, becomes a short term sonar buoy. The code for that too, is already in the game - it's used in the Aeon Eye of Rhianne, which creates a vision entity. This would be an adaptation of that.