oktane

While I sympathize, that's not really a roadblock. I assume you are talking about client side only, non-required addons. You can turn on sig checks TODAY, and if you have a few addons with no keys, sign them yourself and offer them for download to your users. It is acceptable to inconvenience just a few people with the unsigned mod you speak of, compared to the amount of players and good impressions you could be making with a stable and consistently running server. :D The first MOTD line is visible to clients, if they get kicked or not. So you can put info/url/help in there. (at least that was the case with A2, haven't checked with OA yet, hopefully the same)

This is an awesome idea/implementation guys! Very crafty. But there are other reasons to turn on signature checks.. namely stability and cheating. (the latter less of an issue if you have an admin 24/7) With sigchecks on, the server doesn't crash hardly ever, even when full. With it off, it does. And it's due to crummy addons with errors, outdated addons, or ones that are ment to also run on the server side. You won't be able to control your clients, what they bring on your server without kicking sigchecks. They can come on with addons that modify their guns to have no recoil and bullets that do more damage, and other subtle things and you wouldn't even notice it unless they put it right in your face. Public servers without properly working sigchecks (ie, kick on bad sig) tend to ruin the online experience (esp when lacking admins), even ruining it for the people that don't run any addons. The result is greifers with cheats, lots of crashing, popup errors, etc. When OA first came out, I was reminded of how really bad it can be, with people joining with all kinds of popup-error and CTD causing crap. IMO, now is the time to turn it on, and let it kick like it's supposed to. And build up a group of 'regulars' to your server while you can. We've had it on for 3 weeks, the server has still been full for 3 weeks, day and night. It is not that hard to gather up lists of mp-friendly addons that are approved by adding their key to the server. All kinds of people have messed up or edited stock game files. Letting those folks on is what causes crashes. It's the only way to maintain client-server consistency and a good experience for players. Even with 10 admins and no greifers, you're still going to have people with inadvertently corrupted data that can crash your players and server out. Is that a worthy tradeoff? I'll say again, as far as I can tell, (likely due to the lack of mods) sigchecks has no affect on player count at this time. Just remember, without sigchecks, people can do anything - absolutely anything to their game that they want and still join your server. I hope non-sigcheck admins never host PvP where people are a bit competitive, then it gets really ugly! Best to build a dam and poke holes, not the other way around. :D

Look, what makes more sense? A developer spending most of his time in a forum, trying to extrapolate information and issues intertwined in complaints, opinions and various nonsense. And there is a lot of nonsense. (you have seen this in person) A developer goes to a bug tracker, to fix a bug which has clear and direct repro steps. He now has more time to address other bugs. If more information is needed, it is simple to ask and track the status all on a single ticket dedicated to the issue, not 15 scattered forum threads. There are helpful people around like Dwarden that end up filling the 'in-between' of getting issues from the forums to the CIT, when they exist. In most cases, the CIT is a professionally-maintained (by volunteers like kju) place where bugs go to get fixed with the least amount of drama, wasted time, etc. There isn't a 'change in policy' that you are reading into here, Dwarden is just reminding everyone that the CIT is where most bugs get fixed, and that is how it has been for many, many months now. The forum is a waste of time that can be better spent on the issues themselves. Contrary to your argument, it is not hard to fill out a bug report, many examples are given. (please see this simple page: http://dev-heaven.net/projects/cis/wiki) Forum is okay for chatting, opinions, etc. But not ideal for development issues. It's a clear matter of efficiency and accuracy. CIT tickets usually don't have trolls, complaining, scattered topics, etc. Sure you can use the forum because it's easy and you wouldn't like to learn something new right now. But that isn't usually how work gets done. This is indeed work for them, and if you were working, I trust you would expect some kind of standards in your working environment. ;) Try to think of it from their perspective please. Posting issues to the forum actually does them a small disservice, as now you've required someone else to grok your issue and make a proper CIT ticket of it anyways, and it may not be how you originally described due to a misunderstanding.. and it's missing repro missions, etc. Also: Not everyone is suited to be a QA Tester and bug reporter. It takes work, and you don't get paid. And it isn't expected either, nobody is forcing anyone to run the betas. They are for testing, feedback and bug reporting of the game engine on a larger pool of testers. But if you wish to use it and not report bugs, that's okay too. But don't force the simplistic requirements on those that want to do the work, nor should you feel wronged by the developers for wanting to use an efficient system for their ongoing development. (sounds a bit selfish, or self centered, no?) If you do report bugs, it is expected they conform to some very simple requirements, it isn't huge deal like it's been made out to be here. I doubt that the devs will stop reading occasional forum posts. When the CIT started, they didn't, why would they now? But if they did, I honestly wouldn't blame them one bit. (we already discussed why in PM) And remember, since the CIT was created, various people have filled the gap between the CIT and those on the forums that are unable/unwilling to take the time to make tickets. Cheers PS: Be sure to make the distinction between the Bug/Feature tracker and 'troubleshooting', they are not the same. The CIT deals with things that are wrong with the game that affect everyone in most cases, whereas the troubleshooting forum can be user-related configuration issues, users helping users, etc. Real bugs are normally very complicated, and require a lot of data for the developer to reproduce. If a person has not been a QA tester before, they have to learn a bit to become one. It isn't as simple as reporting a problem in a forum post, it is almost never that simple. And the forum gives people a 'false hope' of their problem being recified, since so many people are posting about xyz issue, but it is not organized and there is usually missing information the dev's require to rectify the issue quickly. This is another reason for the dedicated bug testers that adhere to the requirements and post clear issues with the required information, without back and forth requests between people that are not acclimated to QA testing or game development. Try to imagine a person quality checking your work at whatever your day to day profession is, I assume you would want him to at least know what your job entails before he goes telling you how you're doing it wrong, right?

Guys.. mee-toos, in most cases, mean nothing in the forum. There is an issue tracker, BIS has repeatedly mentioned that it considers the highest voted feature requests. See here, and vote: http://dev-heaven.net/issues/show/3718 Note that ticket says 'bloom and blur' but read it as 'provide separate options' like Flash Thunder suggested and Maruk hinted at. VOTE

I did not imply you were using a script, I just mentioned that that is an avenue that can create non addOns=[] sanitychecked objects that would be invisible to clients that didn't have it. (they should get a popup error once however) While not ideal to create OA-only suited missions with a A2+OA dev enviroment (ie your map editor), it does serve to demonstrate a big issue if the game is no longer kicking players based on certain missing content. That may be a huge problem. I think it is due to the config overrides as others have mentioned. I am guessing the common folder contains updated data for the old units in A2, via partial classes which inherit the original A2 addons and override them with the new features. In Common\tracked.pbo, there exists a class patch for CATracked which has no units in it: D:\Arma2\!Configs\OA_Common_Extracted\tracked\config.cpp 00416: class CfgPatches 00417: { 00418: class CATracked 00419: { 00420: units[] = {}; 00421: weapons[] = {}; 00422: requiredVersion = 1.02; 00423: requiredAddons[] = {"CAData","CACharacters","CACharacters2","CAWeapons","CASounds"}; Which may explain why OA-Only clients are able to get in without errors, but then have invisible objects? More knowledgeable people would know if that's relevant. (but a lot don't visit the BIF anymore) There are no CATracked classes in OA proper, they are all appended with CATracked_E_Classname. There are no references to BMP2_CDF in OA or Common at all, it only exists in stock ArmA2 addons. In any case, since you've been around so long you should know the BIF is not the place for serious bugs amidst all the noise, that's what the CIT is for. You can wait and if by chance a BIS dev sees this, he'll likely tell you the same.. suggest to make a CIT bug for it. :) (doubt? do an advanced search Keyword(s): CIT ; Posts Made By: Dwarden) If it is a reproducible bug from a sanity checked environment, it will likely be taken care of by BIS very quickly and the result contained within the upcoming beta patches if possible. http://dev-heaven.net/projects/cis/wiki It sounds pretty serious at least. Cheers

Yeah that shouldn't work. The client should be kicked off. Terox, are you sure you didn't edit the mission.sqm in a text editor instead of the in game editor? When you save the mission out with the regular editor, it should see what external dependencies are required and write them out to addOns[]={} in the mission.sqm. In other words, OA-only clients should not be able to connect to servers running maps that use A2 addons, they should be kicked off. There shouldn't be invisible objects, that should only happen if: The mission.sqm was edited by hand, and the dependencies were not added to addOns[]. A unit is created by the scripting engine, and that unit's class is not listed in mission.sqm:addOns[] Some bug? This whole thing is a big mess because: The mods and modfolders the server started up with may have NO IMPACT if a client will be able to join or not. For example, a server can have some server-side utility addons loaded, like armaLib or DAC which have zero impact on clients. Because of the above, no silly indicator should be showing anything of the sort, its misleading to clients. It's harking back to the OFP -equalmodrequired days. What does matter, is if the server is using classes on the map currently being played. If a client does not have those classes, he should be kicked. (and this is how it normally works) But instead of BIS adding a gamespy query variable that lists the addons currently in use by the mission, they list the addons that the server started up with (which is meaningless, as explained above).

Guys, a few notes: There have been reports of servers that run combined OA + A2, or other mod folders as showing up with a red question mark in the server list to OA only clients. http://forums.bistudio.com/showthread.php?t=102169&highlight=red+question+mark Think of the question mark is a software indicator of if your client has the same addons as the server. If it's a question mark, that means the client doesn't match and doesn't know if it will work, you'll just have to try connecting. Since I'd expect A2 vets to ignore the bogus indicator, as they always have, (with sig checks, it would also sometimes appear red even though everything was fine) I have moved the old ArmA2\Addons and ArmA2\dta folders into a new modfolder called @ArmA2, and by doing that my server has become 'OA Standalone'. I don't recommend you do this, you won't be able to patch your ArmA2 unless you revert it back to normal. This way, new OA standalone folks (most new to ArmA2) will see a nice inviting green indicator, and the A2 and A2+OA guys will just have to figure it out. Since running combined arms will segregate the MP community, not allowing OA only people to join, it isn't a good idea for public servers. (and for some special private event that requires A2 addons, we just load up our -mod=@ArmA2 modfolder) Hopefully BIS will provide some kind of idea or fix for some of these issues like the indicator. The addons loaded on the server are really irrelevant, it's whats in use by the mission running that is important (mission.sqm addOns[]={}) and determines whether the client is kicked.

And this would prevent anyone with OA-Only from joining, thereby alienating all of the new players. If you wish to do this, you would essentially limit the player pool back to the 'old' arma2 pool, which was pretty low a month ago. So it's your own choice if you want to block out all the new people. (more people for us OA-Only servers!) I doubt Xeno will assist in providing something that ultimately segregates the MP community. Xeno, what were the issues that caused the player count to be lowered to 30, too much lag? What do you think has changed in OA? I was looking for some technical discussion about it on the DH waves, but there was none. :)

First part: 'Soften the scene', the blur that most people dislike (at low FPS mostly) is the blur when you move the gun or view in first person. It doesn't soften/blur anything when you aren't moving the view. Just mentioning that because you may have it confused with another shader which adds a small smoothing AA-like effect to the screen no matter the movement. Second: If it hasn't been reported already, please make a CIT ticket for it, that's where things get fixed! :)

You can either omit the -cfg=basic.cfg param, or get rid of the bandwidth settings by commenting them out in basic.cfg, and the problem disappears. (the freeze issue at base only) (EDIT: The issue persists with dropped boxes?!)

On the OA front: In game VOIP is really improved, no more dropping out, but there are still huge glaring issues that prevent it from being used. Like players able to be heard by some but not all users. (yes, channel was global or side, still no bueno) Didn't expect much, was surprised at improvements, but in the end still a let down. :(

You know about the issue caused by server admins using old arma2 bandwidth basic.cfg settings right? When clients try to open the box, they freeze. If BE is enabled, it will kick them off because they are frozen. This was reported by alef in the DH Wave chatbox.

Thanks for the East versions! Probably already reported, but the ammo boxes can't be loaded into the HQ's or Choppers. (2.16 East OA) If you want I can make a CIT issue for it.

Mosh, 1 was determined to be the best for dedicated servers, right? BigBear, I think all these changes for the client threading/studdering are contaiminating the dedicated server, since they share the same codebase. For example, the dedicated server doesn't appear to use more than one core anymore. :(

Hopefully this isn't a thread for complaining and me-too's, ideally it's for solutions. As I explained, people have varying monitors and it looks different, sometimes not as BIS intended. The best thing they can do is provide an option, which they have agreed with, what more do you want? Hopefully it will show up in a beta patch down the road. Until then, you're welcome to learn how the game works and modify it to your liking, as many others here have, or even use the Very Low setting for now.

It doesn't matter! :) As long as it wasn't called A2TS to confuse everyone between the old version Blackwater made and may still develop vs the new version that Nou and team has made. It can mean whatever you like it to, like so: Advanced Carrot & Rodent Eliminator :p To add something serious to this post, OA has implemented one way, outbound communication to other applications via UDP. It doesn't touch jay's armalib, but it's 'half' of the equation at least. Hopefully BIS will add the other half someday and make Jay's life a lot easier, not spending hours looking at assembly code. :D Until then, armaLib will still be required unfortunately, afaik. See here: http://dev-heaven.net/issues/9436

Thank you. I'm sure you understand the limitations of your own engine, being able to load and activate the shader cache file.. What I mean is only ONE can be loaded, the last one loaded overrides all others. This is what drives me crazy, as you can see in this post where I try to explain my issue as the maker of such shader mods, to people that want many options: http://forums.bistudio.com/showpost.php?p=1663840&postcount=129 Please do make my mod useless, I will forever be in debt and can spend time on better things. :D

And I should explain, what I mean by confusing is that because of the way the mod works, it requires: Modified shader files BIS Whole game config.cpp, normally in dta/bin.pbo, without it, it will not load the modded shader. So for each of those 'possibily disabled shaders', I need to make a 'matrix', since I can only have ONE noBlur pbo&modified shader. (All of teh shaders are stored in ONE file, BIS's shdc file, and whichever pbo is loaded last is what the game will use. So you see I have to have a 'matrix' of pbo's, one for each possible configuration.. Pbo with -rotBlur, -radialBlur, -Glow, -Heat Pbo with -rotBlur, +radialBlur, +Glow, +Heat Pbo with +rotBlur, -radialBlur, -Glow, +Heat Etc, the list goes on. There are 256 combinations in all, if there were 4 options. Remember, we cant do like the 'proper' mods and only put PBO's for features we want to change. With shaders, the whole SHDC file is overrode, and the last one loaded overwrites all others. You see now why this is a mess. To compute the number of PBO files needed, take the number of options (n) and multiply it by itself n times. In the above example of four possible shader disables: 4 * 4 * 4 * 4 = 256 ---------- Post added at 10:20 PM ---------- Previous post was at 10:17 PM ---------- That's only 27 possible PBO files... :D ---------- Post added at 10:23 PM ---------- Previous post was at 10:20 PM ---------- Read the instructions mate. ;) If you didn't use Post Processing before, you aren't going to gain FPS. The only way to see the effect of the mod is to turn PP on. (I recommend Low) When it's on low and the mod is enabled, there won't be blurring when you move your gun. ---------- Post added at 10:27 PM ---------- Previous post was at 10:23 PM ---------- What is this issue that you speak of? Lots of people use JPG face files. Even me! +1 for VHEMT btw.

Yeah but if enough people want it, I guess it can be done. But then it's somewhat confusing. I'd have to think of a better way to lay it out so the user can choose what he wants. This is especially relevant with OA, which adds a few more shaders, people may not want blur and glow at all, but do want SSAO. I wish they would just let us disable them individually in the INI. (if they don't want to make a gui for it) That would solve the whole can of worms.

What he said! (Although I am not on the ACE dev team! ;))

I don't have it yet guys. As stated all over the first post and readme, you aren't supposed to use the noBlur with the wrong version of ArmA. Especially don't use it if you play online. Very Low PP setting disables rotBlur and Glow in OA.

I don't have OA yet, but please, looking forward to you putting my noBlur out of business so to say, all that is needed is ini options(on/off) for: Bare minimum: rotBlur shader (biggest issue, was this improved in OA? If not, any kind of way to disable just it, would be nice.) This is the #1 offender! Good additions, that people always ask for: (see discussion sources below) glow shader (some people have issue with this, perhaps on bad contrast monitors) However, more people LOVE IT. Which is why it breaks my heart that your 'Very Low' setting disables it, tossing the baby out with the bath water. LSD or Tired(?) shader (provides 'tired distortion', the issue is that it looks like crap when it turns on suddenly, it looks like it interpolates the framebuffer to 1/2 size. This is most noticable when you have the rotBlur disabled, granted you didn't design it for that situation! ) radialBlur shader (provides radial screen-edge blur when running, most inconsequential) Due to the ambiguities of people's complaints, it is a bit confusing to know what someone means by 'blur'. When I say blur, I usually say rotBlur, because I mean that specific, atrocious fullscreen blur shader. :p I don't think people are complaining about 'being shot at' blur, explosion blur, any of that. Very few complain about the tired blur, and I actually find it useful. However, I use ACE and don't sprint. Other people don't have the same gameplay tactics. When the rotBlur is disabled, you can easily see the Tired shader kick on and off, it looks like 'lower' resolution all of a sudden, I think that is the complaint from all. Discussions: http://dev-heaven.net/issues/5932 (rotBlur bug) http://dev-heaven.net/issues/show/3718 (feature req for bloom + blur) http://forums.bistudio.com/showthread.php?t=97853 (noBlur replacement shader thread) http://forums.bistudio.com/showthread.php?t=90414 (older noBlur thread, used pboprefix to override) Thank you Maruk! Congrats on OA release, have a beer (and many more). I hope you guys have developer release party hosted by BIS! (I have good/hazy memories of previous game release parties myself)

The issue is: If you try to host Domination on a dedicated 1.07 (new patch) server, without @CBA (or without ACE, which uses CBA), it will not load. Since I don't know what you're doing, it's different for each case. If you edit any custom versions of domination, you'll want to make sure that you either: Resave them in the editor after installing 1.07 (easiest, recommended) OR Manually edit the mission.sqm (in the top parts, in both addOns and addOnsAuto sections): replace this: "warfare2", with this: "warfare2", "warfare2vehicles", OR Wait for Xeno or BIS to release a fix. If you just want to play local multiplayer or lan, there is nothing stopping you. If you are a server admin that runs a dedicated server: Download the unofficial hotfix mission pack I made OR Fix the issue yourself (see above) OR wait for Xeno or BIS to fix it BIS's only obligation is to their own missions, they probably won't fix it. Or if they do, they'll probably resave their own missions. (if they are even affected) :D They don't guarantee mission backwards compatibility, it's a luxury.

Yep, sure you can. I didn't know that's how that app worked. I'll add a dummy addons folder to the archive, thanks! Edit: Uploaded!