tacticalnuggets

This is exactly what I mean. When A player first connects to a game, the data does not need to get to his client as fast as possible and cause desynch for everyone. Just a gradual guaranteed synch would be good.

TCP is used in many games. Its that UDP is the favorite for FPS's because its so much faster. However, for things like a JIP player joining and lots of data being transferred all at once, I'm pretty sure its causing the red chain headache. The reason for that is every machine demands information and a cascade ensues throughout the network. Something like (for a 50 player server) a 50 man tug of war with a rock in the middle. TCP can resolve this much more quickly because its not about updating the information as fast as possible while not worrying about synchronization so much, but about making a synchronization over the network that happens robustly and at whatever pace it needs. I'm sure they could create a better layer over the UDP to simulate this, but why re-invent the wheel if you know what I mean.

Actually, the thread isn't too far off, but I think the author is getting ahead of himself. If you want to do anything to fix this games popularity, its to fix the netcode which gives performance drops in MP without any AI running on your client! My hunch from all the desynch issues and fps drops is the fact the game tries to organize a UDP style system. The problem with UDP is its a raw packet broadcast, and makes no guarantees about order or packet loss by itself. Instead, the netcode has to work extra hard to maintain this over the entire MP session network, and thus makes machines struggle to keep up.

Disagree 100%. If there is anything thats guaranteed to boost online numbers its having automatic addon downloading. By whatever means necessary. Everything else is just the quality of the game. But not being able to play it is the worse bottleneck of all...

I believe that the problem stems from the fact that global variables are basically just giant memory spaces floating around for every hacker to get his grubby little hands on. I have never attempted to do anything malicious with arma2. But from pvp mission scripting experience, the vulnerabilities are very obvious.

Why would the server host the mods it needs? Its hosted from a different source, silly...

I cant tell people enough how epicly important it is for this to be in ArmA3. Without it the game will spiral into a state of locked servers and confusion regarding joining a server. With this one feature I almost feel like I could guarantee a 50% increase in late sales compared to arma2. Of course no one could make that prediction absolutely, but the universal reason I hear from people online who dont like arma2 tends to be the inability to join servers online, keeping their game up to date, and never having the right mods. At first its always the bugs, but once those get fixed what are peoples excuses for not playing arma2? Its that online community screaming that they cant join a server in arma2 for whatever reason. Guy buys game, notices MP is barely useable for the casual player. Guy tells 5 of his friends that there is no point in purchasing the game. This is the modern world, adapt to it.

I was reminding rangerPL that its not just mainstream shooters that share this problem with non-skill related advantages. Its pretty wide spread for a variety of reasons.

RangerPL, let me remind you that in ArmA2 its simply about who has the better machine and headphones.

I've heard some information that public setVariable is not working correctly for JIP. Is this true and if so, how exactly is the bug appearing? For instance: - JIP trying to getVariable from a variable that was broadcasted from client - JIP trying to getvariable from a variable that was broadcasted from server - Client trying to getVariable from a variable that was broadcasted from JIPs All important info. Also, is this related to JIPs failing to register on clients that are already connected to server (something about JIP being to far away from client player ingame). My suspicion is if the JIP person fails to register on the client, then the client will not re-broadcast its public setVariables automatically for the JIP. And because the JIP person failed to register, the client can not also obviously get the JIP persons data and public setVariables. The server in this mix, however, does not have any issues, and the JIP client therefor does not have any issues getting public setVariables done by the server. Please correct me where I am wrong.

When people make excuses for stupidity it sickens me, especially when 22 navy seals died. Chinooks do not transport 22 seals into a dangerous area like this unless the orders originated from an IDIOT. Mistakes like this are inexcusable.

Well apparently I do. ---------- Post added at 11:45 PM ---------- Previous post was at 11:44 PM ---------- Put your emotions aside and see into this bullshit. A chinook helicopter... CHINOOK. WITH 22 navy seals!

I cant believe, out of ALL the military junkies in this forum, that not many of you smell something wrong with this? A chinook full of 22 seals, flying low to the ground, into battle? Who in their right mind would attempt to seriously do this in even an arma2 mission? wake the fuck up :j:

The problem with that strategy is it eliminates the economy already present on that island. Thats why there are problems and solutions involving nuclear warfare.

Some kind of biological weapons or gas weapons would be a sweet edition to arma3. Using the volumetric clouds you could model these weapons to cause bad things for your soldier ranging from slow dps, to crippling your soldier to a walking pace.

thread officially hijacked LOL

I ment dps on you. Like, you getting damaged slowly over time. Acronyms are evil, i'm not using them anymore.

*this event has already expired*

New pvp game mode beta released. Template and pack to come soon. Learn about it at armaholic: http://www.armaholic.com/page.php?id=14721 v0.96 fixed - Invincibility problem solved. v0.97 Fixed - Squad leader kit still had obsolete FBP deploy ability Added - New functions SpawnAtomic and ExecAtomic for the PublicCodeSystem; can utilize for atomicity Improved - Reliability now improved by using SpawnAtomic and ExecAtomic in place of old atomicity system v0.98 Changed - Reduced flag zone capture time to 60 seconds, and set expiration warning time to 60 seconds. (warning time and capture appear the same, but expiration just needs a friendly presence in the zone. Changed - Removed the randomized flag tag (was a debatable feature) and now enemy flag zone is visible on map just as yours is. Improved - MP performance now improved, less public variable usage when visual state is the same. Improved - Internal system for scanning flag zones is now more reliable as well, and redeploying in the same spot super fast without redeploy delay (was sort of impossible before, but now absolutely impossible) will not keep the flag from collapsing. v0.99 Fixed - Player kits had a few possible bugs/old pieces of code running Added - New script initialization module called ClientBuildSystem_InitBuildSystem. This allows you to use the raw build menus without the actual weapon kits, but still using the building list format. This is sort of an advance thing to work with, and not fully tested. Added - When you enter the enemy base you get a 10 second warning that you will die if you dont leave the enemy base. Improved - Merged another script into a thread to reduce script usage and increase reliability a tad (these things usually are not problems, and only theoretically become issues).

Most of these people have the talent to make their own game. We will purchase arma3 because people have dedicated their careers to developing it. May you please elaborate more on why you think moders need to put even more effort in upgrading the game?

I dont like some weapons in the game but I dont mind them being there for people to use. LOL dps = damage per second which is a rate

ATF has been updated to v0.99 on the armaholic forums

Its possible that certain objects are bugged while some are not. I think that the way synchronization is coded may require detection of a new presence on the machine that pv'd it. Basically speaking, PV's could be stored on the machine it was used locally. Then when a new machine enters that pool, its up to each individual machine to detect it and re-broadcast it. With this set up desync would certainly be more probable! Just as we see desync always being an annoying issue in a2. Perhaps certain informations act just like public variables in this manner, and cause desync when a high player number is reached. Now, make sure you read what i'm about to say: What if since the addition of public variable eventhandlers this was fixed for regular PV, but the setVariable PV never got fixed for all the objects?

This is what I think to be the important question. Perhaps i'm just misreading him, but he is saying public setVariables are not reaching jips in certain situations.

here are the links sickboy. I have no issues with setVariable and JIP, but they are all on done on the server for me, so my experience is a bit inconclusive. http://dev-heaven.net/issues/18228 http://dev-heaven.net/issues/19213 http://dev-heaven.net/issues/21979 forgot this as well http://pastebin.com/7wZrqj6n I asked VM when this conversation took place but i have not gotten a reply back yet.