Jump to content
Bohemia Interactive Forums

sergeant rock

Member
 View Profile  See their activity

  • Content Count

    199

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by sergeant rock

  1. Posted

    Yes, it includes new units.  They are not as flashy and well skinned as Suchey's Marines, rather they are tweaked for WarGames specific use.  The damage value of the soldiers has been modified to take slightly more of a beating, and they have a removeable rucksack that can store extra bundles of mags, satchels, or other equipment.  Items can be removed from the ruck, or the ruck and be dropped completely...pretty ingenious actually.

    If you're looking to play WarGames specific missions (c&h, a&d, objective, co-op) stop by The Citadel (the-citadel.us).   smile_o.gif

  3. Posted

    Quote[/b] ]Am I the only true american here!
    Quote[/b] ]OH yeah. Care to elaborate on why? I have direct ancestors that came over on the mayflower. Beat that.

    I'm part Cherokee American Indian.  Consider yourself beaten.  wink_o.gif

  5. Posted

    Had to pull the links for WG 2.01 Addpak and Patch from the Citadel FTP.

    We have hit 500GB of bandwidth on the Citadel and its only December 14th. We have a 750GB limit, and normally only use 150-200GB/month. I will keep the remaining 250GB reserved to insure the game server/teamspeak have enough left for the remainder of the month.

    Sorry, but its a question of economics. wink_o.gif

  6. Posted

    Disabling cloudlets has no effect on viewdistance, but does affect smoke producing devices and fog. In fact, setting a low viewdistance on foggy maps is a good way to prevent foghackers. wink_o.gif

  7. Posted

    Quote[/b] ]Any servers running this pack yet? I am dying to try this out in MP!

    The Citadel is running the new WG 2.01 pack. Feel free to stop in any time.

    Server and TeamSpeak IP: the-citadel.us or 69.56.169.34.

    The WG 2.01 AddPak is also available thru OFPWatch on The Citadel.

  8. Posted

    Relax on the name calling and accusations.  Calling people "fucking retarded kids" and "fags" certainly doesn't lend validity to your arguments.

    For the record I was involved in some very intense checkfiles research both for our server 'The Citadel" and for the WarGames league.  Zinco from [uSMC] has also spent many countless hours in pursuit of the same thing.

    I will just touch on a couple things that we determined through our research:

    1. Checkfiles can be wildly inaccurate, and can be influenced by ambient network and hardware conditions.

    2. Just because someone throws an error indicating a modified file doesn't prove they cheat.

    3. Certain addons have the ability to cause modified messages for both data.pbo and dat3d.pbo.

    4. Aboslute clean installs of OFP from a legally purchased CD, without addons, and without modified EXE's, has still resulted in a modified file error on ocassion.

    5. Disk controller errors or failing harddrives can modify the CRC value of the file and result in a false positive.

    6. CRC values of the PBO's on a dedicated server sometimes became corrupted and resulted in anyone joining getting an error message.

    7. Monitoring of data.pbo and data3d.pbo is pointless due to many addons causing false positives.  The more important files to watch out for and always proved accurate in our testing was merged.pbo and config.bin.

    8. Merged.pbo is where the soldier uniform textures are stored and where certain cheaters "spike" or paint fluorescent colors onto the uniforms so players stand out instead of being camoflaged.

    9 The only files that the WarGames league concluded that are reliable enough to arouse suspicion are merged.pbo and config.bin.

    10. Checkfiles does not work properly on Linux dedicated servers.

    11. Certain European versions of files have different CRC values than North American copies.

    12. Some sound mods do cause false positive checkfiles errors or messages.  The infamous and oft seen "Subdivisions" message is one example, which I belive is caused by Stachel's sound addon if memory serves me.

    13. Shooting through fog has nothing to do with modified files and everything to do with people disabling "cloudlets" in their OFP config.

    All I can say about NASF is that they just complted their first season in the WarGames league, and have never been accused of cheating nor did they appear to be "superhuman" during any of their games.  They have always played with honor and have made a meaningful contribution to the league.

    Do some people cheat? Sure.  Is it as prevalent as everyone thinks? No.  Sometimes, belive it or not, players are just that good or just real lucky.

    Just my .02 cents...spend it as you like.

  9. Posted

    Miles: I asked a similar question in the WarGames forums, here is Angus' well researched reply:

    Quote[/b] ]Currently the 5.56 and 5.45 (m16 and ak74 rounds, respectively) have been toned down for a couple of reasons...

    - They were too powerful compared to the 7.62 round (they were only 10% weaker than 7.62 before), which is think is "just right" for 7.62 the way it is so that snipers have a good chance of killing in one shot. A little research will show that the damage done by a 7.62 rifle round is significantly higher than the small caliber rounds. Generally it's about twice as much damage by a 7.62, which is what it is now (10 vs. 5.25)

    - You can still kill someone with 2 or 3 shots to the chest area, up close

    - You can still kill someone with 1 shot to the head even with 5.56 and 5.45

    - Bleeding kicks in after only 2 shots (i've tweaked it a bit in 2.01 so it's more "in play") and the chance of bleeding out should be more of a worry with the small caliber stuff

    - Shots to the legs still gimp ya

    - It puts more importance on the M60, M240 and PKM gunners because they can kill ya good with just a couple shots

    - It's more realistic. The smaller caliber rounds were chosen (in real life) for a lot of reasons, one of them is accuracy and high speed, and the other is to wound soldiers. The idea being that if you can wound a man it takes 1 or 2 men to carry them out or work on them to save their life. If you kill a guy he's dead and that's that.

    EDIT...

    - Weapons with high rates of fire like the M249 (which fires the same bullet as the M16) have an advantage because they can pepper the target with more lead and faster. So they have no problem killing people and should be feared also, as they are in real life.

    And this from a former military member:

    Quote[/b] ]Rock, keep in mind the reports that came out of Afghanistan about soldiers with M4's shooting Talibaners five or six times and they are still coming at them.

  10. Posted

    I would consider this more a public, late-stage, beta than a final release.  I think he needed to get it out to the community for rigorous testing...something he wasn't getting much of unfortunately within the WG community.  

    Keep those bugs coming, the more we squash now, the less patches he'll release...and the less patches he releases the less bandwidth he uses on our server mirroring this pig! LOL

    And, the sooner he gets them all fixed, the sooner he can get back to playing with his squad. :hint: :hint:  wink_o.gif

  14. Posted

    Quote[/b] ]Anyways, from looking at the config, the following should suffice to make bas_ofpcpp.pbo correct in that regard:

    Code Sample  

    requiredVersion=1.85;

    requiredAddons[]={BIS_resistance, BRDM, JAM_Magazines, Su25};

    Note that requiredAddons, as I recall it, is a feature that came with 1.85.

    Was having fits with a mission that kept blowing up because of missing addon: bas_opfor, even though the mission doesn't use any BAS addons. I tried all the old tried and true methods of fixing this, but still got the message everytime, causing the mission to crash.  I added the requiredAddon line to the CPP, Re-PBO'd, and the problem is fixed.  

    Thanks Killswitch I owe ya a beer!

    Ebud, will these suggested CPP fixes be implemented in a patch?

  15. Posted

    Its a MP mission.  I got it working by declaring an array in the init.sqs:

    Quote[/b] ]

    codearray = [{helo1 = _vcl; publicVariable "helo1"},{helo2 = _vcl; publicVariable "helo2"},{helo3 = _vcl; publicVariable "helo3"}]

    Then calling the array in a loop inside of vrespawn.sqs:

    Quote[/b] ]

    #start

    call (codearray select _index)

    ?(_class == "UH60"): _vcl removemagazine "ZuniLauncher38"; _vcl removeweapon "ZuniLauncher38"

    ?(_class == "Mi17"): _vcl removemagazine "Rocket57x192"; _vcl removeweapon "Rocket57x192"

    @(!canmove _vcl)

    ~119

    _vcl setfuel 0

    _vcl setdammage 0.01

    deleteVehicle _vcl

    ~1

    _vcl = _class createVehicle _respawnpoint

    _vcl setdir _azimut

    goto "start"

    Lastly I use a separate trigger to call the helo_dust.sqs script for each helo name.

    Works like a charm....

    Props to Tactician and AngusHeaf for their help. smile_o.gif

  16. Posted

    I have employed a heli dust script that requires that the vehicle name be passed to it in order to function properly.  Such as: helo1 exec "heli_dust.sqs".

    The problem I'm having is that after the vehicle is destroyed and subsequently respawns, its original name is no longer associated with it and the script fails to run.

    I've tried unsuccessfully through various methods to trick the game engine, pass a new name, etc., but nothing seems to work.

    I'm sure this has to do with clients not being passed the new vehicle name or something similar.  I've just about pulled all my hair out of over the last couple nights.  Can anyone help me out?

  18. Posted

    It happened again on the CITADEL on 7/22. Both Data.pbo and Data3D.pbo checksums changed. I say again, this actually changed on the SERVER side. I will post screenies of the CRC32 results when I get home from work. This is 4 times now that I'm aware of.

    Curious as to what could be causing it. I doubt an addon could permanently alter them. They are set to READ-ONLY. Perhaps defragmentation of the drive on the NTFS file system can affect the crc value? Perhaps the drive controller is failing and somehow alters the file? This is bizarre.

    I check once a day now for change, and copy in a good PBO from my backup if I notice a CRC difference. Shouldn't have to do that....

  19. Posted

    Thanks Suma. If this is indeed related to the FPS issue a fix may not be possible as the server quanta in Win2k is not controllable in the release version. I'm still not sure I agree though....since Win2k quanta is fixed, then why the disparity between several servers running the same version of the OS? I have a theory it may be related to processor speed/architecture and perhaps quanta in combination.

    For example I have 2 servers, both running Win2k SP3. The server with a 3GHz processor runs at 32 FPS, while the server with a 1GHz processor runs at 50 FPS. What are the processor speeds of others having this same "issue"? If we could come up with some sort of pattern, perhaps we could derive an answer.

    However, since its not performance affecting, and more about people wanting to see that "50", then I guess its not a big deal..... rock.gif

  20. Posted

    Our server runs the same way. 32 FPS ceiling. My question is if a server with a 32 FPS ceiling is running at 15 FPS, is that equivalent to a 50 FPS server running at 33 FPS? Get my drift? Unless we know the answer to that question, it may be difficult to guage server performance with the monitor utility.

    Suma, the person who wrote the "monitor" code doesn't know how the FPS is determined or why it may appear different on some servers? I'm not understanding your response.

  21. Posted

    I don't know if what you're asking for would be possible. BIS never released the source code, and what you're asking for here would be a source code modification. There may be a way in Linux (and maybe even Win2k) to write a shell script to MD5 the files on the server but never interactively with the connecting clients.

    From some research that I did, CRC should be more than adequate to detect changes in the binary data of the pbo files. CRC does not become more or less relaible based on the size of the file. CRC, in my opinion was chosen over MD5 because of the differences in computational time. As you know, with checkfiles running, attaching to a server takes an extended period of time as the CRC code checks the files on your PC and compares them against those CRC values from the server's pbo's. Being that MD5 does a more stringent and accurate test, these computational times are significantly increased. This also momentarily increases load on the CPU...not something you want to happen in the middle of an intense firefight. smile_o.gif

    MD5 is primarily used in cryptography and computer forensics when researchers want to ensure that the data was not modified and "tweaked" so the CRC check is still valid (or when you are just really anal about being absolutely positive that code hasn't been corrupted during download or burn to a CD). Because the CRC check is mathematically much simpler than MD5 it is possible to modify data, and then find a way to make it equal the CRC checksum by entering bogus nonsense data. I could explain how that's done, but you would probably be asleep by the time its finished.

    I'll research more on the server modifying its own Data.pbo file. I've seen it first hand, so I am confident it is indeed happening...just don't understand why....

  22. Posted

    Zinco, I've found that the Data.pbo file on our server ends up being the one getting modified...not the one on my local install.  Very strange...at certain points it will become spontaneously altered resulting in a bogus checksum.  I've made backups of all the CRC verified pbo's, and have resorted to checking the Data.pbo on the server at a regular basis and copying a "good" version in when I find it modified.  I've never experienced this with any other pbo.

    Contrary to your findings, I can connect with all my addons (BAS, MTCO, Etc) and not recieve any modified file messages.  I'm not disputing your excellent research, but there is still some factor eluding us that is causing these messages.

    I'll continue to test and post finding here.

  24. Posted

    We have a single P4 2.4 GHz server with 1 GB RAM on OC3. We are running Mandrake Linux and Dedicated server 1.90f. Why do I see that OFP is using nearly 100% of the processor when the game is running? It uses the entire CPU whether the game is running at 50 FPS or 10 FPS. Do we have a setting or tweak wrong? Anything we can do to improve performance? I find it hard to believe the resource hunger of this game...it is unparalleled!!

    Rock out.

  25. Posted

    Anxiously awaiting the linux version of our server, and the ability to do all our own maintenance.....then we can stop bothering you Ed! biggrin.gif

    I'll doublecheck my files and make sure I copied everything over correctly. I'm a Linux Novice...just messing around with this for the hell of it.

    Rock out.

×