Jock Tamson

A server/ client architecture allows a few creative ways to get more out of the CPU, without the complexities of multi threading. For example, in Arma 2, I used to launch my missions as multiplayer missions on a headless server, which used one core on my CPU and was responsible for the opponent AI, hit calculations, mission scripts, etc. I would then join that mission as the only player, from my Arma client. This ran on different cores and was responsible for rendering and friendly AI. Whereas that mission running as a single player mission might run at 40 FPS in my client, with a lot of dips when the CPU was busy, when played as a multiplayer mission which my client was connected to, I would get a steady 60FPS in my client, due to the offloading of AI etc to the server running on the other cores.

A headless client can run on the same PC, but on a different core. It is NOT the same as multi threading. Multi threading is much more difficult. The principle is to have the AI running as a virtual opponent, on one of your spare cores, reacting to the information coming from your main program (which contains a server element, and the client that you use yourself).

I'd like to see Friendly AI plans able to be used in scenarios. So that, for example, your orders in a scenario could be to use your troop of Shermans to support A Company's attack on the village, and A Company is controlled by the AI.

Most of England north of the Humber was run by the Danes - the Danelaw https://en.wikipedia.org/wiki/Danelaw And of course ultimately, in the shape of The Normans, they came back again 150 years after Alfred had defeated them.

Edinburgh was at the centre of the medical world in the c18th and c19th, hence the need for cadavers. Many Edinburgh graveyards still have a watch house or watch tower in them, to guard against grave robbers:

The credit card payment page should really be using a hosted Paypal page, instead of POSTing via a form on the website.

I would have no concerns with that. My Paypal account is associated with my primary debit card. The issue I have with debit cards is inputting the details into an online form. I would never do that. With the one exception being the one time process of adding the card to Paypal, who I trust.

With respect, the developers have checked to see if files have changed unexpectedly. They haven't, so that has ruled out one of many potential sources of issues. Arguably the least likely, but definitely the most straightforward to check. Not the same as checking if your site has a vulnerability. Your developers are rarely the people that find vulnerabilities on the sites they build. Most web developers I know don't truly understand what makes a website vulnerable. They pull open source code off the web willy-nilly, they produce web sites that are vulnerable to cross site scripting almost as a matter of course. Most would struggle to explain, definitively, how everything [DNS, etc] works to get content into a browser from initial HTTP request. I'm not suggesting BF need to do more, merely clarifying that there is actually plenty more that can be done to give a site a reasonably clean bill of health.

I always use a Paypal account, which I do not keep signed in. This means that at the point of completing the transaction, I get taken off to Paypal's site and I am not entering data ie my username and password anywhere other than on Paypal's site. I don't use debit cards for online payment, period. When you use a form on a website which is not clearly an iframe from a payment gateway, it is difficult to tell where the data is being posted. Or whether, indeed, javascript in your browser is quietly hoovering it up and firing it off somewhere in the background.

Supply chain attack is much more common than a malicious third party changing your javascript. Pretty much all websites consist of a combination of bespoke coding and open source code and libraries. The open source stuff may be getting pulled afresh into a website's codbase every time a new build of the website takes place. Or, javascript on one's site may well be in turning calling third party scripts. This is what happened to British Airways, whose customer's were exposed to a key logger due to third party libraries having been exploited. I've been working on extremely high volume websites for 20 years. The attack surface has changed markedly in the last 4 or 5.

No, just a wee joke for those of us that have been around games for a long time.

Have Steve and Derek Smart ever been seen together at the same time?

The Uncons are a bit of a disappointment. Partly because of the lack of vehicles in QB, and partly because of the lack of diversity (seeing 40 plus guys all wearing the same tracksuit top). Considering how easily the diversity was modded in the last game (I created a dozen variants in less than a day)

license key

Ok, so that particular CPU boosts up to 3.6Ghz. I would regard 30-35 FPS as ok, in that context. Basically the performance is CPU limited, for all of us. It runs on a single core, so the faster the better. You might notice the stutters less if you use Nvidia Inspector to limit the frame rate to 30, and set vsync on. You will get fewer peaks and troughs. Be thankful it isn't Scourge of War Waterloo - I get FPS in the teens at times and that is with a 8600K @5Ghz and a GTX 1080 !