Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

11 Good

About bus

  • Rank
    Private First Class
  1. Well, the commands would be available to mission designers. They can design the mission and say that they require the security flag to be disabled for the mission. Then at the discretion of the admin who would be deciding whether or not to host a mission, they can increase or decrease their security levels per the mission requirements. This wouldn't be a community wide ban. So, if you design a mission using the full command library, the server admin has to ensure that it's compatible with their security settings. So it would be an optional flag and not necessarily something that's banned community wide. For example, if a mission like Wasteland required a certain flagged function, admins that want to host Wasteland would have to disable the flag. Other missions that don't require these commands are then run on other servers...so why should those servers, run by admins who can pick and choose their security levels and missions, be exposed? If the commands aren't needed by an admin for a mission, lock em down.
  2. BIS: Are there any plans to hurry a limited update for the stable branch for this change? •Small first of many stages to reduce MP security vulnerabilities: should no longer be needed to restart the whole game to undo the common functions breach. This should also prevent it from spreading (but does not help the current situation on default branch servers of course). More on the topic in the next SITREP. Also, it'd be nice if whatever change you made didn't only take effect on server connection/disconnection but also mission change. As a work-around, it'd be nice to able to limit the damage to a single round by allowing an admin (or a vote) to simply start a new mission or restart the current one. Also, is it possible to add a server flag to disable the use of ... more sensitive commands in missions run on the server? For example, and I'm not an expert on the exposed functionality so others should weigh in, can it be made possible for an admin to set a flag to disable a broad set of scripting functions so that command executed either by a mission or by a player on the server are ignored? In this particular case, it might help to limit the exposure to only the players on the server at the time (new players would be unaffected by the hack distribution) and that after a mission change, even the affected players common functions would be 'cleaned'. It would be additionally better if that common functions disable flag were inherited from the server by the client while the client is connected to the server. This of course would reduce the commands available to mission designers but at least it would be an additional option for admins to use that could protect their servers. This would place burden on the server admins to ensure that the missions they run are functional even with the reduced functionality but at least they have a choice.
  3. The real shame of this is the damage it's causing to the community. For those that are saying this hacker has done a service, I can only say that I disagree. What this hacker has really done has locked any new players or players that haven't yet had a chance to join a group or build up their friends list from playing Arma3 online. Sure, if there's a lack of security, some 'might' be able to call that a service but from this morning until now: look at the amount of open servers. The community is on lock down. It's closed to new players and that's a real shame. BIS: Anything you can do to help us is greatly appreciated. The players that are getting hurt the most are your potential new customers. The loyal ones will be here regardless but healthy communities need new blood in order to survive. It's in both of our interests for a permanent solution to be found as soon as possible.
  4. So what we have basically (assuming Tonic is correct) is this: 1. hacker joins, recompiles the bis_fnc_mp and sends it out 2. server, being a client, receives it, executes it and stores in memory as the new 'current' bis_fnc_mp, initiating step 1. 3. clients receive it, execute it, and store it in memory as the new 'current' bis_fnc_mp, initiating step 1. 4. clients disjoin server, join another server, bis_fnc_mp gets executed and the player, unknown to them, becomes the 'hacker' initiating step 1. If true, kind of brilliant in a 'supreme jerk of jerks' kind of way.
  5. It could be affecting those that run the game 'as admin' which I had not being doing until just a few days ago.
  6. I've actually removed my installscript.vdf file. I believe this functions in a way similar to VAS: perhaps it stores an entry locally to be executed regardless of the server, mission, etc? I don't know much about VAS but I checked the player.vars.arma3alphaprofile file and saw some VAS references. Now, to be clear: I'm not blaming VAS. I'm saying that the storage and execution method might work in a way similar to VAS. I've removed my vars file and have tried running a local MP game. I have not had the issue re-appear in the last ten minutes or so but I'm still testing.
  7. I don't think this is strictly a server side issue. I've restarted our server, re-uploaded missions, password protected it and the hack returned. I suspect it's a client side issue after having connected to an infected server.
  8. bus

    Arma 3 MP, Is it Worth it?

    Is that depending on the mission you're playing? I seem to have pretty stable FPS in multiplayer, sometimes higher because the AI processing seems to lag my client down when I play some missions locally. I tend to play on small servers though (<=10 players, <=100 AI).
  9. bus

    Verify Signature

    I think it's been fixed in the dev build but I don't see any mention of it in the latest Alpha change list.
  10. I'm running Arma III on a Radeon 6970 at ~6000x1200. I've got it running acceptably well but the only issue I'm running into is that the positioning of the HUD elements is cut out because it renders in an area that's 'blocked out' by the bezel compensation. It makes it kind of difficult to admin the server or respond to players because the first number or two of their ID or the first letter or two of the player name who's transmitting is rendered in an unviewable area. I realize this isn't a 'fault' of the Arma engine so I'm wondering if anyone else has figured out a way to work around it or if perhaps, the AIII HUD components will eventually be placeable like the ones in TOA? Thanks, Bus
  11. I had the same crash to desktop every 15 minutes issue as well. I checked the event log and sure enough there was a PhysX related error but a guy I play with (GruntzTastic) clued me into his secret: switch to the dev build, play the game, switch back to the regular build and I haven't had a crash since. I was updating drivers (which is a good thing anyways), re-installed Arma via Steam, etc but running the dev build then reverting was the nail in the coffin. Alpha...right?
  12. It's an issue with NAT translation. Basically, you've got 2 Arma clients on the same networking routing through the same public IP address. So even though they have 2 separate private IP's, and, they're both using 2302, 2304, 2305 as the standard ports...even as outgoing. Most normal programs will generate a dynamic source port, Arma doesn't appear to do that. So when NAT tries to translate your outgoing connections, you're NAT firewall ( and some public IP) can only support 1 or the other because (to overly simplify things), when you initiate an outgoing connection through a NAT router, it does this: Private IP - Private Port - 2502 Protocol: UDP Public IP - (or whatever public ip you're assigned) Public Port - 2502 Protocol: UDP And then it forwards your packet to the server. When the server replies, it'll reply to on UDP port 2502. So if you have 2 computers that are trying to use that same IP and Port through the same NAT firewall, the packets will either get routed to one computer or the other computer...possibly both depending on your firewall. Depending on your NAT configuration and/or what router you're using, it could be more or less restrictive. To get around this, modify your ArmA2 shortcuts and add " -port=2350" to one of the computers. The number doesn't really matter, just as long as it's different from the other computers which will use 2302, 2304, 2305 by default. This will change the client port (though it's not documented) and allow you to connect to Internet servers. Well, at least it should ;-) Also, another strange thing is that it won't actually use the port you specify, in this case 2350, it'll use +2, +3 of that. So you could technically specify -port=2304 and it'll end up using 2306, 2307. If you specify -port=2303, it'll conflict on port 2305 so don't do that. Skip at least 3 for every computer. You can always check open ports by opening up a command prompt, typing "netstat -an" and hitting enter. It'll list all of the open TCP and UDP ports. This being ArmA, you're interested in UDP. Dont pay attention to the endpoint column though...it's UDP which is "connection-less" so there isn't any maintained connection. The packets just kind of get there...or they don't and ArmA compensates (or tries to) appropriately. Let me know if this worked for you. Bus
  13. I would agree with you on that and have felt the same in the past but there are other people on the team besides the engine designers/debuggers. Those artists/mission designers/audio engineers/etc have to do something while the programmers are debugging things. What primarily concerns me is if ArmA3 get's released without BIS improving the warping in ArmA2:OA. I mean, how can they say the multiplayer is better in A3 if they haven't fixed it in ArmA2:OA? Unless the netcode for A3 is entirely brand new. Regardless, it seems like they're finally trying to put their finger on this warping issue so kudos to them for sticking with A2:AO and not abandaning it entirely to prepare for A3. -Bus
  14. Just wanted to let you know that a new group, [COMMON] gamers is forming. I've put up a small server running 1 mission, a custom infantry centric domination-esque mission of my design, and posted a website @ commongamers.com. I've tried to put a bunch of info on the site explaining what [COMMON] is all about but I'll try to provide a quick summary here in the forums. A true "clan" or gaming group is much more than just a server and a website, it's a community of like minded gamers and that's what [COMMON] is hoping to become. The idea behind [COMMON] is that there are those of us who: -Like a hint of realism in our gameplay -Want some organization in how we play the game -Are not able to manage the added weight of military realism -Have normal demands on our time away from the computer What I'm trying to do is to put together a community of players, doesn't matter how small or large, that are flexible, enjoy playing ArmA in a tactical fashion and aren't looking to re-invent the traditional milsim wheel. [COMMON] has no attendance requirements. We place no limitations on what or how many other groups you participate in and you don't have to "wear" the tags. [COMMON] isn't about enforcing a set of rules...it's about providing a relaxed framework for enjoying ArmA with like similarly minded gamers. Keep in mind, [COMMON] is brand spanking new so we can't provide the services that some of the larger more established clans offer (multiple servers, teamspeak, huge overly involved rank structures) and we're not necessarily looking to. Again, the size of the community isn't what's important to [COMMON], it's the quality of the members. There's more information on the website, commongamers.com, if you're interested. Thanks for your time, Bus
  15. Dude, Beagle hasn't explained anything. He kindly mentioned something about a config file and i politely asked him to elaborate. To be clear, I'm not asking for a full blown HUD like in the link you posted, I'm wondering what happened to the simple green crosshairs that were in the AH-1 in Armed Assault 2 (no mods, just vanilla AA2) for the pilot and why aren't they in Operation Arrowhead. Have they pulled that crosshair as a feature update so that the pilot needs a gunner or is it a bug. If it's a bug, is there a way to fix it? if it's a bug, will BIS release a fix for OA? If it's a bug, will BIS not release a fix for it and I'll be stuck with an, although superior, not 1st party mod like the one you linked to. Your attitude was the one that's not "nice" and I'm simply not taking your crap. Thanks, Bus