eddieck

By default Boot Camp binds certain keys to certain actions, for consistency with the key bindings in OS X. You may be able to disable that in the Boot Camp control panel. If not, uninstall the Boot Camp driver set and just download the graphics drivers directly from the vendor (either NV or AMD) - that should be all you need.

Thank you. I mentioned this to Dwarden on Skype on August 26, but didn't hear anything back so I just left it at that (not going to chase people down to fix their own problems). ---------- Post added at 08:58 PM ---------- Previous post was at 08:55 PM ---------- It's the same one that's been used in A2 for awhile. I think most people call it "GameSpy v3" but that apparently isn't an official name. Here's a good description of it (this is for UT3, and references a "GameSpy version 4" but appears to be the same thing): http://wiki.unrealadmin.org/UT3_query_protocol

I have to agree here: keep the map neutral and let mission makers fill in the blanks.

Yeah, but he (yxman) asked for an update to this very reasonable question there too and was ignored.

Glad to see it's fixed. I assumed a global ban would probably be coming for him at some point due to the BE kick.

It's a lot of trouble but what about running A3 in a VM and using VT-d/AMD equivalent for GPU passthrough? KVM, Xen, ESXi can do it.

You were probably kicked for a BE GameHack when your game crashed, and when you rejoined an admin saw that and banned you. You'll also probably be global banned at some point in the near future, but if EMET was in fact the cause of the kick, I am sure $able will be able to verify that and remove the global ban. It might not be possible to remove the EMET detection though if it's doing something similar to an actual cheat. You should probably contact BE now to prepare for this eventuality.

Is your server behind NAT? 7 will work fine.

Agreed. While I don't think the game in its present state (or the state announced on the countdown page) is in any way "final," MDX is correct that it effectively is an arbitrary label and I for one would be quite happy if content plans were announced to bring it up to par with previous games. (I'd then consider the "release" to be a content pack for the beta, and consider the content package to be the actual "release.")

Colocation only makes sense in certain situations. This is not one of them. There is nothing about dedicated servers that make them inherently unreliable. The quality of hardware can vary, but there are a great many providers that use server-grade (usually Supermicro, which is among the best) hardware. The OVH box I linked is desktop-grade hardware, but once you start getting into the $100+/mo. range most offerings will be server-grade. Furthermore, in this case, renting will provide you better reliability than colocation. The reason for that is simple: dedicated server providers rent hundreds of those same boxes so they will have spare inventory available. If _their_ hardware fails, it's also their responsibility to replace it (and they will do so for free). If your hardware fails, it's your responsibility to arrange for that replacement - both for the replacement hardware and for someone to perform that replacement. To get the same level of reliability as a dedicated server, you'd need to have a spare server available, and you'll either need to arrange for yourself to be available to perform that replacement (if you're close to the DC) or for someone else to do that. Not only do the parts cost money, if you want to use DC remote hands for this then you'll probably need to pay for the storage of them, and the remote hands service itself will cost money. If downtime of a week or two isn't a big deal (and it certainly may not be in this case; after all, nobody is losing millions of dollars from their Arma server being down for a bit), you could go through the warranty process to save some money. But it's just not worth it - you can find a good dedicated server that costs _less_ than a comparable (datacenter and bandwidth-wise, that is) single-server colocation offer, and not have to worry about any of this. It's odd, I know, but the actual savings from colocation come when you've got a rack (or more) full of servers and can rent by the rack, not by U. edit: Actually, if you're OK with paying a large upfront cost, you might want to look around (or maybe contact a few providers; look on WHT) for any "pay down a dedicated server" offers. I think I've seen them around before, although I don't remember where.

It's still bad.

On a Hetzner i7-3770 (they were selling these as 2600s but the newer ones were actually 3770): Base Board Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: P8H77-M PRO Their older stock (presumably the stock used in actual 2600 boxes) would probably be a similar H67 model. Their disks are desktop-grade (Toshiba DT01ACA300 in the box I have access to; they probably use a few models, whatever's cheapest at the time they buy them) but at least are reasonable. They are awesome compared to Internap's Seagate HDs, at least - _those_ are horrible and make you want to burn down Seagate's factory. (SSDs FTW.)

That 64 slot server is the $50 instance I quoted. Since the OP said he would go with that if it would run better, it's safe to say $50 is within his budget. It is desktop hardware (not only is it an i5 and not a Xeon, but no ECC RAM either), but so are Hetzner's i7s. Hetzner is quite awesome as well (I do have experience with them) and they also have a line with server-grade hardware (Xeon + ECC, not sure if they still use desktop boards for that though?).

Is that really the case though? For the same price as a 64 slot A3 server from the GSP the OP listed, you can get an i5 (SB) quad-core dedicated box from OVH (in Quebec; their DC is about 8ms from NYC). Sure, it's desktop hardware but if we were to compare a $50 A3 instance to that box, I would choose that box. I don't know what the OP's budget is, but there are a few other good options at the $100/mo. range. Besides OVH which also has some servers in that range ($89/mo. for an E3-1245v2), there's also SecuredServers with an E3-1230 (v1 presumably) for $98/mo. in Phoenix or Ashburn. I have used SecuredServers in the past and didn't have any problems; I haven't used OVH but they seem to be well-liked for the most part (they're a massive operation too). I will try them out in the near future though, as they're going to be offering DDoS mitigation for free on all their servers soon. And of course, a quad-core server could run 2 servers.

The best option is to avoid GSPs, buy a dedicated server from any reputable server provider (WHT is a good resource for that) and run the server yourself. Most GSPs oversell and it shows in their service quality. In addition, when you control the box, you can run whatever servers you want (Arma and/or other games) and additional services like TeamSpeak, within the limits of your hardware of course. AI does run on a single thread and depending on your mission types, that will probably be your bottleneck. You can offload AI to headless clients (additional processes) to solve that, but there are some caveats to that (which you'll have to look into further if you want). The mission also has to explicitly support that. (I've wished for awhile that they'd just add multithreaded AI to the server binary, and Suma even said awhile ago that they were considering it, but who knows...) The server is a 32-bit process just like the client, so it can only address 4 GiB of RAM maximum, and it will probably use a lot less than that. 8 GiB will be at least enough to run a server or two (or three, honestly). 16 GiB would help if you also want to load the game data into a RAM disk, which could increase performance. Also when the Linux DS comes out, you can use that and save some money on an overpriced monthly OS license. (I know it's possible to use Wine, and there's a thread about that, but I don't know if that's something you want to get into.)

Holy fuck, this is AMAZING! Especially seeing the melee with a real animation :D Epic work!

Thank you. I'm glad to see some work is still being done in this area, as this is quite honestly one of the most important issues remaining with this game/series. (Gameplay issues are one thing; a fundamental flaw in the engine is another.)

... which is just more reason they (eventually, at least) need to be completely removed. I don't know what your current plans are for an SQF alternative, but if that's ever going to happen (I know one of the mods in the BI livestream in June said JVM was still happening, but considering the recent news I'm not holding my breath for that), that's when you really should consider making some big changes. Consider it an opportunity for a fresh start - you'll be maintaining the SQF APIs anyway for backwards compatibility, so those can be kept as they are, but the newer one can enforce proper security practices.

Related: http://img.photobucket.com/albums/v514/Benny1/what-trolls-want-you-to-believe.png I agree, this is a real problem. I have long been in favor of absolutely no in-game "admin tools" (AKA cheats) because they always get used for other purposes.

-- -- What _doesn't_ it have to do with that... you were bitching about them not creating filter configurations and it was pointed out that they did, for a pretty major mod?

Some effect = I can go play A3 for a few hours and probably won't deal with any bullshit. Then quit posting. Yes, not only have I played Warfare for hundreds of hours in OA, I have also run WFBE on several occasions with a large public population. And while there was of course the occasional issue (easily handled), I can say that I, as an admin, was spending the vast majority of my time playing and not wasting time investigating things. Good enough for you?

Because that is evidence that BE is having some effect and detecting some things? In addition to that, you can actually, you know, play the game to see how prevalent the cheats are. Both will give you a pretty good feel for how BE is doing. Also, if you want to talk about A2 for a minute - I feel pretty comfortable saying that the global bans there as well as the filters have significantly reduced cheating activity. (And I say this from a server admin perspective.)

That guy's an idiot just like all the other kids on that site. They are server-side and would have been bypassed in 5 minutes if they weren't (but they've been around for a year).

So if we say there are 10,000 bans and 1,000,000 players online (I'm just throwing out random numbers; I don't know what the ban count is but the player count definitely isn't anywhere close to real!), what will you say: that means BE is ineffective or it means only around 1% of people tried to use a cheat? I want to see that. I also want to see the mission name/version and your filter configs. Maybe you have some cheat that is undetected (why not send the details to $able then?) but if your filters are configured properly (which will require some support from the mission; if the mission is doing retarded things like having a PVEH that executes arbitrary code, then no BE filtering will fix that) then it will be blocked. You aren't exactly in a position to bitch about it if you are unable to make a better recommendation. So then have you finally figured out that the architecture of the game is the actual problem? Then maybe you can assign the blame appropriately? (hint: BattlEye can't change that) Were you not just bitching about BI not creating filter sets for enough mission/mod configurations? And when have I disagreed with that? It's not a good solution but it's the only one possible with the current architecture, and BE is not in any position to change that architecture. Only BI can do that. So WTF are you blaming BE for? So how the fuck is this BE's fault? Once again, you are blaming the wrong party.

Yes, +10000! So glad to see someone else gets this. BIS_fnc_MP should never have been added to the game in the first place. It was ridiculous that they continued adding broken functionality like this when it was evident before that this wasn't the way to go. (Honestly, props to whoever created that big hack issue a few months ago, as that has at least resulted in some security improvements.) Everything other than scripts.txt has always been server-side.