NeoArmageddon

It works for commander seats since OFP, so the tech is there.

Just an idea: Why don't you port the CTFs and DMs to CUP, so you can play with oldschool weapons/units/vehicles too? Hexenkessel with Katiba and co just doesn't feel right to me.

I wrote a c++-program that automatically fixes bargates a few month ago ;)

The briefing got broken when I fixed a few other bugs. Should run fine nevertheless.

That is no error. Just stating that default params were loaded because "Load existing or default if not found" was selected in params.

Yes. For now atleast.

They were not meant for editor placement and "accidentally" are available in editor. They will be removed in next update. Consider using an "Editor Upgrade" addon like the ones for A2 instead.

Most likely because the engine must inteprete the type of the arguments to booleans before it can evaluate and compare. See the short-circuit example from the BIKI for example: if ((count _array > 0) and {(_array select 0) == player}) then {hint "It works! Without lazy evaluation it would throw an error if array was empty."} That means, the evaluation is indeed skipped, when the first compared boolean is false followed by and WHEN the next statement is a boolean too (return type of code in this case). I strongly suspect the stuff above comes from the way "call" works internally. Yes, because that is the same as the lazy-eval example from the BIKI when compiled. {"systemChat 'Abcdefg'; false} is (as code) a boolean statement just like (array select 0) == player. That is how code evaluation works in SQF.

No, it actually is not: Without lazy eval every statement is evaluated before compared by boolean operators. When call Fn_ShouldNeverBeExecutedEver is evaluated {systemChat "You will never see this message if you are programming in properly designed language"; true}; is executed and "true" returned. The if reads than (false and true). Makes perfect sense to me when lazy eval needs to be explicit (there are many other language that do this the same way). The example is the same as: Fn_ShouldNeverBeExecutedEver = { systemChat "You will never see this message if you are programming in properly designed language"; true; }; private returnvar = call Fn_ShouldNeverBeExecutedEver ; if (false and returnvar) then {};

if (false and {call Fn_ShouldNeverBeExecutedEver}) then {}; Works as one would expect when actually using lazy eval. Don't see your problem here, just ranting about a script language that is not fancy JS/Python/C/Whatever. Edit: Ninjad by Fiddi...

No idea. They claim that everything is modular with ACE3. That's all I know.

Yes, there is: Deactivate the ACE Revive Module. That way it is more compatible ;) Sorry, but I personally don't use ACE and I fail to see that it is up to me to make my mission compatible to a third party mod (and I also don't have the time for that). The ACE scripts are the intrusive part here, not the scripts in my mission. Infact my revive script proved to be very portable and friendly to most other mods that don't actively interfere/bypass/overwrite eventhandlers. There exist some workarounds here in this thread, but you have to get your own hands dirty with it. Also I really don't understand why people want to bother with 10 minute "healing/reviving" in a mission that is finished in 2 hours. It is not like the mission isn't hard enough yet (and I can always make it harder).

And the only answer to that is: "It doesn't have a priority". Because nothing "completely new" has a priority at CUP. It is done when it is done. Mostly in a short period of time when somebody feels motivated and without much lead time. It just doesn't work the way that we assign priorities to anything except critical bugs that actually need to be fixed (the latest hotfix for example).

CUP TP runs perfectly on any host I ever encountered (only my Raspberry doesn't have enough space on his SD-card...). What I am saying is: When you "can't" upload 10GB for a mod you want to play, you should either reconsider if you really need that mod or if have a logistical problem with your server/ISP/hoster. Hosting a server just involves uploading large stuff. The terrain pack is big, yes, and why? Because it is a terrain pack where the elevation data for every terrain alone is ~300mb and all assets are from legacy titles. The terrain pack is kind of an ArmA1+Arma2+ArmA2:OA bundle (minus the vehicles). Of course that is big. What should we do? Remove stuff we consider useless? Maybe remove all the takistan rocks or all non enterable houses? Or we can realize the always demanded "Make every terrain standalone, so I don't have to upload them all to my server". Fine... every standalone terrain will than be 1-4 GB in size and all of them about ~30-40 GB. Also the patched versions of terrains will get incompatible. When one terrain is updated, most of the others will need an update too. That would be a shitstorm from the majority that uses all terrains equally.

The mission is palyable for me and many others without that fix. Can you investigate more what is causing this issue for you? Thanks for your feedback. A lot of that stuff was discussed before but I will answer any point nevertheless: 1) When we test we often struggle to get repkits. They are not that common. Most of the time it takes us ~30 mins to encounter an enemy engineer. After that we have to disable an enemy APC/tank to actually use it. That is (especially with CUP/RHS) more harder than it sounds. The mission sould be hard but beatable in ~2 hours. That seems to work perfectly with current roles and item desities. 2) Ingame role assigment is quite new (last patch). Also this mission is focused on small, private squad sessions. Most of the time those groups know who will play what role, so lobby assigment is perfetctly fine and ingame assigment an total overkill. 3) Defintily not. The Mil-Sim squads playing this mission will kill and quarter me. Also I really like the good old role separation. Infact the idea is to even specialise other slots more in the future (reintroduce the radio operator). 4) There are mods for that. Said it before: I don't like addon scripts to missions that are far easier to include via addons on a squad/team basis. Just uneeded redundancy. 5) It is a bug and not intended (infact they circled around perfectly a month ago). They have the loiter wayoint and/or multiple small move WPs in circles, but BI broke the helicopter movement somewhat the patch before the last. When I will have time I will get to that problem. 6) Just an oversight. The system for random clothes is on place but there is only one entry ;) Random heads and classes seems to work fine for me. 7) Two points on this: The loadout of enemies is already randomized but with a small set of possible object on every unit that makes sense. There are basically two problems with totally random loadouts: It is totally unrealistic and takes a lot of the atmosphere. It just doesn't make sense to fight against a sniper with a PK and a nightops without a nightvision but with a 40mm grenade launcher. It just feels better to fight against a 4 man squad that is composed of teamleader, grenadier, sniper and mg-gunner instead if 4 guys with random mgs. The other thing is, you take away a lot of finetuning and gameplay possibilities. For example the only way to get silenced OPFOR weapons is either through luck at an ammo depot or to wait for an specops para insertion (both of them are quite dangerous if not prepared). So I have to disagree with you here. Not the more random the better but the more variety the better. You don't need randomisation if there is a chance for everything in a certain context. It will look believable and won't get boring. 8) It does. There are ~5 times more patrols in urban areas/cities and around landmarks/POIs. Also enemy patrol density shifts in response to the playergroups behaviour. 9) They do (not all of the time). They most likely already unloaded them. Don't get me wrong. I really appreciate any feedback, but a few of the points you mentioned were already widely discussed, some even back in A2. Maybe this is just our different view on how a good mission should look. For me a good dynamic coop mission should feel like a handcrafted and curated mission, even if everything is random and dynamic. I can understand that some people want stuff like "I downloaded Toadies M60, now I want a chance that russian patrols carry one" but that is not how I think the mission should play.

And I am afraid we can't get that authors permission anymore :(

@the1krisrob and @lawndartleo That is a problem with your server hoster. My general recommendation is a real root server. There you can either simply download CUP in browser, use wget or even install steam and download it. Updating CUP takes my squad a few minutes. And there are definitly root server in the same price range than "gameservers". Also you definitly shouldn't use the steam download for upload to your server. We provide a bunch of download mirrors that are not steam and they are preferable for server upload. 80% of all "HALP! CUP IS BROKEN FOR MY SQUAD!" posts here and in the bugtracker exist because somebody downloaded a corrupted addon from steamWS, uploaded it to his server and distributed it with his squad.

I had :lol: On the topic: Not interested in RP but I will definitly look into the taser. I need one for my squad (not for handing them out but for restraining them).

I will check that later. Better create a ticket about that. But I am not sure if we can do something with the ponds except remoing them again. Those bugs are really engine bugs we can do nothing about. We don't play Exile so we have no idea were you find ducttape. Better provide a screenshot and a bugtracker ticket (with the screenshot attached). A screenshot of the garage, not the ducttape of course^^

CUP TP already has a lot of upgraded vegetation and next update will bring more of that (mostly technical not visual). Buying models has several problems: 1) Most licenses prohibit redistribution in any reusable/extractable format. P3D is such a format. 2) Getting vegetation models in ArmA is very hard. 3) Changing models will result in misplaced objects and drastical changed look and feel of terrains but we want the A1/A2 terrains to feel like they did in the old days (but of course with better visual and technology). 4) Such crowdfunding never worked with the ArmA-community (as far as I know)

Not sure why you need the pbo name. You more likely need the worldName and you can get it with the "worldName" command.

Indeed it is.

I was somehow able to stop the issue. Here is what I did: Removed malloc from startup completly. Updated NVIDIA drivers from 362 to 364.74. Freed some disc space, so I know have 15GB instead of 6 GB in C:. Removed GFE and MSI Gaming App. In NVIDIA Control Panel set mode to "prefer performance" and than restarted windows. Ingame I than had stable performance but an quite early LOD switching (trees in 100m distance were two dimensional). Changing texture resolution from "Very High" to "Ultra" fixed that (maybe any change will fix it as switching back didn't reintroduced the LOD switching). No idea what actually helped. Most likely the driver update, the restart and the removing of malloc.

Changing malloc to TBB4 or removing it from startup (and let A3 select it) doesn't make a big difference, it just delay the degeneration of LODs and frames for me: http://images.akamai.steamusercontent.com/ugc/269463939053416250/A924BDFC3F273ABA5E6BFDE6FA7B3D343D40AECF/ I am using an MSI GTX 970, i5-2500k and 16 GB RAM. Afterburner tells me, that while playing A3 the graphicscard goes from 1144MHz to 899MHz (driver is set to "Prefer performance"). While playing neither CPU nor GPU is at maximum capacity.

Same with malloc=tbb4malloc_bi. But LOD degeneration seems much slower.