oktane

Here's another, there was a bug in the way version numbers were being detected by the automatic script, needed to retain leading zeros. (the true version is 1.54.74.94, but BIS uses 1.54.74094) Also it has the modfolder logo issue solved by BIS here: http://dev-heaven.net/issues/14039 http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_for_beta_74094.7z Remember before in this thread we discussed why it would be complicated..the shaders can only be overriden once (whatever was done last is what wins) so more noBlur's would have to be made and signed for every possible combination of customization. And then whatever magical tool would have to be created to make it easy for someone to choose what they want and install it. :/ I had it like that before and quite a few people didn't understand that they had to do this non traditional step to make it work (run one of the config batch files).

For newest beta: http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_for_beta_73968.7z And BIS fixed my mod logo bug! So when I get time, I'll fix that error. Puffy clouds are optional, they are 3d particles, created by the Weather module. They reflect light from the ground. The reflective tape is also intentional, if you see a side of a firetruck which uses reflective tape for the lettering, it has the same effect with a bright light source. It does haze around the edges. It's a little overdone, but there are just a few things that it affects and normally I think it looks good. Removing bloom totally flattens the whole scene at certain times of day, it removes all reflective properties from all objects. The main reason I don't do it though, is because then it becomes complicated.

Can you remove any personal differences you seem to have had in the past (with the admins?) and take this from a fresh perspective? kju does this to *many* tickets, he isn't singling you out. He's done it to mine a lot, mostly because I have a hard time explaining things clearly without unnecessary details that confuse the matter. It sounds like a similar situation here. It is frustrating sometimes, because of the terse and almost canned nature of his responses, but he has a ton of bugs to sort thru. If BIS was capable and interested in hosting their own bug tracker, I'm sure they would have done it by now. But quite the contrary, they view the CIT as a success. (see biki OA faq responses) Your claims of 'high handed and highly political' behavior I find quite ridiculous and deliberately dramatic. Considering your obvious intelligence and great contributions to the community and game, (like ECHO) I did not expect this from a person of your stature. The CIT has proved itself time and again, by providing a platform in which work gets done to fix game bugs quickly and provide a democratic way for people to suggest feature changes. Your post lacks any respect or acknowledgment for the success that have brought to the BIS development and beta process. (and the people that volunteer managing it are a big part of it) The staff's purpose is to vet tickets that come in for key factors dealing in the reproduction of the issue. This includes specific repro steps (of which you had none), a repro mission (if applicable) focusing on the bug in question that clearly shows the issue without any other code etc. (your submission was a demo mission for ECHO) These things you view as obstacles are basic requirements of QA testing. (I actually know, I worked as one) If anything, the CIT is actually lenient on the requirements, as it doesn't expect everyone to be a properly trained QA specialist. The requirements exist to minimize the amount of time wasted by the developer addressing the issue. If Suma has to spend ~30 minutes making a specialized test mission to reproduce an issue, that is a failure and waste of resources. This is an area that kju is directly responsible for, verifying tickets are in a suitable state for the dev team to process, before they are sent off. In any case, the foundations and standards of the CIT aren't personal, try not to treat them as such. Without them, BIS would get nothing done because the place would be a mess. The requirements for reporting have always been here, so it is bewildering that you are crying 'conspiracy' here. Please reconsider your opinion. If you'd like to say kju, et al suck, by all means do that. But please don't bring the CIT down with you. The CIT and it's volunteer staff have done far too much good for this game to be treated like that. (I'm not expecting you to love them either!) As a side note, I bet you could volunteer yourself to get a taste and perhaps gain a new perspective on why things are done the way they are. With the utmost respect, oktane (a user and reporter on the CIT/ex-full time QA employee)

Nope, no addons should go in Expansions really.. even if you have CO. The normal dir is ok. In otherwords, you'd put the @oktNoBlur or @oktNoBlurBeta folder in the same directory as the arma2oa.exe file. Then add it to your modline like -mod=@okt_noBlurBeta. If you have more than one mod, it has to be -mod=@okt_noBlurBeta;@someothermod (note no end semicolon) If you aren't using the beta though, you have to use this version for 1.54 retail patch.. which I haven't formally released yet: http://www.506th-pir.org/scripts/oktane/noblur/@okt_noBlur_OA_1_54.zip With the non-beta version, you can use the 'expansions' menu too. (I'm waiting to see if BIS will fix a certain bug with the mod manager)

Thanks. Another test with latest. (been looking forward to this beta, SendUDPMessage command should work!) http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_for_beta_73643.7z

To retain functionality in windows try this: With the mouse software(setpoint, or intellimouse etc), map 'pageback' mouse button to backspace or alt-left arrow, as both of those will cause the browser to go 'back' to the previous page. Then set that in the ACRE config to be transmit. That way you get the old behavior of the mouse while not in game, yet still are able to use it to talk in ACRE.

The issue he's referring to is the ACE manpack radios not working. The interface comes up, but if you xmit, nobody can hear you. After giving people real ACRE radios (with the long whip antennas) things work fine. So some sort of backwards compatibility seems to be broken with the ACE radios. Sorry for limited information, nobody to test with at the moment. But I have verified it personally and everyone who tried the ACE manpacks could not successfully use them. (this at like 50m) Something seems wonky with them. This is all with version 1.0.11.

KaBoNG, 'ANZINS' has his own thread afaik. Can anyone test this? It's for the latest beta. It's a completely automated build. http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_for_beta_73478.7z Note that if you use the 'in game' shitass expansions manager, it can't load the paa logo before you 'enable' it. It's because it's inside the PBO. There's a bug in the expansion manager that doesn't allow pictures to load properly if the folder starts with @, which totally figures. (all BIS stuff does not have @ and it works fine) If that's okay, then there isn't much more to do, cept clean up the old readme, posts etc. Then start the 'machine'.

Solution (to a non-existent problem imo): Write a pipe -> ms/mysql connector, I'm sure it would be appreciated by those that need it. Otherwise sqlite is perfect for stats and dyn missions, etc. The reason I say it's non-existent, is because it was based on an assumption. Stats tracking should do fine. You're only as fast as the game engine anyways, if the sqf engine couldn't handle the data throughput, either could the hooking engine. Use intelligent caching, only write data that matters, etc. For example, benny has stats tracking in warfare, and he uses the damn clipboard buffer! (no armalib) So I'd recommend you try it before suggesting major changes to a system that already works. The 'remote' argument is totally valid, but hopefully BIS will fix the UDP command someday, or a community member could write a plugin for armalib or pipe->whatever connector. You can also read the sqlite db file periodically. (why does it need to be 'instant', can't it be delayed by a few minutes?) I'd start fleshing out your stats tracking with the implementation that jay has already put in, you could start today, work around any problems that come up later. To the guy that asked about DLL injection, google 'dll injection tutorial', the first link from edge of nowhere is good, as are others. There really isn't a simpler answer. Cheers

Please note that if you have previously 'Disabled' CO with the old version of the tool, be sure to 'Enable' it back with the old version before downloading and using this new version. We did this because it disables it in a different way now, and wanted to avoid any issues with people mixing versions. If your CO is disabled (with the old version), the new version will not let you proceed until you have re-enabled it. (with the old version) Cheers Details: The old way it was disabled (in this order too): Addons was renamed to Addons_A2 Common was renamed to Addons <--- this is the part which was incorrect and shouldn't have been done, yet the game still worked. arma2.exe was renamed to arma2.exe.off a 1 was put in $codisabler$ status file The new (correct) way it's disabled in v2: Addons is renamed to Addons_A2 arma2.exe is renamed to arma2.exe.off 1 is put in the $codisabler_v2$ status file (note the new status file)

Works great here, got 3 people using it pretty much fine! One thing was odd, instead of USMCSoldierLight error, now there is a Worker error. :D RPT in spoiler: The other occasional issue is "ACRE [7:8:57.744] RadioDistortion::AddToChannel() : Already on a channel" popup in TS but I am checking if that is a misconfiguration or a known issue. (I don't get this, but the two other guys do)

Note for 8/27/2010, after that disregard.. If you sync this via Six Updater, the crashy version is still on there. Jay has hotfixed the release but Sickboy will not be active until tonight, due to time difference, and therefore cannot update it until then. Bugged version is version 4 on six updater.. I imagine the fixed one will be 5, after SB uploads it. In the mean time, you could manually install jay's hotfix for now, and when you update Six Updater, I imagine it will blow away the files and make it's own when that time comes. Cheers. Bad version 4 from SU: File: jayarma2lib.dll MD5: e168f9a94d866695ab99dc70e2760a3f Latest Download from Jay: File: JayArma2lib.dll MD5: 31a7ce9a23c5f79fda5fb2d35e35d342

Hi ACRE Team I looked around a lot for this (here and issue tracker), I was surprised that nobody had reported it. (apologies if it has already) But the acre_sys_deployable.pbo causes errors for people that have OA standalone. Due to this section(config.cpp) referencing an A2 object not present in OA: class CfgVehicles { class USMC_Soldier_Light; class ACRE_DummyUnit: USMC_Soldier_Light { takeWeaponAction = ""; animated = "false"; }; }; A popup error occurs when the game is started for the first error, and the rest silently fail but occur in the RPT. Below is the RPT section. Otherwise radios operate normally. (I imagine the actual deployables don't though, not familiar with that system) Cheers

Pretty much a month doesn't go by before this pops into my head.. "You're in position six, now grab that truck and get out of there, out!" (listen) Pretty much the greatest series, made with by the hearts and minds belonging to a rare mutant breed of developers. They broke the mold on it, there can only be one 'real virtuality'. :)

Hi $able This does not negate the need for BE to have a simple log file, it would help tremendously with auditing and having at a glance log of what went on. All it needs to do is make a log file similar to the arma rpt, which lists all events that are normally seen in the rcon console while logged in, it can be stored in the BEpath directory. Writing a separate application that has to run 24x7 logged into the server, just to keep track of a log, is a bit kludgy don't you think? It's only needed on the server side really, and it would just log BE events, nothing complex. Timestampped, with Player joins, admin logons, admin actions taken, disconnects, etc. The issue with the server_console.txt and RPT from arma is that in a lot of cases the information is irrelevant, or spread between the two files and you have to match up things, or that the file isn't even written out when the server crashes. A BE-only log would be much more applicable and useful. Perhaps you can have a variable in BEServer.cfg that specifies the max file size before erasing old data, but that isn't a big deal. Cheers and thanks for BE

This is indeed the case as we expected. OA Standalone differs in that it does not have an Addon directory at all. Arma2 Standalone: Addons OA Standalone: Common Expansion Combined Ops: Addons Common Expansion So the tool should actually rename Addons to Addons_A2, rename arma2.exe, and that's it. Common should be left alone. Did you make this with the .Net deploy tools? If so it should be easy to update hopefully. Cheers.

Guessing that's due to the AI communication links for group members? Say if member 1 sees something, he tells 2,3,4 what he saw if they are in the same group. Whereas without grouping, they don't share information and would have to each witness/hear something to react.. plausible?

Will you have a solution for servers that need to run server side addons? Addons such as CBA, GroupLink, ACRE, JayArma2lib which are not required clientside... As was mentioned, enabling anything causes people to get confused by the icon. I think this is all due to the technical limitations of the method used to populate the icon. If the base technology was improved (ie, start over without using OFP GS stuff as a base) I think it would actually work as you would expect. This essentially means: Importantly, a completely DIFFERENT way of checking, with these essential features: Class dependencies based on in-use MISSION addOns={} data, not server startup modline. This also solves the server-side mod issue, as those serverside class parents aren't going to ever be present in a mission.sqm. Why auto-require addons that aren't in use? (but you can manually, see below) Admin definable requirements in server.cfg (ie: requiredClassesOnJoin=["ace_main","acex_main"]; etc) Admin definable exemptions in server.cfg (ie exemptedClassesOnJoin=["some_base_class", "acre_main"];, this is the counterpart to above, exempting requirements for known addons determined to be OPTIONAL) The last two above things would directly affect the data provided to client server browser. Hypothetical situation: Server runs ACE and ACRE radio mod. However, they are currently playing a non-ACE mission. As a twist, the mission includes an ACRE radio pack, so that class (acre_main) is in the mission.sqm. (this is unlikely, but please grasp the general concept here) addons[]={ ca_wheeled, (some stock class) acre_main (mission editor classifies as required, but admin overrides that since he knows better) }; Now, at mission runtime: Without required type override, Users without ACE could join, this is undesired. With required override, only users with ACE may join, this is desired. Without exempt type override, User with ACE yet without ACRE gets kicked. With exempt override, same user is allowed in. This is desired, since ACRE is known to be essentially optional. You can see it's up to the admin, and it's very flexible. You may scratch your head at my suggestion, but try to see it as if you were creating something from scratch to solve the issue and disregarding any current implementation. :p I've never seen the code of course, but from observation it seems pretty clear that there are large limitations to working with the depreciated structure that was created back in the OFP days, when the data was so simple and we didn't have some of these issues. And in the past there has been some resistance to change.

Nope: http://dev-heaven.net/projects/six-updater-web/repository/revisions/develop/entry/app/models/appsetting.rb#L11 "Arma2OaCo" => ["addons/"], "Arma2OaSt" => ["!addons/"] If you wish to discuss it with Sickboy and I, we welcome you to the DevHeaven Google Waves. :) (OA Wave here) Cheers.

If you use six updater, it is unable to detect OA standalone properly if you have your A2 disabled with this tool.. It still detects it as CO. This is because OA Standalone does not have an Addons directory afaik. (six updater looks for an addons directory to determine it it is CO) While we wait for someone to provide a clear, real directory structure from an OA standalone install, the solution is to rename the addons directory to something else while six updater is updating, then rename it back. This is only relevant, because of the way CBA needs to be installed. If you have OA standalone, an additional @CBA_OA is required. If Sixupdater detects CO, it disables this addon and it won't update. THerein lies the problem. I am guessing (and we wont know until someone reports back) that all OA installs have a common folder, and the renaming of common->addons is unnecessary. But we'll see soon. Cheers

Hey jay, Sickboy has generously provided an 'afteraction' execution option, for six updater. So provided he syncs the beta to the repo relatively quickly, and you can somehow automate memory hook location finding, you could execute it that way. (if a new beta is detected) All of this coupled with running six updater console mode, via cron job. I intend to do something similar for the noblur, each time a new beta arrives, bin.pbo will be patched automatically into an addon, named by version num, and ftpd. (hopefully soon) Maybe you can find a way to do this, to make things easier on yourself. There are also tools in the DH waves for unittests, you could make a unittest to test if the new hook is working, then everything would be automated? Since I have no idea if you can automate the hook location finding, this all may be of little use. Thanks for arma2lib, sqlite is superb!

Yes, while minor those would all be actual bugs imo, aside from the ones about pockets and crouching. Especially if they can be reproduced on another players machine, then for sure they are universal bugs. (like i have verified that the shadow is missing for the hat) The pockets inclusion was the artists choice when BIS made the model, I don't see how this is a bug at all. If it was posted, it would pretty quickly be assigned into a feature request I bet. The last one about crouching, um, set a key to crouching? That sounds like a user configuration issue, the game expects you to have a key bound to it. If you don't want to do it, then while in the mission, hold down left shift and type: numpad -, e, n ,d, m, i, s, s, i, o, n (without the commas, all while holding left shift) What that will do is pass the mission successfully. Dunno if it works for what you are talking about. I find it simpler to use the mission editor to test things rather than the armory. I too had some LOD issues with the betas that became 1.07 and 1.07 itself. Especially certain weapons held by other units appearing to be square and malformed up close. (very low LOD) This has also started happening in recent OA betas. The front sights being missing may be a part of this overall LOD issue, or something else..(I can't understand why the game would show low LOD models for the players 1st person gun, it shouldn't do that afaik) If you run very low graphics settings, be sure to mention that if you report it or find the existing ticket. I looked at the 1911 and it appears normal in my 1.07 A2, it has a front sight even though it is a bit low. (the camera alignment is a little bit off, it's hard to see) Cheers

Dwarden, are there resources for users to sanity check their environment before submitting bug reports that are very likely not bugs at all? You ask for people to submit everything like crashes and such, but doesn't that produce a ton of tickets that are user configuration or user enviroment issues and not bugs? For example, if after patching the game, a user has crashes but there aren't reports of that 'en masse', and the user does not provide repro steps or much detailed info, what is the workflow for something like that? Does it go to BIS for someone to load up into the debugger and report back what the fault was, providing a kind of tech support? To rephrase, does that fall into the scope that the CIT serves? I am asking this because if the above situation is acceptable and desired by BIS, providing tools and guides for users to sanity check their environment may help alleviate the creation of such tickets that are user issues rather than game bugs. I often help troubleshoot peoples game issues, I have found that MD5's are very useful for determining if a users game data is corrupted. When the game is corrupted, all kinds of issues can arise, the most common of which is frequent crashing. (when the game goes to load an asset which is corrupted, poof) Also, in the above example case, the user could have had an error while patching that wasn't reported because he didn't see it or think to include it..(dunno, major lack of detail there) any number of things could have happened really but still likely not a game bug and isn't being reported to other users. Any consideration for a similar yet separate CIT system specifically for tech support, such as community helping community, rewarded with rep points or something, like experts exchange or yahoo answers, to reduce the amount of non-bug dumps going in BIS's direction? (BIS could still get involved for tough ones, or if enough people are having the same issue(as in a game bug), a staffer would forward the ticket to the original CIT) In a perfect world, the game should never crash, even if presented with garbled input.. But that is never going to be the case, and I've never seen a complicated application capable of doing that. The error checking and handling code would equal or outnumber the actual app code! Just curious, Cheers (also sorry to you Warrior for using your ticket as an example, don't take offense :) )

Hey I apologize for being so verbose, it's just the way I express myself, a force of habit from teaching complex tech stuff, I try to explain the same thing 30 different ways until even I am confused. It gets worse with more beers. But don't interpret my verbosity as annoyance, or disrespect. The two places (BIF/DH) serve separate purposes, and they both must exist for either to prosper. I am just explaining why DH/CIT cannot become the next BI Forums, and why certain elements that occur here frequently are not welcome or tolerated there. And don't construe it as elitism, it's really open to all who want to apply some effort to what they'd like to do and get involved. Wishy-washy nonsense: Cheers :cheers:

Argument for the sake of argument? SNR seems to be falling rapidly.. defending some unidentified group of people suffering as a result of the CIT's existence? What seems more obvious to me is apprehension towards anything that inconveniences you in the least. (see spoiler) No, there isn't that I know of. The information changes regularly anyways. (people get new hardware, upgrade OS, etc) Your browser has the capability to save the information in the text fields too. Those fields are irrelevant to most bugs anyways. For example, the 'GFX card type/Driver' data would be relevant to a bug about GFX stuff: LOD swapping, running out of VRAM, alt-tabbing issues, or crashes. But it isn't useful for a bug about a scripting command not working, being able to hear 'dry fire' noises across the battlefield, or the Mi24's air-ground anti-tank missile not hitting targets properly. So include them if you are unsure, but they don't have to be there if they aren't useful. Seriously though, Phantom (oops, I meant) Dice, if you have an interest, your desire for improvement is welcomed. You can join us at the DH google wave discussions, your technical skills can be used if you wish to volunteer. Sickboy would be the person to address. We could use some help on the 'dynamic class browser' css and js.