Jump to content

chicogrande

Member
  • Content Count

    17
  • Joined

  • Last visited

    Never
  • Medals

Community Reputation

0 Neutral

About chicogrande

  • Rank
    Private First Class

core_pfieldgroups_3

  • Interests
    5 Inch Manatee

Contact Methods

  • Yahoo
    cannedparty
  1. chicogrande

    Co-op: group commands issue

    My buddies and I have been playing OFP Resistance v1.91 co-op at length lately and have noticed issues with the command interface. When I issue movement or target orders to "ALL" (by hitting "~" on the keyboard) the players ordered are not seeing the typical yellow square with target or movement orders. When I select the players individually (using F2 for player 2 for example). It works fine. We're playing on a 1.91 server, in Cadet mode. Is there a known issue with OFP 1.91 and issuing commands to a group of soldiers? It's rather annoying that if I want a group to move to a location I have to select each player and give move orders one by one. Thanks! cg
  2. chicogrande

    1.55: sockets + nat firewalls = no go

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">if you're running a ofp server behind nat you will need a port forward, doesn't matter if you're using direct play or sockets! if you have no portfw the join request will end on your router / nat-gateway! does the socket version uses any other ports that have to be forwarded?<span id='postcolor'> In the past with DirectPlay I forwarded UDP/TCP 2234 to the internal IP as well as the collection of DirectX ports and it worked just fine. So I am familiar with the need to port forward. You raise a good point though, are there are other ports used by the sockets version of the netcode? I could send you the results of the packet trace we did if you think that would be helpful. Again, it appears that the initial UDP request/receive works on port 2234, then there are many subsequent requests from the client to the server on several other ports. cg
  3. chicogrande

    1.55: sockets + nat firewalls = no go

    A friend and I attempted to get a 1.55 sockets based server going which exists behind a NAT firewall appliance (SonicWall SOHO2). My buddy attempted to connect over the Internet to no avail. We did some packet tracing and noticed that the initial UDP request to port 2234 was getting recoginized, but then subsequent requests were not being answered. Will the sockets based netcode work on a server which is running from behind a NAT firewall? I've been able to play in the past without issue with DirectPlay, NAT firewall and port-forwarding DirectX and port 2234 to the internal server. It would be dissapointing if the sockets based solution alienates those who may run a server behind a NAT firewall appliance. cg
  4. chicogrande

    1.46: frequent dedicated server crashes

    Suma, I just tested the new 1.47 beta server hotfix against the same test mission I was using to crash the server in 1.46. It would appear you have solved the "taking weapons from once manned vehicle" issue. Nice work!
  5. chicogrande

    All seems very quiet

    I know that personally I've decreased my OFP gameplay to nill since the discovery of a rather critical dedicated server issue with 1.46. I found it frustrating that a bug, which leads to the server ultimately crashing, that is so easy to replicate, went unnoticed during BIS testing. I've become a bit disenchanted with the game, and I'm sitting on my hands until I feel that they get these problems ironed out. I'll jack with this Global Operations game that's coming out and perhaps play some more Magic the Gathering Beta until they get it all square. cg
  6. chicogrande

    1.46: frequent dedicated server crashes

    Please access the testing mission at: http://24.219.228.176/ofp/146_crash_test_no_hind.Intro.pbo Mission contains one ammo truck loaded with a LAW and LAW ammo, and one West Officer unit. No Hind. The instructions are contained in the briefing and hint pop-ups. To restate: 1. Get in the truck 2. Drive a bit or just hop out 3. Grab a LAW Launcher from the truck 4. Crash cg
  7. chicogrande

    1.46: frequent dedicated server crashes

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">As I wrote, there are two most common issues: - Most common crash is related to title effect and sound which is played when taking weapons, magazines, reloading fuel or similiar actions - Second most common crash is related to getting into vehicle cargo space. Exact details are not known yet. First one is what you describe here, it is in no way related to Hind and it is not a new issue in 1.45. Second one is "cargo issue" which is almost certainly isolated to Hind cargo inconsistency. <span id='postcolor'> For the record, I have done the following: 1. Created a small mission with an ammo truck with cargo loaded with LAWLauncher and LAW ammo. No Hind is present. 2. Tested the sample mission on a re-install of both server and client to patch level 1.42. Results: The server did NOT crash I also tested the same mission, following my original "crash" steps of get in vehicle, move, get out, take LAW from vehicle on 1.46. Crash. Can you please clarify what you mean by the statement that no new issues have been introduced since 1.42, aside from the Hind cargo issue, and the "get in as cargo" issue? This clearly looks like a new issue for version 1.45-1.46 as it relates to accessing items from vehicle cargo. From what I'm seeing, 1.42 is not having nearly the same amount of problems that 1.46 is having. I would go as far as to say that 1.42 is a more stable dedicated server platform than 1.46 for this reason alone. I would advise that server admins avoid missions where vehicles are loaded with cargo for player usage. My goal is not to be overally critical of your judgement, but to ensure that you are truly seeing the issue at hand. From what I've been able to test, the issue is far larger than anything related to having a Hind in a mission, and does not rear it's ugly head in version 1.42. I'll reluctantly patch back up to 1.46 and await a dedicated server that operates without issue. Thanks. cg
  8. chicogrande

    1.46: frequent dedicated server crashes

    Thanks Suchey for bringing home my point. I'd like to comment on Suma's last post: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Exact details are known: Different cargo space definition for Hind helicopter is what is causing trouble.<span id='postcolor'> I disagree. I've been able to crash the server using the steps I've indicated above with any number of vehicles where... 1. The vehicle has cargo spaces with ammo/weapons 2. As the player I take weapons 3. As the player I drive the vehicle 4. As the player I disembark and select another weapon/ammo from vehicle. 5. Crash. I do not believe this is an isolated Hind issue as you indicate in your last post, but a general cargo issue with any number of vehicles. Time permitting, I plan on rolling my server/client install back to 1.42 and trying to break it. cg
  9. chicogrande

    1.46: frequent dedicated server crashes

    All I do know is that I can now make the 1.46 dedicated server crash like clockwork by: 1. Taking a LAW Launcher from the cargo area of a St. Truck 2. Getting in the truck as a driver 3. Driving a few yards 4. Getting out of the truck 5. Taking a LAW Rocket from the cargo area of the St. Truck Crashes it every time. </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE"> Let me repeat: we have no evidence of any crash opportunity introduced in 1.45 or 1.46. I cannot say there is no such thing, but no crash file we received showed us any new bug that would be introduced in 1.45 or 1.46. In other words, all crashes we received from 1.45 or 1.46 would happen in 1.42 as well. <span id='postcolor'> I have to think that in version 1.42 I often found myself taking items from cargo areas, manning vehicles, then grabbing items again from the cargo area without crashing. Perhaps it's time to find out... hmm... cg
  10. chicogrande

    1.46: frequent dedicated server crashes

    Thank you for your response Suma. It would appear that there are several major issues that the BIS team is working. Some questions: 1. Is it safe to say these issues have been introduced with the introduction of the 1.45 patchlevel? 2. Until a fix for these major issues is reached what suggestion do you have for server admins? Roll-back to 1.42? Don't use missions with vehicles or vehicle scripting in them? cg
  11. chicogrande

    1.46: frequent dedicated server crashes

    Whew! Glad I'm not the only one going through this agony. I sent along the files as everyone suggested. cg
  12. Since upgrading to 1.45, and now 1.46, I've noticed more frequent server crashes than ever before. Looking at the Flashpoint.rpt log reveals: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ===================================================================== == C:\Program Files\Codemasters\OperationFlashpoint\OFP_Server.exe ===================================================================== Exe version: Mon Mar 04 11:29:20 2002 file: Â Â cur_mp world: Â Â eden campaign: battle: Â mission: Â Exception code: C0000005 ACCESS_VIOLATION Version 1.46 Fault address: Â 00592EB1 01:00191EB1 C:\Program Files\Codemasters\OperationFlashpoint\OFP_Server.exe Prev. code bytes: 8B 70 08 8D 7A 08 75 05 BF C8 8D 6A 00 D9 45 E4 Fault code bytes: 8B 06 51 51 D9 5C 24 04 8B CE D9 45 E0 D9 1C 24 Registers: EAX:10026130 EBX:006AEDA8 ECX:0000001A EDX:13B581F0 ESI:00000000 EDI:13B581F8 CS:EIP:001B:00592EB1 SS:ESP:0023:0012F568 Â EBP:0012F59C DS:0023 Â ES:0023 Â FS:0038 Â GS:0000 Flags:00010206 ======================================================= <span id='postcolor'> This happens with not just user-made missions, but also BIS provided MP missions. Again, I've only noticed hard-core server crashes like this since 1.45. Any ideas BIS faithful? I've read some of the posts regarding tweaking MaxMsgSend, and other bandwidth related config. I've tried this, as well as the defaults and this crash happens regardless, usually when the number of connected users is > 1. Platform is Win2k, 798MB ram, PIII 550. Not ideal, but it worked great before 1.45. cg
  13. chicogrande

    Compare of to counter-strike

    OFP is nothing like Counter-Strike, save for some of the weapons that are common to both games (AK47 for example). Counter-Strike is a mod to Half-Life, which is a true shooter game. Very fast paced, some, but little "military" type strategy. You complete some basic objectives, like defusing a bomb, but the game is still VERY focused on "frags". In the end, the one with the most kills is seen as the winner. If you like Quake style gameplay with "realistic" weapons and settings, then you like Counter-Strike. OFP is more of a military simulator with some first-person-shooter elements. The combat is more realistic and slower paced. You cannot jump like in Counter-Strike, but you can lie down and crawl. Multi-player has several flavors, although co-op is the most unique. You work together to complete a task or tasks. Less focus on fragging, and more on the task at hand and staying alive. Although you can play Deathmatch in OFP, and CTF style games, I feel it's the Co-op multiplay that sets it apart from games like Counter-Strike. As for your firewall problems, open up some ports. They are well documented on forums such as these. Unless, you don't have permissions from your firewall admin. cg
  14. chicogrande

    Logs in OFP

    Points taken. To catch potential cheaters, logs would be invaluable. I see your point now. Having logs would assist server admins in having insights into what is going on day-to-day. Yes, I am basing my opinions on stats based on games played in the past, but I've seen their effect on gameplay once introduced and publicized. More emphasis is placed on achieving statisical glory than on the tasks at hand. People will be Alt-Tabing to their browser to see if they've gone up a percentage and surpassed a rival in M16 kills. Personally, I think this defeats what makes OFP great, in that you're not out for there for stats, but to survive and achieve some group goal. If stats can be used creatively to promote clan/team play, I'm for them. Having logs would perhaps lead to some of this creativity mentioned.
  15. chicogrande

    Logs in OFP

    Despite the risk of going against popular opinion, in the priorities of ehancements, I'd place stat logging towards the bottom. In team based MP games I've played like Counter-Strike viewable logs decrease emphasis on teamplay and focus more on attaining personal glory. The game eventually degrades to the point where everyone is concentrating on how many headshots they can get as opposed to defusing the bomb, saving hostages, etc (aka: "stat whores"). Why not focus the "re-coding" on such efforts as NOT using DirectPlay as a multiplayer platform as opposed to logging headshots, LAW hits, etc.? Then we could actually host the servers on Linux? In summary, I'm sure we'll see logs, but I'm wary of their impact on the success of the very new OFP online gaming world. Just my thoughts. cg
×