Insanatrix

Considering the scope of ArmA 3 and the visuals, I'm highly impressed. My performance viewpoints aside, the game is visually stunning to me compared to ArmA 2 and OA.

I wouldn't set them that high anyways, UDP should normally be set to 512 and TCP can be set anywhere from 512-1380, though I wouldn't exceed 768. The higher the latency, the more hops the packet generally has to take to reach it's destination and the more destination headers are tacked on to it and the greater risk of fragmentation and dropped packets. You want the packets to be large enough to contain the required data without having to send multiple packets to accomplish the same thing, but you don't want them so large that a dropped packet causes desync and lag. In fact, try setting NonGuaranteed to 512 and Guaranteed to 768 and see how it works for you with a 128 MaxMsgSend. Then start tuning it from there. I would venture to assume that MaxPacketSize exists for compatibility purpose and is used mostly for handshaking and not for actual game data packets, hence why you can set TCP and UDP sizes separately.

Yes!!!!!

This part here you might have wrong. I'm assuming that MaxPacketSize is basically the maximum size of a packet the engine will actually send, basically whatever your MTU is which in most cases with ethernet is 1500 and 1492 for PPPoE, but in this case it's limited to 1400, probably for compatibility purposes and to ensure that packets do not get fragmented during transit. MaxSizeGuaranteed and MaxSizeNonGuaranteed are defineing the actual size of your TCP and UDP packets respectively. So unless you set MaxSizeGuaranteed and MaxSizeNonGuaranteed to equal value's of MaxPacketSize, You would never actually be sending packets that are 1400 bytes. If you wanted to do a rough calculation at default value's, I would think , 128 x 30 = 3840 total messages sent per second and assuming a 50/50 ratio of TCP(Guaranteed) and UDP (NonGuaranteed) packets, split 3840 in half which is 1920, (512 x 1920) + (256 x 1920) = 1,474,560 / 8 = 184.320 KB/sec per player. Then you would do 184,320 * 48, assumed player count of 48, and you would get 8.847 MB/sec or 70.776 mbps. Also you have to remember that this is the theoretical maximum bandwidth you would see being used assuming that the server was pumping out 128 x 30 x 48 = 184,320 packets per second consistently. Using the same calculation above with regards to Blue1's test #2 I get, yes this is kind of pointless but I want to show the math, 2 * 256 = 512 / 2 = 256, (256 * 512) + (256 * 384) = 229,376 / 8 = 28,672 * 64 = 1,835,008 or 1.8 MB/sec or 14.68 mbps. So roughly around what he was seeing in terms of bandwidth usage, give or take. The ratio of TCP packets to UDP packets might have been closer to 75/25 or some arbitrary amount. It's all going to depend on the mission and what the server is calculating and sending out. I would be more apt to raise the packet sizes of both guaranteed and nongauranteed packets, closer to MaxPacketSize, before I would raise MaxMsgSend. For example, it's better to send less but larger packets than it is to send a huge amount of smaller ones. The only case where that might not be true would be in a situation where you have very bad packet loss. If you wanted to calculate a worst case scenario, just take the larger of the two packet sizes and use that. For example, 128 x 30 = 3840 * 512 = 1,966,080 / 8 = 245,760 kb/sec, 245,760 * 48 players = 11,796,480 or 11.8 MB/sec maximum total bandwidth. The key factors are going to be server simulation cycles or fps, maximum player count and maximum packet size.

I have to kind of agree with this. Initially it felt like I was getting more performance around Agia Marina. When they first introduced the the hash tables performance seemed to be a lot better and there was a lot less flickering and the LOD's seemed to switch much faster. Now the LOD's still switch slow and there's a lot more flickering and the performance has gotten better in area's where there aren't a lot of buildings, but it has gotten a little worse in area's like the airbase and Agia Marina.

Yeah I've got the flickering as well.

Nope, they reintroduced the hash maps for LOD loading. I got a significant performance improvement when they first implemented that and then a subsequent performance decrease when they took it out for testing purposes.

No more scripting in equipment via classnames would be nice.

I agree, wind can even play a factor in firefights at 200-300m depending on wind strength.

I made you reply and hit the post button? Like I said, Master of the Internet award....

Game set and Match, Bad Benson. I concede. You get the Master of the Internet award.

Like I said, it is what it is. And Dayz is not bad, I don't mean to insinuate that it is. It's just the primary focus seems to have shifted to it is all. Also, I don't believe the devs are dishonest, just that some statements have been dishonest I.E. like the livestream comments and things like the engine being multithreaded etc... Sure the engine is multithreaded for some parts, but the majority is not. Or that immense lag while looking out at the bay of Agia Marina or anywhere in that direction was because of the stream? Or every time there was heavy fire and a lot of AI action and movement the stream just magically bogged down like it seems to do any time you're not streaming? Fact is fact, I dunno what you want me to say. Just smile and say "uh huh" :)?

Yeah I know. Like I said though, having some answers would honestly be nice rather than the beating around the bush. Things like the livestreams and talking about how they got great performance on this system when you can see the bad performance plain as day is just dishonest, there's no other way to put it. Also just lying down and accepting things just invites more of the same. Having that attitude doesn't make you superior either. And yes I realize that my statement means that ArmA lost fair and square. It is what it is, Just didn't think BI would abandon their roots at the first sign of a cash cow is all. ---------- Post added at 14:14 ---------- Previous post was at 14:03 ---------- I made the most intelligent decision based on what little facts I had about the game. I used the recommended specs as a guideline, saw that I was well above them or equal to them and made my purchase. The fact that the developer recommended specs don't reflect the actual performance of the software has nothing to do with my intelligence. Sorry, I don't have ESP. Also I'm not questioning your intelligence, more your reasoning skills for making a decision based on your attitude and your said reasons for making the decision to purchase the game. They differ from mine, that's life. Life's binary, you can't go along with something without supporting it or defending it. You're saying it's ok, isn't that a defense against why it wouldn't be ok?

As long as there are people like you in this world with your attitude and in any great number, I don't hold much hope for the market making intelligent decisions or guiding any company along the right path. The market spoke anyways, it said DayZ. We're just the red headed stepchild now apparently.

Most of the issue's were with early SSD designs and just generally lower quality NAND flash memory. Nowadays SSD's last as long if not longer than mechanical drives during normal use. File servers that handle constant I/O 24/7 are the only types of systems that really need to worry.

I think the problem boils down to the fact that if you keep providing excuses for problems instead of fixing them, you will soon run out of excuses to cover the problems. We can sit here and excuse the performance issue's until we are blue in the face. We can find ways around them like dynamic AI spawning and just using less general entities until even that doesn't work and we're stuck on a map solo with 10 fps. We can optimize code till our fingers hurt. Until you fix the actual problem instead of trying to work around it and putting band aids on it constantly, you're just gonna be digging yourself into a hole. The fact is that while aspects of this game might be multithreaded, the only system I am aware of being multithreaded is the AI pathfinding and file operations, Everything else is single threaded. This is why CPU usage is atrocious. Why do you think that this has become a bigger issue with the RV engine as technology has progressed into parallel processing and multicore cpu's instead of 15ghz single core cpu behemoths? Because the engine is literally not written for multicore, even though it's spouted like the gospel that it is. I mean that's basically what Jay Crowe said during the livestream or Gamespot interview. This engine was written at a time where things like multicore cpu's were a thing of the future. The thing that agitates people is when you have someone say, "oh but the engine can handle up to 32 cores!" or "There's no performance issue's!" and you can look at your 8 core 8350 or your 4 core i7 and see such little usage, except on 1 core, and you can see impartial performance graphs done by independant reviewers that show even a GTX 690 with a 3980x can barely maintain a 40-50 fps average. Seriously, what hope does that even give the rest of us? Or how about during the livestreams everytime Zipper5 or one of the developers fired or any kind of event happened and the drastic slowdown in performance, even from just looking around there were large pauses and stutters and slowdowns that are common occurrences for me and a number of players I know even with beast systems. Then you have developer comments about how it was running great and it must have just been the stream. I'm kinda gullible, but I'm not completely stupid. When I see the same issue's, the same area's of performance problems on a developers system and then have them try to tell me that it's just the stream, ya I feel some dishonesty there. The fact that the issue feels like it's swept under the rug honestly just really doesn't help. Maybe it is, maybe it isn't. At the end of the day, it's the impression that's given. The problem is becoming more severe as time passes and as more things are tacked on to the engine and as technology gets farther away from the mentality of raw cpu speed and more into parallel processing. ArmA 3 feels like ArmA 2 did at launch, the same old problems that can only by fixed by cpu's with more power, It's just not gonna happen though. You're not gonna see cpu's breaking the 5ghz barrier any time soon, not like during ArmA 2's time where we started breaking past the 3ghz and then 4ghz later on. We're reaching a point where the advancements of technology are just not going to cover up the sheer design problems this engine has.

The problem is that higher specs has become a horizontal or diagonal measurement rather than a straight vertical measurement in terms of CPU performance. It's not about the ghz or raw speed as much as it's about the amount of cores and how efficiently you can use those cores. It seems that ArmA is still trying to follow a vertical, higher speed over more cores approach rather than taking into account how technology is moving away from single core and even dual core cpu's. With that in mind, I fully agree with Rockets statement that ArmA 3 supports less AI and less human players. It only takes 2+ players and a few AI squads for performance to start dropping dramatically. You say that ArmA 3 is better designed to do what ArmA 3 does, what exactly is that? Doesn't that require multiple players and multiple AI entities? I don't think ArmA is a scenic simulator where the point is to just walk around as a single entity and observe the landscape. I would say DayZ and ArmA 3 share the same fundamental and technical requirements, but on different levels. To say that ArmA 3 is better designed to do what ArmA 3 needs to do is something of a fallacy unless you consider it to be a scenic simulator where the number of simultaneous entities and players has no impact on the game.

AFAIK, they said that Java wouldn't be used in any of the vanilla content but they hoped to have it in for release.

Because all of the behavior FSM's reference SQF functions and operands for their operations. No, one specific instance that the AI fails at would not require a complete rewrite. How about the 100's of other instances? If you're going to change so much about the AI, possibly to the point that you would end up rewriting most if not all of the functions or FSM's that control them, wouldn't it be time better spent on just coding and optimizing anew rather than trying to tack everything on in a band aid type fashion and try to revise all of that code? Pathfinding really isn't the issue, and yes it is multithreaded. Stick 25-50-100 AI down and give them all waypoints to somewhere. First set them all to combat or aware behavior and monitor your performance. Next set them all to careless behavior and observe. Now is pathfinding really the issue, or is it the behavioral scripts that cause the most problems? When you set them to careless, you bypass all of the danger FSM's which make up almost all of the AI's behavioral routines. Now try tacking on scripts or functions to pick up weapons or to scavenge for items, or to react faster to threats or to be able to process multiple threats etc... and see what the overhead is like then. Sure, under the current system, simple things like turning speed could be fixed with a simple variable tweak. Other things though that would require more extensive scripting and for that scripting to be constantly evaluated per simulation step would require a new approach on how the AI behaviors are calculated. I don't foresee AI changing much unless the manner in which their behaviors are calculated changes. I don't think it has anything to do with DayZ, as much as it has to do with core engine faults that would have to be rewritten or rethought out to find a better way of handling them.

No, they suggested to rewrite the AI Behavior scripts from scratch. That's not the same as rewriting the engine from scratch. I can't say that I disagree. I think the largest hurdle would be writing the AI code native to the engine's code rather than through SQF functions and scripts. Unless they implement a multithreaded interpreter to handle the SQF scripting, you're always going to be stuck with the AI behaviors being single threaded along with all other scripts a mission or any addons may use. This affects all aspects of the AI's precision and abilities.

It probably would have, and I'm not trying to say it's the wrong decision. It does give you a sign of what to expect though with ArmA 3 in terms of engine performance. I'm hoping that over the years after ArmA 3's release, we will see a lot more functionality tacked on to the engine. You can tell by their statements that they really want to release something that is as bug-less as possible and has the core functionality that they want. I think that they just want to KISS it and release it basically. One thing BI has done well is supporting their products after release, that fact gives me hope. At the same time though, I didn't buy the game to wait 2-3 years to be able to fully experience it.

Kind of agree. If you listen to Jay's interview on the livestream, he remarks about how the engine was built in 2001 and how they didn't expect or plan for multicore processors to become so mainstream so quickly. The problem I have with that is that multi-core processors became mainstream in like 2006 or so. While they might not have foreseen it, there has been ample time since inception to adapt and make use of it considering we are halfway through 2013 and heading into 2014. The same goes for 64bit architecture. I find it odd that you would adopt Directx 11 as a standard and then allude to the fact that you don't want to embrace or include 64 bit because it would cut off potential customers. I don't think anyone is going to try and run ArmA 3 on an old pre-64bit Sempron or Celeron. Anymore everyone has a 64 bit processor. The only downside would be needing to run a 64 bit OS, but really why would you or who would want to run Windows 7 or Vista 32 if you have a 64 bit processor, and how is that any different from alienating Windows XP users by requiring Directx 11? I could see it happening with a pre built Dell or name brand manufacturer computer, other than that though I honestly don't know anyone who actively chose to run Windows 7 32 over 64 with a 64 bit processor. Both of those things heavily affect the ability to run large missions with large amounts of entities and large amounts of players. I don't want it to turn into a performance discussion, just wanted to comment based on those two E3 comments from developers.

He looks like he's been mainlining coffee and beer for the past couple of days ;)

I hope it's still in, it was kind of an interesting bit of future tech.

Yeah, I enjoyed the interview with Jay. Seeing the passion for the PC from him and the advantages to it was reaffirming. DayZ doesn't look bad, it looks like more focus was put into the technical aspects of it and getting it to operate how they need it to for the type of game that it is. Also Take on Mars definitely looks interesting.