oktane

Thanks guys. I saw a patch came out for arma2 today.. I wonder if there will be a new OA soon then too. Here is A2 1.09, in usual place: http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_A2_retail_1.09.7z Haven't tested it, but should work fine, same as others. Let me know! Cheers

How goes it then? Any news on the dll? Cheers

If you like what Jman is doing here, or want to expand your missions capabilities with SQL storage, please vote up this ticket for jaynus. We think alike! I had a similar test mission running, far more crude than that beaut, it's liberating having sql access isn't it.. so many things can be done. Makes you think of the game in completely different ways. But without support on the current jayarma2lib sqlite bugs as you mentioned (I reported those :D), I lost hope.. there are too many 'gotchas' that cause the jayarmalib hook to crash the server when using the current sqlite implementation. It's amazing what he's done so far, his auto update script is boss.. imagine the backend of that.. searching for new memory locations to patch when a new beta comes out, it's unreal. Hope you get it working! Cheers **There are some other implementations without jarmalib but they are very low bandwidth, and not ideal for a GSP like jayarma2lib is. It's already trusted and accepted.. there are just a couple issues holding it back for this kind of thing! We'd all use 3rd party exe + pipe but it's not allowed on GSPs, therefore very poor adoption..

Everything still okay here? I don't monitor how many people use the noBlur, and since it's been automated I rarely have to check on it. Just wondering if people even still use it? I noticed that the new betas seem to run really well.. never seem to have the low LOD problem anymore. Oh and that thermal problem I was having was because I somehow deleted the whole /arma2/expansions/dta folder one day.. You can imagine that caused a few issues.. but nothing to do with the noBlur. :D Cheers

77737 Beta is screwed! There are no shaders in it! So I'm not releasing that one. But as soon as I clear this broken beta out, the next one 77750 will process. Sorry for the delay. I'm happy it wasn't a problem on my end this time. (except for the fact my script stalls when it has an error.. :()

Looks like it did it an hour ago. My computer was asleep so that's probably why it wasn't there when you expected. :) I should move it to the server that is 24/7 soon.

Lol, ironically it broke today, because I was moving things around on my hard drive and moved the DirectX SDK to another drive. This broke the automated build and I had to debug it to figure out why. So today's okt_noBlur_OA_beta_77068.7z was reuploaded just now, should work fine.

Yes, thanks for spreading the word. As long as my computer is on, it will try to process any new betas within 30 minutes of their release. When a retail patch comes out, those I do manually, but I usually get to them pretty quick. A while back I updated the main topic to say this stuff too. If you want to know when new betas are released, you can try out my RSS feed too. http://forums.bistudio.com/showthread.php?t=85411

New 1.57 retail patch is out, noBlur is in the usual place. http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_OA_retail_1.57.7z

This disables the full screen blur effect that occurs when you have the post processing on Low or higher. (it is not present in 'Very Low') The blur happens when you move the view around. It happens constantly in first person. This does not effect the running or tired blur at this time. (this blur only occurs at the edges of the screen when you are running, and another kind of blur appears if you are very tired) CO, BAF, PMC, none of these things are relevant to the functioning of the noBlur. All that matters is what version OA (or A2 if you don't have OA) you have. As mentioned in the first post, the version is displayed when you have the mod loaded. See here: I cropped out some of the menu and stuff to save space.. so it looks weird. But that's the main menu screen.

This works well enough now that auto FTP'ing is now enabled. The check takes place every 30 minutes for a new beta, processes it and uploads it to here: http://www.506th-pir.org/scripts/oktane/noblur/ Please let me know if there are any issues. I don't play the game or test them very frequently anymore. :(

okt_noBlurOA is For any version of OA, CO is not special.. it is just A2 running inside of Operation Arrowhead.

Hey all right, new patch! Try this out http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_OA_retail_1.56.7z

Ah sorry I missed that detail, yes sure: http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_A2_retail_1.08.7z Can you try that out? If everything is good then I'll formally release it. Edit: if you downloaded this when I first posted it, it had a issue.. should be fixed if you redownload it. Note this is only for ArmA2 Standalone.. ie if you do not own OA. If you have both games aka Combined Operations, you do not need this. It's only for people that want no blur when they run classic arma2.exe.

Hello Sorry, I've been away on a trip. Can anyone try these out: OA Beta 75666: http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_OA_beta_75666.7z OA Retail 1.55: http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_OA_retail_1.55.7z Now everything's pretty much fixed, and even creation of retail noblur's is scripted. (yet manually triggered out of necessity) These were both generated by the system. Now to automatically zip and ftp upload, then I don't have to do anything!

http://www.506th-pir.org/scripts/oktane/remove_arma2_pbo_association.reg If you aren't editing or decompressing PBO files, then this fix probably won't be important to you. The latest patch seems to glom onto the .pbo file association. Hopefully posts will help those get back to their previous association for PBO files. EDIT: Beerhunter found out that if you use XP as your OS, the solution is simpler: "Start"->"Control Panel"->"Folder Options" Folder Options has 3 tabs. Select "File Types" Find "pbo" , click on it and the "delete" button becomes available. Click on "delete" and confirm (or "edit" and select another program to open the pbo's rather than ArmA2). It is pretty difficult to remove and there is no way to do it without using the registry. (that I know of) This reg file removes the stuff that Arma2 1.05 does to the association. You can look at the file, it is just text. To run it, just double click the file. If you have Vista/7 with UAC, you will have to run it as Administrator. If you previously had a default action, it may go back to normal after running this. If after running it, it still doesn't work, you may have to reinstall whatever app you previously had managing pbo files. (for example, I use cpbo.exe) If anyone knows WHY this was put in, post here! I think its so you can launch missions directly by double clicking on them. While this may be useful to some degree, it isn't so useful for a power user that works with both mods and missions.

Use the symlink method.. this will make your game combined operations all the time. Then you can use the in game manager. (because now you wont need to specify A2 on the mod line) Is the symptom, that steam says Launching but it just hangs? Btw, theres a space in your mod line. Heres the script to do the symlink: http://506th-pir.org/scripts/oktane/combine_A2_and_OA_into_CO_v2.zip Make sure you run it as administrator. Now you don't need to tell steam to run as Combined Operations anymore. You can also try Spirited's ArmA Launcher, but it will have the same issue if you have a long mod line and steam. You can also get the beta, and then you wont be hassled by steam's issues like this. (the max modline issue is steam afaik) Hope this helps some.

The sysinternals software includes the EULA. Upon first run, the EULA is displayed, and the user can accept or deny. However, you are correct in that you cannot redistribute it, I would not in your position. But in my position, I don't mind. I suppose it could be made easier if it fetched the exe from the sysinternals ftp, avoiding the issue. (edit, here's a version 2 which does just that, fetches it legally from live.sysinternals.com as their license directs... ) If you had looked at what I posted before becoming defensive, I simply improved the junction script you put in the first post with more help text and error handling, so.. of course I read the post fully, downloaded your junction script, and then made improvements to it. Yet, the core of the script is identical. Please don't confuse my passion and desire for the game to be more friendly to new players as an attack on your scripts. What is troubling to me is that the problem and temporary solution appeared to have been dumped on to you to solve, perhaps because it wasn't taken as a very high priority issue by the programming team in the beginning. I and many others continue to appreciate your community outreach. But this is one issue that seemed glaring enough, troubling a large subsection of the userbase that own both games, that I thought (and this is just my opinion) it deserved a real engine fix, not a interm batch file solution for many months... Please understand, this does not disrespect your effort to help people here in this thread!. Just felt that more programmer resources could have been put towards this for a complete fix.

here's a much more user friendly 'junction' script pack I just made. http://www.506th-pir.org/scripts/oktane/combine_A2_and_OA_into_CO.zip If you want to run CO, I recommend you just junction the directories. It's straightforward, and the most trouble free, especially if you have Steam OA. The problem with !@# Steam is that it chokes on long command line options, so if you have lots of mods, it gets stuck saying 'Launching ArmA2 Operation Arrowhead...' and never starts the blasted game. When you junction the directories, you no longer need to run in Steams 'CO mode', because it's automatic. This saves a shitload of characters on the commandline, because now it doesn't need -mod=ca;c:\program files\steam\steamapps\arma2" etc. I wish BIS would refrain with the 'advanced users only' scare, because with a little work on the batch file package, it's very easy to use. I am only posting this to help anyone else it may affect, as I've had to fix several OA installs via remote control that wouldn't work with long mod lines because of this issue. Junctions is the way to go if you cannot install the games into the same directory. (ie, you have Steam) MP works fine! Why would you ever need to run OA Standalone anyways? (Perhaps if you are a mission author, that wants to make clean OA-only missions.. just use Deadfast's CO disabler.) BTW: To undo the junctions, just delete the Addons and Dta directories in your OA directory. (don't delete the ones in your ArmA2 directory!) This will make OA standalone again. I hope this issue is fixed in the next retail patch with the registry improvements. There's no logical reason OA itself can't detect if the original game is installed via the same registry keys the batch file uses.. Steam and BIS games never seem to get along! :mad: This really isn't being treated as a big enough issue. Official batch files that launch the game are bit ridiculous... (No offense to the author, Dwarden?, but imo the engine exe is more than capable of reading the registry on launch.. possibly provide -noA2 or -oaOnly command line paramaters to disable automatic CO detection.) Hoping for the next patch! Cheers (ps Dwarden, feel free to improve your scripts with this if you wish)

Hey that's neat. Do you think that you could add a shortcut for TS3 to the desktop (if the target OS is Vista/7 only though) that has a target line of this? c:\windows\system32\cmd.exe /C start /affinity 1 c:\path_to_ts3_detected_from_plugin_tool\ts3client_win64.exe" (or/and ts3client_win32.exe if found) This would cause it to start on CPU0. You could name it 'TS3 ACRE (x64)' or something? I don't know about solutions for XP, but this sure would make it more stable for a larger portion of people that have Vista/7. (I've had to help a lot of people with the #@! Six Updater version of ACRE, I noticed most of them have these OS's) Send me a PM if you'd like any help with adding this, or the installer, etc. Cheers

FYI, in some cases, addons can be converted into mission scripts, because they aren't doing anything special. For example, the VFTCAS really has no purpose as an 'addon' other than ease of use. It's config.cpp simply runs the script on all helicopters present in the game world. For a mission author such as yourself, I suggest to unpbo VFTCAS and grab the tfr.sqf, which is the meat and potatos. Put that in your mission, in a VFTCAS folder, and call it in the heli init like _ret = this execVM "VFTCAS\tfr.sqf" Here's a rather extreme demo to show what I mean: http://www.506th-pir.org/scripts/oktane/VFTCASdemo_script_version.Chernarus.pbo.7z You can adjust the wp's to TRY to get them to bash into the mountain, but the two OPFOR hinds with VFTCAS will be very difficult to crash. The civvie one without it tends to crash at the very top, rather than into the rocks surprisingly. (BIS has improved it a bit but not as good as VFTCAS) The cliff is so extreme that in some cases (it's random) that when VFTCAS needs to kick in really hard, the chopper goes hauling ass upwards. Love these small missions. Only issues I had in the Radio one were: -Last AI guy did not want to get in the damn chopper at base, could have been user error, I think he ended up getting in the gun.. It's like there is one guy too many for the back seats. -The chopper not landing at the LZ.. it hovered. I had to tell an AI guy to 'disembark' which of course forces the chopper to land. -The chopper that picks you up wouldn't fly to base, it just hovered over the extraction point. I manually debug setpos'd it back to base so the mission would end(always want to see if there's any ending), and the damn guy flew back to the extraction point! So I setpos'd it again and did the disembark trick. :D May have just been beta issues, I was using the beta. The difficulty in that mission was perfect though! Anyone who goes head on into the forest, up the road should be shot anyways. Flank the radio, use trees to support your weapon(esp with MG), and you're in for a good yet winnable fight with minimal casualties. The only issue there was the AI being wounded over and over, kept having to revive him. Most of all I like that you are not given access to a magical weapons box with 200 guns in it, and grass was left on. Some C4 or Wirecutters would be nice for the dual fence, as well as earplugs. Cheers

Then you can burn it to a DVD after you download it... Watching too much Lethal Weapon?

Part of the problem is the version on Six Updater. It's been 1.0.11 since the hotfix was released. Since a lot of people use SU (that is, if they already use ACE etc), they all have the unstable version. Quite a few people aren't technically comfortable swapping between the SU repo version and the installer version, since SU handles it for them and it gets confusing. I'm looking forward to Friday when the updated version comes out that hopefully resolves things. In the future, hopefully the ACRE team would consider rolling back if a bad version is pushed to SU. (ace has done this too, when needed) I realize the SU version may be considered 'bleeding edge', but you have to admit that the majority of users that sync it via that are indifferent, stability is more important. If someone really needed to test bleeding edge, they could seek it out from the code repo too. I'm still pestering SB about various automagic dll-configuration implementations within SU, to make the SU version on par with the e-z installer. :D Cheers and thanks for everything so far. D3lta: The loss modeling is dynamic afaik, not island dependent. (ie, there aren't lookup tables, they'd be huge!)

Maruk/Dwarden, You mentioned some interest in making these shaders configurable, even the simplest of implementations would be appreciated. (undocumented ini setting, able to disable a few of the biggest offenders) Consider that this old guy from pre-OA still has nearly 100 votes. http://dev-heaven.net/issues/show/3718 While the addition in OA to have a very low level is nice, it doesn't fully address the communities desire to have a separate control on rotBlur and Glow/Bloom. Cheers

Heh, and another.. http://www.506th-pir.org/scripts/oktane/noblur/okt_noBlur_for_beta_74123.7z Basically, if you notice a pattern here, they are located here: http://www.506th-pir.org/scripts/oktane/noblur/