Jump to content

Jock Tamson

Members
  • Posts

    443
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Jock Tamson

  1. Nearly finished the combatants now. Far fewer instances of tracksuit guy. Instead we have stripy jumper guy, and horrible brown zip up cardigan guy. Also using @Zveroboy1's shemaghs and sneakers to further the ragtagging https://ibb.co/XY54GfB There are 25 new combatants now, and 20 new fighters
  2. And these, which are a ragtagging mashup of bits of Blimey's CMSF mods, mjkerner's Woodland asset and my own attempts at rolled sleeves, which are a wee bit ugly but serviceable https://ibb.co/N6hhSxJ :
  3. https://ibb.co/K00MPcL https://ibb.co/CB5FLbV
  4. Good news, albeit long overdue. I've never understood the meta on these forums that there is a "typical Steam user" when there are games like Scourge of War Waterloo - less accessible than CM and with graphics performance that makes CM look like it's on speed - that are rated Mostly Positive on Steam. Anyway, aside from hoping that the vastly increased exposure through Steam will lead to significant future investment in the titles, for me one of the biggest windfalls from this partnership would be if CM integrated with Slitherine's PBEM system. If you are a regular player of Field of Glory 2 or similar you will already know what a boon this is to quickly getting multiple games going with randoms or friends.
  5. 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.
  6. 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).
  7. 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.
  8. 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.
  9. 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:
  10. The credit card payment page should really be using a hosted Paypal page, instead of POSTing via a form on the website.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. No, just a wee joke for those of us that have been around games for a long time.
  16. Have Steve and Derek Smart ever been seen together at the same time?
  17. 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)
  18. 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 !
  19. What sort of frame rates are you getting? I would expect 20 to 30 on that kit, on Best settings. Over the years I have had GTX 580, 680, 980 and now 1080. It makes little odds, it is the CPU that has the biggest impact. I think your CPU turbos up to 3.9Ghz, which is middling.
  20. Please change thread title to "good performance" It is worth limiting the FPS to 30 in the Nvidia settings and then enabling vsync, you will get fewer peaks and troughs which will make it smoother. Frame rates will respond well to overclocking (you should be able to get your CPU to 4.2Ghz without much effort).
  21. Disabling MFAA won't do anything, the game has to support MFAA to enable it. CM doesn't.
  22. I presume everyone in this thread is aware of the "Shaders On" crashing the game if you have Nvidia drivers newer than about December 2017 ? There is quite a lot of detail in one of the other CM2 Technical threads. Tends to happen after about 30 mins play.
×
×
  • Create New...