Jump to content

oktane

Member
  • Content Count

    520
  • Joined

  • Last visited

  • Medals

Posts posted by oktane


  1. 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


  2. Its automated release for new beta's, just go here:

    http://www.506th-pir.org/scripts/oktane/noblur/

    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


  3. Oktane, is this supposed to completely turn off the blurring effect around the edge of the screen when walking/running? I'm using the version for OA 1.56 and I still have the blurring effect. Would I get startup errors if I were using the wrong version?

    (I have CO, BAF and PMC, if any of that makes a difference.)

    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:

    noblur_mainmenu.jpg

    I cropped out some of the menu and stuff to save space.. so it looks weird. But that's the main menu screen.


  4. Beta 75666 and 1.55 Patch are both for OA.

    Any chance you could build a version for vanilla A2's 1.08 Patch ?

    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.


  5. Hi, with last week's release of patches for A2, OA and BAF would it be possible to generate another version?

    I patched my copy of A2 to 1.08 last night then gave it a quick spin and I swear I felt dizzy and eyes squinted at the screen...

    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!


  6. 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.


  7. oktane if you paid attention i said it will be resolved ...

    also you obviously missed the first post with included 2 junctions solution

    one is via OS mklink (w7/vista) another with Sysinternals junction (xp)

    i also bet that Sysinternals's software You are redistributing w/o licence file or readme is not possible way for me to officially do ...

    not to mention junctions are in certain aspect unrealiable and thus i was not able use it in first place by default

    so nothing new :(

    anyway back to first line ... work in progress ...

    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.


  8. 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)


  9. As its been suggested before and reminded to me just now, setting cpu affinity to 1 for TS3 solves a number of the crash issues for TS3 and ACRE since it limits execution to one core and prevents race issues from occurring in the code.

    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


  10. Exactly, thanks Bink. Sadly, vanilla pilot AI is a bit silly. I can probably adjust their flight route so that they have time to gain altitude before reaching any trees. For now, use VFTCAS (it's just a good mod to have enabled anyways). I really hope BIS does something about the piloting AI in the future though.

    No longer requires VFTCAS to my knowledge, now the pilots will actually clear the trees at the airfield and fly to the LZ. Let me know if they encounter problems anywhere else. I've been relying on VFTCAS too much I suppose, since it fixes a critical flaw in Arma 2.

    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


  11. 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!)


  12. 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


  13. 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).


  14. 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.


  15. Just discovered that two tickets relating to the BIS artillery system, one by me about how it reloads ammo and another by Das Attorney about a bug in the latest beta had their status changed by a non-BIS person for very questionable "stylistic" reasons.

    I find it highly distressing that a self-appointed censor is altering tickets in such a high-handed and blatently political manner. The effect has destroyed the credibility of CIT in such a way that I may never totally trust it again.

    At this point I'd prefer that BIS run it's own bug report system with properly vetted staff managing it. Having a 3rd party in charge always had the potential for tampering. Additionally, the host server of dev-heaven.net has proven to be less reliable than hoped, with a much higher rate of downtime than what is expected for professionally managed sites.

    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)


  16. 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)

×