=jps=sgtrock

You probably need to update or reinstall your graphics drivers. I had this problem in Ubuntu and did an update of the drivers that solved the problem with this error message. (Using Nvidia drivers that is) I'm running the latest drivers, so that's not the problem. I'm wondering if there might be an issue with running it on a 64 bit machine. My system is built on an AMD 64x2 4400. I've had to set this problem aside for the time being as I have several other projects backed up. Based upon past experience with other games, I don't think that spending time on the demo will be beneficial. It's still the same basic game engine, after all. Besides, 1.14 is more stable in general.

BTW, I just checked the AppDB. There are only 22 votes for the European version of ArmA and 0 for the US version. I /strongly/ recommend that people should add their votes for the European version so we can get some visibility for this great game!

You know, it is sometimes possible to get games to run using mixed libraries. Â Maybe what we need to concentrate on is figuring out exactly which libraries need to be pulled from a Windows install to make ArmA work. Â Once we have that information, it may help the wine developers narrow down where the problem is. For example, this is my entry into Wine AppDB for Civ 4. Â I report it as "Gold" because the game plays absolutely flawlessly (in single player, anyhow) but does require a couple of native Windows dlls. Â You'll note that I have an earlier report where I gave Civ 4 a rating of "Garbage." Â At that time, I couldn't get the game to run at all. I'm convinced that it should be possible to get ArmA running under wine if we can just figure out what native DLLs it needs. Â For example, right now I'm getting an error that says it needs Pixel Shader 2.0 support using wine 1.1.1. Â Anyone have a clue which native DLL calls that?

Personally, I still say I could live with the flight model if the landing/crash model was improved a bit. Military choppers simply shouldn't be this fragile on landing.

Maruk; If I understand this correctly:

I'm with you on the quality over quantity. However, as Stalin sagely observed, "Quantity has a quality all its own." In this context, that means that the more good players we can draw in, the better the overall gaming experience will be for all of us. IOW, we need to be inclusive, not exclusive if we want our gaming community to ever reach its full potential. Any security model which doesn't take this fact into account is simply an impediment to play and will either be disabled, ignored, or continue to drastically limit ArmA's popularity. None of these options are desirable. Look, I like the basic concept of what you suggested. My issue is that I simply cannot afford to implement it as a community run option when my server sits empty so much of the time as it is. In order for it to be truly effective without damaging my chances of filling my server, it has to be on all servers and accepted by all players. How are we going to do that without a BI required patch?

Indeed, there is nothing wrong with it, see see advanced signature usage scenario "server keys" description on the biki The entire signature concept is based on one key thing: you trust the authority that signed the addons that these addons are not used for cheating etc. and that their private key is really kept private and unauthorized people can't use it to sign anything. See also another part of the biki article. Except that you're creating more work for players to connect. Quoting from the article that you link to: Let me restate the pertinent part: So how am I supposed to get these new signatures deployed to people who have just found my server? How do I build up a player community when my basic security requirements force them to get all the appropriate bits in place first? Worse, others in this thread pointed out that modders were misusing the concept of signature creation anyhow. So how do you guarantee that both ends of the player-server connection are using a current, valid key? Let me tell you what a typical new player will do the first time he runs into either of these scenarios on a server: He'll go somewhere else. He won't bother to find out why the connection failed, he'll just leave and probably never re-try connecting. If enough server admins begin creating and using their own keys so that the player has a hard time finding a server to connect to, then he'll quit playing the game. From BI's point of view, what's worse is that he'll tell all his buddies not to buy the game because it's too hard to find servers that you can connect to. End result, empty servers and no money for BI. Earlier in this thread, I proposed a model by which when a client initiates connection, the first step would be for the server to download code to the client that verify that the client was running only approved mods. I'm slowly coming to the conclusion that's not going to work in the long run. Any such scenario would probably take so long that clients would give up and go looking for another game. End result is therefore the same; empty servers and no money for BI. No wonder most server admins turn off signature checking. At this point, the only way forward that I can see that makes any sense at all is something similar to id software's sv_pure variable. If there is any extra or modified code on the client, then the server needs to prevent the connection /and/ the player needs to be informed of that fact. I imagine that would bring on howls of protest from people running their favorite sound mods, but I honestly can't see any other way to get to an easy to use security model that can be trusted. The only other proposal that I've seen that I think may work is something along the lines of Yoma's. However, I don't think it can work unless it's deployed by BI to all as an official, required patch.

How did you do that? I'd love to make the AI on my server more challenging.

Then I misunderstood what Yoma was proposing. It sure sounded to me as if the only way to make his approach work was with his client side code pre-installed. That's not the case? Yoma, any thoughts?

This, in a nutshell, is what is wrong with relying solely upon signatures for determining whether to allow or disallow a file to be use. If you can only deny the use of a mod based upon its signature by disavowing all files signed by the same key, you haven't really addressed the problem at all, have you? That is why I advocated downloading a script to run a hash check for approved mods. It provides a means by which server admins can manage their own environments without having to rely upon a single point of failure external source for authorization of players. It has the additional benefit of not requiring any pre-installed code by the players, making it much easier for them to find and play on our servers. And let's face it: We have trouble enough building a player community as it is. I see the problem, I just don't buy the solution. No centralized approach is going to be workable in the long run. IMO, the discussion surrounding Yoma's app that has been going on since your post looks like a more promising direction. Unfortunately, I still think that requiring the players to DL and install a piece of client software is a fundamentally flawed idea for several reasons: <ul>It makes the mistake of assuming that griefers won't hack the client to let them connect to our servers anyway. That's why I think that only code deployed by the server owner has any hope at all of being trusted. It's still not a perfect solution because the code still has to be run on the client. However, at least it raises the bar by forcing a griefer to figure out how to manipulate the code while it's resident in memory /and/ he's already gotten ArmA running. <ul>Unless and until you have a large fraction of players routinely installing Yoma's app, you're stuck with a tough situation. A server admin will only be able deploy Yoma's code on his server after he's pretty sure he can meet the following conditions <ul>Already built up a community <ul>Spent a great deal of time patiently explaining what he's doing ahead of time so people have a chance to get ready <ul>Dealt with the inevitable storm of protest by some players who hate having to do anything extra to play. (I know, a lot of them would be whiners who we'd be better off seeing gone, anway. However, a lot of them would still be valuable members of a community.) <ul>He's willing to take the inevitable hit in the loss of players after he gets Yoma's code up. (People who won't install, people never got the word and don't bother to dig too far, etc.) <ul>It fails to recognize that people may want to use other external browsers, not just Yoma's. I'm thinking of apps like kali, AllSeeingEye, xfire, Steam, etc. I think Yoma's on to something with the basic approach. The one issue that we need to deal with is; can his client app (or one very like it) be adapted to deploy from a gameserver as part of each player connection? If it can, it solves all of the shortcomings that I've pointed out. If not, the approach won't fly unless the vast majority of server admins insist upon it. Right now, I don't see that things are bad enough for them to take that drastic a step on all servers.

It sounds as if you might understand the difference between the two commands. Care to elaborate? I'd love to understand what they do.

OK, we clearly have a disconnect at some point. Tell me, what do you think a signature file is? What does it represent? How is it associated with the file that it supposedly was generated from?

Are you sure about this? Â I've always understood a signed file check has minimal checks at best. Â Someone along the line in this thread pointed out that some modders were re-using signature files. Â That shouldn't be possible if a signed file had any changes. Â A signature check and be as basic as just verifying whether or not a signature itself is valid without necessarily comparing it to the file it is supposed to represent. I thought the file check routine was actually a hash comparison of matching file names on the client and server. Â That's a very different process. Â Right now, I've got the following lines in my server.cfg: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> verifySignatures=0; //Signature Verification broken in 1.08 // onUnsignedData="kick (_this select 0)"; ... //Cheat detection checkfile=0; //1=slow 0=default onHackedData="kick (_this select 0)"; Â //auto ban hacked addons onDifferentData="kick (_this select 0)"; //auto kick modified files checkfiles[]= { Â Â Â Â "dta\bin\config.bin", Â Â Â Â "dta\bin\config.cpp", Â Â Â Â "Addons\wheeled3.pbo", Â Â Â Â "Addons\weapons3.pbo", Â Â Â Â "Addons\A10.pbo", Â Â Â Â "Addons\weapons\config.cpp", Â Â Â Â "Addons\weapons\config.bin", Â Â Â Â "Addons\wheeled\config.cpp", Â Â Â Â "Addons\wheeled\config.bin", Â Â Â Â "Addons\tracked\config.cpp", Â Â Â Â "Addons\tracked\config.bin", Â Â Â Â "Addons\sara\config.cpp", Â Â Â Â "Addons\sara\config.bin", Â Â Â Â "Addons\air\config.cpp", Â Â Â Â "Addons\air\config.bin", Â Â Â Â "Addons\miscUS\config.cpp", Â Â Â Â "Addons\miscUS\config.bin" }; If what you say is correct, why are both sets of lines necessary? (forgetting the comment about signatures being broken in 1.08, anyway)

I've read through this whole thread and my gut reaction is that the proposed central repository isn't quite the right way to do things.  I hope I can articulate my reasoning well.  I've been using free and open source software (FOSS) for various purposes for about 15 years.  I've also been hosting gameservers on the Internet off and on for nearly as long.  I've hosted a pretty wide variety of servers from at least 6 different vendors.  All of those gameservers have been Linux.  I and the admins that I've granted limited rights to have banned dozens, if not hundreds, of griefers over the years.  In all that time I've had exactly one break-in (due to one of my admins using a weak password).  I'd say I've got enough battle scars to have a pretty good idea of what works and what doesn't.  That breadth of experience has taught me some painful lessons over the years about server administration in general, gameserver administration, and what tools are necessary for providing a solid experience for your players.  Sadly, BI's inexperience with the rough and tumble world of public Internet play meant that the first ArmA release was lacking in many critical respects from a security perspective.  To their credit, they've done a lot to make things much better. I had originally written a long post detailing what I thought was where they still had some holes.  However, as I thought about things a bit more, I slowly came to the conclusion that they've already provided most of the tools that we need.   In my view, what is currently lacking can be summed up by this from MadDogX: Unfortunately, I don't think that the proposed central repository gets us any closer to meeting that goal.  I think without realizing it, MadDogX points out why in the same post: Not to mention checking files is also all over the map.  Many (most?) servers don't seem to enable it because it can slow the connection process so drastically.  Yet this is probably one of the more effective ways to stop some of the worst cheats.  It's obviously not bulletproof because it still depends upon trusting the client to properly report its results.  This violates one of the key tenets of network security; "NEVER trust the client."  Still, forcing an MD5 or SAH1 hash of files at the time of connection isn't completely useless. From my point of view as a server admin, what's missing at this point in time are two functions.  The first is some way to inform someone why they were disconnected.  The suggestion to redirect them to a Web page is a good one.  However, if we do that I think it needs to be an in-game connection instead of attempting a call to open a browser on someone's PC.  I don't know anything about ArmA's scripting language, so I don't know if this is something that can be done by a modder or not.  What I would suggest is that if it is possible, it should work something like this: <ul>Player connects <ul>Server downloads a small script that includes <ul>The list of approved mods for comparison <ul>The code to perform the MD5 or SHA1 check along with the correct, precreated hashes for comparison (helps minimize the need to trust the client). <ul>The code to create the disconnect message if the connection process fails. <ul>The downloaded script checks to make sure that only pre-approved mods are loaded. <ul>If the check passes, Player connection proceeds as normal. <ul>If the check fails, the redirection code is triggered.  At minimum, this should put some text in the middle of the Player's screen that tells him why he's being disconnected.  If it's due to having unapproved mods or failed hash checks, tell the Player exactly what failed. <ul>The downloaded script runs the hash checks and comparisons. <ul>If the check passes, Player connection proceeds as normal. <ul>If the check fails, the redirection code is triggered. The other function that's missing is some way to add lots of admins without having to give them all passwordAdmin.  Ideally, I'd love to have some way to create pools of admins with map change, map change/kick, map change/kick/ban privileges.  This solves multiple problems for me.  First, it gives me a way to guard my server without having to grant unlimited rights to people who may not deserve it.  Second, it gives me a way of promoting admins as they demonstrate that they deserve it.  Third (with logging), it provides a way of resolving conflicts when someone asks to have a ban lifted because I can go back to the admin who did the action. This kind of administration mod has been available for a long time for Quake 1, 2, 3 engines, Unreal engines, Half-Life engines, etc.  Sometimes it's created by the vendor (Unreal).  Sometimes it's a modder created addon (Quake and HL).  Quite some time ago I asked on the Modding board if anyone was interested in creating such a mod.  Sadly, I got no response.   Is there anyone reading this thread who thinks they could write such a program or script? (Edit)One thing that I forgot to mention is that it sure would be nice if there were some way of displaying more detailed information about servers in the in-game browser. Having a list of pre-approved mods instead of just the one that is actually running, a complete list of who is on a server instead of just a few, etc. It would help people find servers that they want to connect to. (/edit)

Very early in this thread, someone asked how using this mod would affect someone connecting to a server with signature verification on. The reply, if I understood it correctly, was that it would not affect the connection process because all the files that were changed were not at the ArmA/addons level. Is this a correct interpretation? If so, does this expose a bug with how signature checking works? The reason that I ask is that I want to include this mod on a Linux server that I have running. TIA

Your best bet is to make note of the ones that you see running it. Your next best bet is probably to DL the mod and run it locally. Outside of that, I'm afraid you're reduced to checking them out one by one.

Dumb question: My control setup is: q throttle up z throttle down Joystick everything else The problem that I've run into (and it's probably just me) is that I don't have a clue how much throttle I've added or subtracted. Outside of watching my airspeed indicator, altitude, and attitude, how do I keep track of how much throttle I've rolled on? TIA

One other thought just occurred to me, and I honestly don't know if this is important or not. Have you considered doing a fresh install /without/ QG, then updating? My working setup doesn't have QG in it. I don't know if that's a significant factor or not. Worth taking a look at, though.

OK. They must have updated the script since the 1.12 beta then, as I had to run it separately from the commmand line to get it to work.

it happens with any mission or just a selected few? @=JpS=SgtRock, the tolower script/code-snippet just makes all filenames lowercase. since linux differs upper and lowercase. while windows doesnt. so without running tolower it can get quite quirky. I know that Linux differs upper- and lower- case for filenames. My mistake was in not realizing that his log output was showing internal variable names, not filenames. As it is, I must admit that I'm puzzled as well. I'm inclined to think at this point that osmokov may have a messed up 1.08 to 1.14 upgrade. If I'm right, it'll be difficult to clean up. However, there is this comment that leads me to wonder if he's actually run the right script to solve the problem: Even though I run it again and again, it says the same thing now every time "1 file-names were converted". In the beginning there were more file names naturally. osmokov, the ./tolower script must be run from the command line as a separate step /after/ the ./install script is run. It calls tolower.c that actually performs the necessary magic. Have you run that script?

I'm not positive, but I thought that the tolower script just cleaned up the initial installation. I don't think it touches added mods. Or am I off base? In any event, if you're at all familiar with Perl, Python, Ruby, or just shell scripting there's another solution. There's bound to be several scripts out there that'll do the job for you with some minor modifications. A Google search or two for HOWTO, Linux, lowercase, and the scripting language of your choice should come up with one for you.

Please don't make QG content mandatory. It'll limit who can use the mod pretty dramatically. I don't have it, for example, and I don't think I'll be buying it. Other than that, I'd like to echo that I like the changes that you've introduced in your version. One other thing that I'd like to see: Please change the default vote for Commander from AI to abstain. Too many players just ignore vote requests of any kind. It would make game play on some servers a lot better. TIA.

Wow. Â 8 pages arguing about the helo flight and crash models and not one person has linked to Dslyecxi's training video? Â If anything shows what can be done in an ArmA helo, that 4 or 5 minutes will show you. Note: I'm not saying that those pushing for a better crash model aren't right. Â I'm simply saying that Dslyecxi shows what's doable. Â He's too modest to mention it himself, so here's where you can find it. Â The landing on the rooftop is a picture perfect feather light touchdown. Â The video has a handful of other landings in tight urban surroundings, too. Here's another video done by one of his passengers when he was doing an insertion into a hot LZ while flying a UH60. The point for me is that while the helo crash model is very unforgiving, it's not fatally so. Do I wish it was a tad easier? Heck, yes! I probably won't ever be as good a pilot as Dslyecxi and others. But at least he shows what can be done.

Something else that I noticed: The Commander voting seems to be a bit messed up. I joined one server and forced a vote for Commander where the slot was held by the AI. There were 8 humans playing on my side on a 32 man server. I was the only one who voted. Everyone else just ignored the vote. End result? We still had an AI for Commander. Anyone who has played against a team with a human player who isn't totally incompetent knows that a team with an AI for Commander is well and truly outmatched when facing a human run team. I suggest that the default for not voting is to abstain, not vote for AI. This would mean that even if no one else bothered to vote, a player can get the Commander's slot and actually do some good.

Artillery: Arty is definitely unbalancing as it's currently structured. Â I'd STRONGLY recommend limiting its use dramatically. Â If you've ever played the Commander role in Battlefield 2, you are familiar with the tempo of play in that slot. Â Handling artillery strikes (with some additional limits to its use) isn't all that tough. Â I recommend that the Commander should be required to approve all strikes. Â (Maybe allow for "first come first served" if the Commander is ignoring artillery) I also suggest instead that the following changes be made: Limit the total number of artillery pieces that can be bought. (8? 12?) Borrow Evolution's concept of calling artillery strikes. Â Designate a light strike as one half or one third the max artillery available. Â Extend reloading times for each gun to simulate bringing up more ammo from a supply depot after the ready supply is depleted. Purchase of arty (and all static defensive pieces) should be manned by default and their prices adjusted up significantly. Static defensive pieces: I haven't seen them used much by anyone else, although as I've noted I use them extensively around my mobile HQ. Â I suppose it's because manning them gets boring, for one reason. Â For another, it's clear that players don't know that defensive AI can man them. Â It would sure make taking towns away from another player a lot tougher (and a lot more fun! if it meant having to deal with more AT, AA, etc. instead of just taking the town's Supply Depot. As noted, I think that buying them should be for manned pieces by default, although I have no problem with a "Buy Empty" option for them similar to that for vehicles. Â Placement of static pieces is an interesting puzzle if we assume that they're manned. Â We don't want them just anywhere, do we? Â Maybe allow for placing them within a some defined radius of a town's Supply Depot? Â Make that radius large enough to cover all the outposts. Â Either that, or allow for placing them only around the outposts and shrink the radius dramatically. (Maybe 100 meters? 250 meters?) In order to prevent people from building impenetrable defenses, disallow placing similar static pieces next to each other. Â One way to handle it would be to say that no outpost can have more than one of each kind of static piece near it. Â Another would be to use a radius around each static piece that no other static piece can be built in. Â I don't know which would be easier to code. Â The first method would certainly make the idea of just building around the outposts a natural choice, though. (Edit) Â I didn't realize that static pieces weren't automatically reloaded. Â If so, this is definitely an issue. Â I think there's a way around it, though. Â If a town is held by a player, any static pieces he builds in and around the outlying camps are designated as being in supply. Â Normal reloading cycles for all weapons, ammo brought up similar to the way that arty pieces are handled now. Â If a town gets taken by the resistance or the other player, the pieces have their "on-hand" supply only. Â That way, a player still has to completely clear a town if he wants to place his own pieces. (end Edit) Fixed wing aircraft: Boy, I struggle with this! Â Having only one airport makes them incredibly unbalancing, but they definitely add a fun dimension to the game. Â Unfortunately and as others have pointed out, online battles tend to focus on just struggling to own the airport instead of roaming all over the island. Â Southern Sahrani is too small for two full airports. Â I've got a feeling that when or if we extend Warfare to the whole island we'll find that it's really not all that great for it. Â Games are liable to get stalemated at Corazol. Â I think this mod works on Southern Sahrani because there are always multiple ways to go to extend your supply reach. Â If we get a larger map, it really needs to have multiple routes defined for most cities. Northern Sahrani by itself would be OK, I think. Â The problem again is that there's only one airport. Â Unless we get some user built islands adapted for the mod? How about this instead? Â Add an option for a Commander to build a small airstrip, suitable for VTOL and STOL style aircraft like the Harrier, the Osprey, etc. Â Take away the special character of the Paraiso airport and just make it another city to capture. Â That neatly resolves the problem of only one airport and gets people fighting over the whole island again.