PiZZADOX

"This is a simple config/script patch for Arma 2 OA. My objective is to correct all the errors that ArmA 2 OA (1.63) show with the launch command line -showScriptErrors. Upon rollout of 1.63 patch, Bohemia included a new script interpreter that show all the undefined variable present inside scripts. There are a lot of them and maybe they cause script to not run properly. Because of ArmA 3, BI programmer have not much time to spend try correcting errors of an old product, as a programmer I understand this, so I decided to use my skills to try to fix these errors as best as I can." EDIT: Please do not change the class names of the addons in your configs. Changed Corepatch_Turrets to Corepatch_Vehicles. Any mods that use these classes as dependencies (any that want to revert some of your changes) break and need to be updated for the tiniest of reasons. What was wrong with Corepatch_Turrets? That addon modifies the turrets...

Fixing script errors due to new interpreter != changing values in configs. Corepatch was meant to be fixing BI content and performance gains, not to change aspects of the game.

g36 and AS VAL/VSS optics broken on most mods due to new muzzle config.

Anti Prone in buildings has not been updated in this patch, updated Module: https://dl.dropboxusercontent.com/u/187563416/Arma%20Addons/CorePatch_AntiProne_v3.rar

As stated earlier, Corepatch is great as long as you fix and improve core aspects and broken elements. However I do not agree with adding elements to the game that interfere with other mods or simply tweak things, these things should be put in their respective mods (ACE/ DayZ/ Life) Barely anyone updates these mods, so it will be broken in these mods... I fixed the problems with the RPK magazines and BMP sighting adjustments in ACE but I do not have authority to publish an update to Armaholic or SU, meaning only people who I can communicate with in my unit can recieve updates. This is simply not the best case scenario. These edits would have been great if made inside ACE...

I would agree pistols are useless as is, I use a simple config mod to boost them to levels i find acceptable. Of course pistols cause less damage over a long distance, but the effective damage in a short distance is very comparable to intermediate rifle rounds. We can simulate an exponential decrease in damage from the airfriction value right? EDIT: Regarding the config or lineintersect methods, It seems like line intersect is the only universal way of doing it. It seems to work without too much performance impact. Updated pbo here: https://dl.dropboxusercontent.com/u/187563416/Arma%20Addons/AI_AntiProneV2.rar

Good idea, most likely taking the +Z of the box and then giving some generous leeway (seeing as boundingbox is a little innacurate, and specific buildings have a box that is much taller than their roofs. ) would work, and that should be much better performance than the other options, hopefully.

This is definately the next step. I would assume shooting a line above every AI's head is out of the question performance wise, but idk about the feasibility of doing a config class switch matrix. Doing a simple elevation check wouldn't work as building heights are different. It would have to be combined with the config class... I'll test some performance of the class switch and line methods. Since nearobjects commands already gather the class name I would assume the majority of the script time would be in the name switch. I ended up using a class switch matrix for my button door opening mod, and the performance was not lowered by any significant measure.

The FSM conditional check for inside (near the center) of a building works well as is but I think it would be best if we could have a lineintersect shooting above/infront of an AI's head to determine if he is in a fortified position, although I don't know how much that would affect performance.

Here is the mission I used for testing: https://dl.dropboxusercontent.com/u/187563416/Arma%20Scripts/FSMtestAI.Zargabad.rar Just a very simple mission involving an enemy in a watchtower position and a captive on/off switch for the player's unit in order to see the effects of the DangerFSM activating. Here is a youtube of a comparison of old/new FSMs:

Seeing as Corepatch is the only hope of ever getting a core fsm change, what would you think of editing / improving on the dangerfsms? I find the problem of AI going prone in buildings as very detrimental to cqb combat and any enemy building occupation scenario. (think AI rifles and arms out of the walls, and AI in watchtowers not being able to fire out of them) I whipped up a custom danger formation fsm, with a simple conditional check for buildings or houses which would make the AI prefer to go into standing or crouched position and keep them from going prone. Of course AI away from buildings are not affected. compare the behavior of the enemy detecting you or a shot with and without the addon. It's not perfect and is not meant to be a finished product, but I hope it can open up discussion on the old fsms and the work that can be done on them. https://dl.dropboxusercontent.com/u/187563416/Arma%20Addons/AI_AntiProne.rar perhaps even some additions to the danger FSM such as firing a couple quick shots on audible contact or taking fire instead of spotting the enemy before being engaged. (forcing AI to fire weapon before hitting the dirt)

Also done with BI. I was done with BI for a long time, but now with their ill choices in allowing the community to change config values at such a late development cycle I realize they know nothing about game design theory at its core, or they simple don't care. Either way, ArmA 3 is a mess and I could never see myself playing it without major engine calculation rebalancing, and ArmA 2 is getting broken more day by day, so there's no point. Here's hoping some competitor will come along, and they certainly have my monetary support.

All of these changes built into an ACE framework would have been great... but they weren't. I don't understand how one could possibly think that reconfiguring the muzzle indexes of weapons wouldn't have an adverse affect on anything, not least of all the missions with scripting workarounds for selecting them, now they are unusable. Easy enough to fix, but people are more likely to drop the game than to fix a lot of these issues. Crazy man was right, this just pushes people away from ArmA 2 even more. Fuck bohemia, they are a shit company and the more they move in their new direction the worse it will be. Arma 3 will never be fixed and arma 2 will continue to be ruined. Guess im a paradox exclusive gamer now.

You are forgetting that many mod devs have abandoned their projects. Putting an update like this, as there was tons like this in the past, would have been fine if there was a healthy mod community with active devs. There is not, so it means a very, very small percentage of mods will be updated, including the most popular ones. Just like the new script interpreter that breaks so many scripts that will never be updated by their mod authors (think UPSMON) it ruins the functionality of the game, and is a direct result of a bad decision to update a game that is completely done its development cycle. It's like if some obscure game with a ton of mods, say Empire Earth, was somehow updated and that update broke many cpp inheritance and made many of its most popular mods unplayable. It just does not make any sense. I completely agree with corepatch or any effort to fix Bohemia Interactive's own issues with their harsh script interpreter, but changing game assets is just plain naive. How many people use ACE? A decreasing few, and you know that is going to be less now that these problems are plaguing it. You want to encourage realism in a milsim game? FIrst of all, the devs are not on your side, look at the mess that is ArmA 3, and look at their shitty implementation of the new script interpreter that stops scripts at a point when they were not stopped before. Secondly, you just broke a bunch of features in the most realistic mod... How could anyone argue going from a usable ACE to a core game is more realistic? That is asinine. lol @ the people defending this update by labelling everyone who disagrees with it a DayZ player. Never enjoyed DayZ, never seriously played it and never will as I enjoy realistic milsim gamemode. Your small, insignificant config changes make nearly no difference in terms of realism compared to ACE, and significantly downgrade the usability of it. Take a step back and put yourself in line. Some people dont want realism in ArmA, and since ArmA is just a platform, those people have a right to a say as well, but if you are going for realism what the hell are you doing.

ACE 2 handles backpacks in a different way than base OA. In fact in ACE there is an effort to remove the combined player + backpack models entirely and simply use separate attached models to display backpacks.

Would have been nice to simply not put that stupid script interpreter update that broke most of our scripts at the end of the development cycle. Sure, there were errors, but it logged it as an undefined variable and dealt with it instead of stopping execution of the script. I thank goliath and the people like opus that did great work reporting errors. This is all in response to BI's errors in missions and modules having tons of errors according to their own new script interpreter... what a joke. This is completely different from content changes. Patching the invisible but beneficial updates for BI modules and scripts is great, and no one could be upset about that... Changing frankly minor parts of the game that break a ton of mods which will most likely never be updated anymore is just simply stupid. Breaking tons of optics, especially via ACE workarounds for muzzle changes (not to mention many scripts that rely on muzzle detection) is just ludicrously stupid. How anyone can even think there is as big of a modding community in A2 as there was before is beyond me... not to mention we dont have access to any of the keys or authorization to update ACE or the like. Maybe the crazy person saying this was all a ploy to get people over to A3 was right. Ever since 1.62 literally every single thing BI has done to A2 has been ruining it. Sure, the server browser hosting was not their fault, but such a simple edit to the reporting server could have fixed that (Halo 1 update for gamespy outage) but instead we get a shit script interpreter and a bunch of changes that ruin things. Great job bohemia. Top fucking notch.

I don't mind most of the changes, but as stated earlier, most devs have abandoned their A2 projects, and most players are not going to come here and complain, they are just simply going to leave and play a different game. If for some weird reason you think ousting all the DayZ players will make arma 2 milsim better... say goodbye to all support for hosted servers from 3rd parties and any custom launcher support. I bet you the main reason we were supposed to get patches after 1.63 was the large DayZ community on this game... The attitude from Schatten is simply childish. I would love you on an ACE team, but I hope BI throws you off Corepatch. I don't see how they couldn't, given the intense backlash, and simple config errors resulting in unplayable assets.

Schatten, maybe instead of responding to each and every criticism of your work you could perhaps be constructive and make sure this complication doesn't happen again. Spreading more info about the github and the changes you are making will help, and maybe listening to some player feedback about the things that are not simple bug fixes (as this was corepatch's initial warrant) Does goliath work alongside you for the config changes or are you solely working on the config changes? I might add that the amount of players lashing back at these sort of content changes pretty much bars your name from any future projects. Part of what people look for in a portfolio of projects is what other people think of your work and your responses to it... I can bet you a particular unfortunate dev tasked to this project is shaking his head and may be regretting some of the decisions made during this patch's implementation.

^ Completely agree. ACE 2 and any further implementation of that mod is where to put these changes. Changes most of which, I might add, are completely in line with realism. There's a few exceptions, but I would certainly be happy to work with people towards ACE 2 updates, or whatever it would be called.

@theduke77 I remember overtaking civvies on asphalt off the road in Arizona all the time, with 5 tons and humvees. The vehicle offroading speeds in ArmA have always been ridiculously slow. Using Ghost's addon seems to bring it to a more realistic value, although I am not sure about the offroading speeds of BTR/BRDMs and the like. http://www.armaholic.com/page.php?id=29502

inside config.bin (you can convert to non-binarized c++ format with BItools) you should look at the entry labelled "requiredaddons" which should be an array of the required addons, the names of which are defined in each config's cfgpatches section.

People might throw this around, but it simply isnt the consensus, no matter what the intention was, it was pretty clear almost every single decision changing ArmA III from the previous ArmA titles was away from realism and catering to a different audience. Simply not changing a part of your game is not "appealing to the old schoolers out there" it is simply that they thought they didnt need to change it/ were not smart enough to come up with replacements.

headless client

I would agree that that 1) ArmA 3 has many of the same elements and style as the previously mentioned products 2) My perception on it is in part because of your comment and information. Don't be one of those people. My opinion is that it is far more likely that they had sights on an ArmA 3, they would be insane to just never expect making another ArmA... and then eventually they looked at the style and assets they already had from scouting the island/terrain for the other project and decided to use it for ArmA 3. So instead of making them separate games, they merged the assets and made both more like the other. Game devs do this all the time... They are almost always failures, but its pretty common to try and use scrapped content. AS for the Enfusion engine, I highly doubt BI's ability to perfect an engine in the near future. I would be pleasantly surprised if they were to pull of a usable iteration of that engine in the next 2 years, regardless of their development plans. I would agree with your first inference on the issue.

Are you defining a type of group as set out in the defines, or are you randomizing unit count or alternatively using an array of unit classnames? neither of the two latter options work, this is a well known reported error on the tracker. For now only use the group configfile define. It works with this version of corepatch and the latest beta.