BlackAlpha

Switching ammo is buggy when doing manual reloads on Russian tanks. Sometimes it doesn't load the ammo you had requested. When this happens, it simply loads the ammo you had fired previously. The bug happens with the scroll wheel actions for switching ammo and it also happens with the RHS Next Round hotkey for switching the dial in the top right of the screen. The bug only happens when manual reload is enabled. So, it does not happen when you turn on auto reloading. The bug happens with all Russian tanks (I haven't tested other factions). Steps to reproduce: - Get inside a T72 and use manual reload. - AP ammo should be loaded by default. Switch to HEAT ammo, then fire and reload manually. - After reloading is complete, HEAT ammo should be loaded. Switch to AP ammo, then fire and reload manually. - Repeat the above steps, keep switching between AP and HEAT after every shot. Eventually you'll run into an issue where it hasn't loaded the ammo you requested.

I'm trying to make a dedicated server run Tanoa. Does the server's Steam account require the Apex DLC? It crashes when loading a Tanoa mission, so I guess it does, but I want to make sure before spending money on it.

Not sure when it started happening but I get the same thing. Repro with BWA v1.3.3: - Put BWA3 Comp ACE file inside BWA3 addons (or any other mod folder you intend to run). - Run CBA, ACE, BWMod. - Start Virtual Arsenal. - Previously mentioned error message shows up. RPT: http://pastebin.com/Xrb0x0Su

Revive (the one used in End Game) stopped working for me and I can't figure out why. It still works in the End Game mission but not in mine. Does someone know how to get it to work in the current game version? The problem is that when a player gets killed, the revive screen shows up, but the timer bar stays full and pressing space doesn't do anything. The weird thing is that I did about 15 tests and the 11 try it did work (even though I hadn't changed anything), until I respawned, then it stopped working. This makes me wonder if it's in fact a game bug. There are error messages that show up. It's either one of the following two that shows up (which one shows up seems random): 19:01:54 Error in expression <_selected,objNull]); alive player && {!isNull _selected && {((_selected getVari> 19:01:54 Error position: <isNull _selected && {((_selected getVari> 19:01:54 Error isnull: Type Number, expected Object,Group,Script,Config entry,Display (dialog),Control,Network Object,Task,Location 19:01:54 File a3\functions_f_mp_mark\revive\fn_reviveProgress.sqf, line 120 Or... 19:14:39 Error in expression < [ "#rev_helper",""]),objNull]); if (isNull _helper) then { _ctrlText ctrlSe> 19:14:39 Error position: <isNull _helper) then { _ctrlText ctrlSe> 19:14:39 Error isnull: Type Number, expected Object,Group,Script,Config entry,Display (dialog),Control,Network Object,Task,Location 19:14:39 File a3\functions_f_mp_mark\revive\fn_reviveProgress.sqf, line 458 19:14:39 Error in expression <te", 0]) == 3}})} do { waitUntil{isNull (missionNamespace getVariable [(p> 19:14:39 Error position: <isNull (missionNamespace getVariable [(p> 19:14:39 Error isnull: Type Number, expected Object,Group,Script,Config entry,Display (dialog),Control,Network Object,Task,Location 19:14:39 File a3\functions_f_mp_mark\revive\fn_reviveProgress.sqf, line 338 I'm using the following settings that worked before (a few months ago at least): Description.ext respawnTemplates[] = {"Revive"}; respawn = 3; respawnOnStart = -1; reviveDelay = 55; reviveBleedOutDelay = 300; reviveForceRespawnDelay = 3; I also tried enabling the revive template in Eden, but that didn't seem to change anything.

Nevermind. The problem is caused by MCC.

True. However, if they feel like they are being damaged in some way they will still try to make you stop (it's within their right). So, for example, if you create a Toyota model and then use it in a game where you drive over innocent people, this may show Toyota in a negative light that might influence people accordingly. Toyota may not like that, they want people to only think of Toyota in a positive way, and so they will probably tell you to stop using their name/car. I'm fairly sure that's why GTA doesn't use real names and changes the cars a bit. If you don't mind potentially making adjustments if they tell you to stop, you can still try using their name/car. If it doesn't portray them in a negative way somehow, they will probably not mind because it will serve as free (positive) advertisement. But if you intend to use the car for terrorists, then you need to be prepared to change things as Toyota may not like that. However, most likely they will never find out or won't even care unless your mod becomes super popular and high profile websites start to showcase your mod. Then Toyota may decide your mod is able to reach and therefore influence enough people that it's a problem for them. By the way, it's virtually impossible to be dragged to court over such things unless you want to go to court. They will first send you a warning. If you ignore it, they'll take you to court. Also, I'm not 100% sure but I think they can only go after the websites hosting your content because creating a Toyota car for your own personal/private use is not illegal. So, the car you made is not illegal. In this case, spreading it publicly to other people is potentially illegal (they will still need to prove this in court), and that's something the website is doing. This is why websites often have strict rules about potential illegal content, they rather take down your mod unfairly than risk potential legal trouble in the future (when you made an account you agreed that this is OK for you). About that warning I mentioned, keep in mind that people's lives have been destroyed by long and expensive legal battles. So even if you are 100% certain your mod is 200% legal, you need to pay attention who you pick a fight with.

I'm trying to get "BIS_fnc_spawnGroup" to work. Specifically, I'm trying to spawn a squad of AI. As a test, I've been trying the following code: _grp = [getMarkerPos "marker", west, 4] call BIS_fnc_spawnGroup; There's a marker on the map called "marker". No errors show up. No units are spawned. The above does not work. Can someone please point out why? What am I missing here?

Zombie mod logics/modules spawn stuff on the server. MCC spawns stuff on the server (or headless client). Zeus spawns stuff on Zeus' machine (the player logged in as Zeus).

Vanilla AI is made to use tactics, covering fire and the other things you mentioned. But for zombies, you don't want that. There's no melee AI behavior in Arma. That's why you must override the vanilla AI behavior using scripts and you must use scripts to give the zombies new behavior in which they run towards people, stop next to them, play an arm waving animation, play a sound and damage the player. The scripts made only work on the server. That's just the way they are made in this mod. It is possible to change that.

The zombies are running scripts that make them move around, play sounds, find targets and attack stuff, etc. Go spawn like 100 units in Zeus next to you. You will probably begin to lag, which will affect other players if the AI units are local to your machine. Even if you are far away, you might still lag because your PC might not be that good. A (good) dedicated server doesn't have that issue. For that reason, in the community I'm in we never spawn in AI using Zeus. We always use MCC and only use Zeus sometimes to control them.

The zombies will only work if they are local to the server. Things you spawn with Zeus are local to the client who spawned them. Hence, the zombies won't work when spawned with Zeus. Things you spawn with MCC are local to the server. So, spawning zombies with MCC works fine. Personally, I modified the mod and made it so you can spawn zombies for all sides using MCC. Makes it quite easy to use and you can have loads of them without any issues (by spawning them in incrementally). Doing that with Zeus might not work as well because the clients lag up very easily, and you don't want whoever is hosting stuff to be lagging or bad things happen for everyone. So, it's in my opinion better to make them spawn on the server (ie. not use Zeus).

True. On top of that, players need a better visual indicator that explains to them how much fatigued they are exactly - ie. a stamina bar like ShackTac Stamina Bar or the stamina bar on the dev branch. Then all the boxes that royaltyinexile mentioned will be ticked off. Let's look at the old stamina system... "Encourages players to consider their loadout" If you carry to much stuff you get tired more quickly and can't run as much. So, you need to be careful with what you carry and sometimes you have to make compromises on what you can and cannot carry. -Check "Asks players to plan their movement" If you run all the time and/or run up hills a lot you'll get tired more quickly. This means you need to take care of where and how you move to avoid getting exhausted. -Check "Rewards players that make objectively better choices" If you take in account the above then you won't be tired as much and have a tactical advantage. -Check "Prohibits players from selecting unrealistic loadouts" If you carry too many things you get tired more quickly. So, you are encouraged not to carry unrealistic loadouts. -Check "Is transparent and comprehensible for players" Implement better feedback in the inventory screen and add a stamina bar (which is something mods already do!) -Semi-check Now, let's take a look at the new stamina system... "Encourages players to consider their loadout" Does it? Sprinting isn't that more faster in this game. As long as you don't max out the weight you don't get punished much. So, you can carry anything you want and not get punished for it if you don't care about the sprint key. "Asks players to plan their movement" You can run anywhere as much as you want. Just don't hold down that sprint key for too long and you'll be fine. But that hardly requires planning. "Rewards players that make objectively better choices" As said above, sprinting isn't that big of a deal in Arma. So in the new system you ask yourself: Do I want to run a tiny bit faster or do I want to carry that MG/launcher/super body armor and a bunch of other items instead? I'd go for the latter. The new system encourages you to ignore fatigue because fatigue in the new system is a non-issue - it almost doesn't exist and you don't need to worry about it. "Prohibits players from selecting unrealistic loadouts" With the new system you can carry an unrealistic loadout and still be able to move and fight effectively quite easily, much more so than with the old stamina system. The new system encourages unrealistic loadouts. "Is transparent and comprehensible for players" The stamina bar certainly helps there and clearly shows to the player the action/reaction of what they are doing. -Check The new stamina system gets one check mark out of five, while the old system gets four - it even gets five if you use mods. It seems to me that the old stamina system is much better. EDIT: The new stamina system has one advantage not mentioned above - it's more accessible. The old system is less accessible. Is it worth it switching to this new inferior system and removing the old, superior system altogether just to make the game more accessible? Surely, there must be a better answer! Why can there not be both? For instance, this could be an option in the difficulty settings, similar to what BIS already does, where they give people the choice between an arcade and a more realistic experience.

You can now literally carry a heavy AT launcher, a big sniper rifle with loads of ammo, a big vest/armor and a bunch of other stuff and you won't get penalized for it. Running, having a ridiculous amount of gear on you, running up hills, jumping, etc will not make you tired at all. I understand that BIS wants the game to be more accessible for the average COD/Battlefield player, but what about your hardcore fans? Could you please at least give us the option to toggle between the current fatigue system and the new one?

Oh, right. I forgot I recently updated it with that.

That is because it starts zoomed out. So, you need to zoom in. Unfortunately, it emphasizes another bug on the scope. Every time you switch to the CQB sight, the scope's zoom level gets reset, which is quite annoying. Looks like a game bug, it happens with all the scopes. Honestly, the best thing right now might be to simply get rid of the 1x zoom level. At least, until BIS fixes the issue. Or alternatively, don't use my file and simply never use 1x zoom level, the scope works fine then.

I experienced the same issue a few times. I'm not 100% certain but I think Alex2k might be right that it happens when there are dead bodies around you.

@gatordev The problem seems to be with certain RHS M4 versions. The one with front grips in combination with the Specter scope all have the issue. Another issue with the Specter scope. The view gets somewhat distorted in a very weird way for a second or so when you look down the scope. This happens when: - Look through scope and zoom out. - Stop looking down the scope. - Now when you look down the scope, the view will zoom in and then a split second later zoom out. It can make you somewhat nauseas after a while. I made a quick fix for it to make it first zoom in a little, before switching to the full zoom level (basically, I reversed the process) and that basically fixes it. Here's the config for it: https://www.dropbox.com/s/ut1uczcnjex57wv/t1_specterScope_fix.pbo?dl=0

In this mod, the Carl Gustav's sight can only be adjusted in 100 meter increments. This is too crude and doesn't allow you to aim precisely enough, making you often miss. The real version uses 50 meter increments. So, is there any chance we might see that in this mod? Really nice mod, by the way!

Drongo asked me for help with this mod and I worked on a new version. Since then, he says he got burned out on Arma modding. So, I'm just going to post the new version here so that it doesn't get lost. Consider this to be an unofficial version. Changelog: - Fixed all aiming problems. - Fixed pre-plotted and FFE missions that you can call from the missions list. - Fixed the artillery interface crash when killing/deleting a controlled artillery unit. - Made the mod compatible with the latest CBA keybinding API. - Changed reload and prep times to more realistic values (based on modern automated systems). - Prep time is reduced when you fire a second time without changing target location. - Prep time is reduced when using a pre-plotted mission. - Fixed some minor errors and cleaned up the code quite a bit. - With ACRE, it only gives you access to the artillery menu if you have a medium/long range ACRE radio. - You can cancel an ongoing fire mission with the End Mission button. - And some other stuff I probably forgot about.

The vehicle is always local to the player who fires the missile, right? The player then executes inside nuke.sqf: [_pos,_yield,_radius] call rhs_fnc_ss21_nuke_fx_damage; Then inside damage.sqf he'll run into: if (!isServer) exitWith {}; I'm thinking that's probably why the nuke didn't do any damage on the dedicated server.

Nuke.sqf, is it run on the server or the clients?

Nice catch. I think you're right. Another thing about the nuke. I noticed that quite often the top of the mushroom (the mushroom itself) disappears after a few seconds. So, you only see it rise from the ground for a few seconds and then it disappears. You then do see the rest of the smoke column and everything else, just the top is missing. It happens in both the editor and a dedicated server on all clients (tested it with two players). I think I pinpointed the problem to the damage function which looks for objects from the center of the nuke and starts damaging them. That function is run on the server only, but somehow it still (indirectly?) seems to delete the nuke special effect on the clients. I suspect due to a game bug, the damage code (after it arrives from the server to the clients?) mixes up what it needs to damage and then instead of damaging an object close to the nuke center, it damages/deletes the mushroom. I think only buildings that were damaged by the server cause this issue. I'm not 100% sure that's the actual problem, however. A way to test the above theory is by running the nuke code on a place with many houses. Make sure there are houses close to the nuke center. The top of the mushroom will disappear. Then run the nuke at exactly the same place again. The mushroom will now show because the server is probably not sending to the clients any damage code from buildings close to the nuke center. Then run the nuke code at places where there are no buildings close to the nuke center. The mushroom should always show up properly at those places. Anyway, I was able to create a workaround by running the damage code first, then doing a sleep for 6 seconds (made it higher than needed to compensate for lag in multiplayer), and then afterwards running all the nuke special effect functions. That way, by the time the nuke special effects play, the damage code has already moved on to different areas (it starts from the center and works its way outwards) and thus won't accidentally delete the mushroom.

I think I figured out where the problem lays with the not working nuke on a dedicated server. This code successfully creates a mushroom cloud when I run it on my machine: [] spawn { _pos = (getpos unit1); _yield = 10000; _radius = 20 * _yield ^ 0.4; _core = "logic" createVehicleLocal _pos; [_pos,_yield,_radius,_core] call rhs_fnc_ss21_nuke_fx_smoke; }; So, I'm guessing the problem lays with: rhs_c_rva\rhsafrf\addons\rhs_c_rva\scripts\nuke\nuke.sqf Line 14 Something there is making it so the smoke function is not run properly on the clients. There's probably more wrong with the whole nuke thing on a dedicated server because, like I said previously, it does no damage. But I don't have time to look into that. For now, all I need is the nuke special effect.

I'm trying to fire the 9m79b on a dedicated server and I can't get it to work. More precisely, I don't see an explosion (mushroom) and the AI infantry don't die, so it appears there's no damage being dealt by the missile. I tried it with both AI that is local to my machine and local to the server. I tried spawning a 9m79b on the server, but then using the fire control feature it does not fire the missile (pressing the launch button does nothing). I then tried spawning a 9m79b using Zeus (which spawns it on my machine), then I could fire it. However, when the missile impacts (I see it impact), I only see the flash and I hear the sound, but there is no mushroom and the AI stays alive (no damage). I also tried it in singleplayer (editor) and it works 100% fine there. Am I doing something wrong or is the 9m79b simply not multiplayer compatible yet? EDIT: Figured out why the launch button doesn't work on the vehicle spawned on the server. The engine does not automatically turn on when you get the vehicle into the firing position. So, you manually need to turn on the engine, then it will fire. But the no mushroom, no damage problem is still there. I did notice that every now and then the missile itself will do damage (in like a 200 meters radius), but there's no mushroom and it should do damage in a bigger radius. EDIT2: I did some testing by triggering the nuke through scripting using this: [(getpos unit1), 10000] call rhs_fnc_ss21_nuke; It works in singleplayer. In multiplayer, doesn't matter whether I run that line on the server or my client, there's only a flash, a sound, but no mushroom.

But now it's the first of April. So you can't trust anything anyone says today... I hate this day of the year.