Tritonv8

If anyone is looking for RHS damage values, I've added a few that we use exclusively from the RHS USF pack. This is just 5.56 (plus vanilla). If you want to add more, just look at http://class.rhsmods.org/rhsusaf/CfgAmmo.html for specifics. class CfgPatches { class Redfield_Bullet_Hits_Value { units[] = { }; weapons[] = { }; requiredVersion = 1.000000; requiredAddons[] = { "A3_Weapons_F", "A3_Weapons_F_beta", "rhsusf_weapons", "rhsusf_weapons2" }; }; }; #define hitvaluecoef 8 class CfgAmmo { class BulletCore ; class BulletBase : BulletCore { hit = 8 + hitvaluecoef; }; class B_556x45_Ball : BulletBase { hit = 8 + hitvaluecoef; }; class rhs_ammo_556x45_M855A1_Ball : B_556x45_Ball { hit = 9 + hitvaluecoef; }; class rhs_ammo_556x45_Mk318_Ball : B_556x45_Ball { hit = 9.55 + hitvaluecoef; }; class rhs_ammo_556x45_Mk262_Ball : B_556x45_Ball { hit = 10.3 + hitvaluecoef; }; class B_56x15_dual : BulletBase { hit = 8 + hitvaluecoef; }; class B_65x39_Caseless : BulletBase { hit = 10 + hitvaluecoef; }; class B_65x39_Minigun_Caseless : B_65x39_Caseless { hit = 10 + hitvaluecoef; }; class B_762x51_Ball : BulletBase { hit = 12 + hitvaluecoef; }; class B_762x51_Minigun_Tracer_Red : B_762x51_Ball { hit = 12 + hitvaluecoef; }; class B_408_Ball : BulletBase { hit = 21 + hitvaluecoef; }; class B_12Gauge_Slug : BulletBase { hit = 24 + hitvaluecoef; }; class ShotgunBase ; class B_12Gauge_Pellets : ShotgunBase { hit = 8 + hitvaluecoef; }; class B_9x21_Ball : BulletBase { hit = 5 + hitvaluecoef; }; class B_127x33_Ball : BulletBase { hit = 18 + hitvaluecoef; }; class B_127x99_Ball : BulletBase { hit = 27 + hitvaluecoef; }; class B_127x99_SLAP : B_127x99_Ball { hit = 34 + hitvaluecoef; }; class B_127x108_Ball : BulletBase { hit = 27 + hitvaluecoef; }; class B_127x108_APDS : B_127x108_Ball { hit = 34 + hitvaluecoef; }; };

Yes, the array is exactly like that and yes, I am aiming for the second position in the array with an index of "1". I will try removing the parenthesis and see if that makes the difference in the UPSMON call. As an aside to this, the script is placing multiple units using "FORTIFY" as well. Those units seem to be behaving as expected. It's just the units spawned not using an optional placement parameter. I have disabled all other calls to pinpoint this issue and make sure nothing else is influencing this behavior. If the removal of parenthesis works for this, I'll remove it in the other calls to UPSMON so the parenthesis aren't getting doubled up. Thank you and I'll advise with the results later today. Thank you for porting this script to Arma 3, it adds some great features and is a welcome addition to A3. Thank you Cool, removing the parenthesis in the UPSMON call did the trick. They now patrol as I wanted without any spam to the RPT. Well done.

"_this select 1" is from an array of markers in the trigger that I'm passing to the script above. I have made sure the names in the array are correct with the markers in the editor as well. They do spawn to the marker called, it's just they won't patrol and the call to the ellipse function seems to me to probably be what's causing it to not work as intended.

I've been hassled by this for a few days now. I've put down a marker, which is perfectly square (it was a rectangle to begin with but I changed it to a square which made no difference). I am spawning units using a trigger with this code: _marker1 = toLower( _this select 1 ); _pos1 = getMarkerPos _marker1; hint format [ "Marker name: %1", _marker1 ]; _side1 = EAST; _units1 = [ "CAF_AG_AFR_P_AK47", "CAF_AG_AFR_P_RPK74" ]; _spawngrp1 = [ _pos1, _side1, _units1 ] call BIS_fnc_spawnGroup; sleep 3; _leader1 = leader _spawngrp1; nul = [ _leader1, "_marker1", "SPAWNED", "DELETE", 300 ] execVM "scripts\UPSMON.sqf"; The units spawn in as they are supposed to and I've hinted that the correct marker is firing the script as well, although they won't move and this is generated in my RPT: 19:20:53 Error in expression <rivate ["_sum"]; _sum = ((_dstX * _dstX)/(_sizeX * _sizeX)) + ((_dstY * _dstY)/(> 19:20:53 Error position: </(_sizeX * _sizeX)) + ((_dstY * _dstY)/(> 19:20:53 Error Zero divisor 19:20:53 File C:\Users\BillGaming\Documents\Arma 3 - Other Profiles\SGT%2e%20Triton\mpmissions\7-75_No_Idea_Yet.Altis\Scripts\UPSMON\Get_pos\UPSMON_pos_fnc_isinellipse.sqf, line 48 To begin with, I'm perplexed as to why an ellipse is being called as I'm not even using an ellipse. Once the units spawn, they just stand there which is obviously not the behavior I'm looking for. in past versions by default, these units would patrol if I'm not mistaken. I'm using the latest version. Any ideas? Late edit: I should also mention that if I throw in the Random parameter, all of the spawned units move to the lower left (0,0) of the map (after spawning at the correct marker location) which means something is definitely awry.

So far removing the modifier key and the show names key (both in AGM options) has allowed me to use the 2x control to toggle raise/lower your weapon.

Fer, I have found the issue and it doesn't appear to be related to Alive. It was because I was using the Massi (7-75 Rangers) units in the editor. When I replaced them with the vanilla Blufor units, the group markers now work correctly.

This is a great framework. I've ran into a small problem though running Alive. I'm just utilizing the group markers component and I can get custom markers working just fine in a map without Alive. The problem occurs though when I use it on an Alive map I'm working on. I have all the player units not profiled, and when using group markers they get the "e0" marker instead of what I set a custom marker to be. I assume this is a conflict with Alive's entity marking feature. Any ideas?

Great mod so far. I use the XTacticalHud and when running AGM the HUD no longer works. Any ideas?

Hello there, I started testing Authentic Gameplay Modification today and noticed XTactical Hud doesn't work when I launch AGM. Any ideas? Thanks

Odd bug with the latest halo drop. There is a vest stuck to your feet or front of body after the jump that doesn't go away until you respawn.

Eric, Here's the specific error if it helps any "No entry 'bin\config.bin/CfgWeapons.Harris_ej'."

We aren't using the U100_tmr_bipod.pdo. @Mav87th: I've checked the load order and we already have them in that order. Even with the latest version of TMR running, we're still getting the error. I'll keep playing with some things but I'm not sure why that specific error came up out of the blue one day.

Hey Eric, We're getting config errors related to the harris bipod upon joining. Does anyone else get this issue?

We're getting the same right now. Even if you move your existing @a3mp out of your mod directory, it still fails.

I'm just curious as to why the Armaholic Frontpage and Play With Six both direct to Arma OH? I was under the impression this was for Arma 3.

SpectreRSG, I tend to agree to a certain extent. Certain variables should definitely be hardcoded. The flexibility I do like here is that units/players can simulate the amount of realism they want in their medical system. That said, in the beta, I think it's probably the right idea to give the flexibility up front so it doesn't crash and burn in the final. Just how much though is a matter of personal taste. I would suggest commenting out your init variables and adding them back in after checking the new release.

We've been having problems with the "knockout" thing ever since the patch with the UI change. We tested the latest update today and still can't get people up the majority of the time. They get stuck in a constant revived/back down state even when there are no other ailments affecting them. I'm hoping you guys get this sorted out soon.

This to me is the best weapons pack so far. The active development and response to user feedback has done wonders to the end result you've been able to achieve here Eric. Great work!

These are looking really good Shammy. I'll be following these closely and look forward to seeing them progress.

We did some tests today with Blastcore disabled. It seems under 30m you take damage that gets greater the closer you get to the burning vehicle. You can see the cross go from green to yellow. It seems the closer you are to the burning vehicle, the faster you go down. 30m may or may not be magic number for taking damage from a burning vehicle. The only thing is, other than looking at the health cross, you have no idea you're taking damage until it's too late and you're dead. Maybe some other visual indication you're taking fire damage as in a game, you can't tell you're burning.

This is a great mod. The visuals are a major improvement over vanilla. Thanks you OS. We've run into a problem were we are getting fried from vehicles 100m+. We had an entire squad get burned to death from a vehicle that was on fire 100m out and also on the other side of a wall. Seems to be conflicting with XMedSys as well. Units are not able to get back to 100 health with Blastcore and XMedSys both running. X39 mentioned it could be related to the EventHandlers.

Some of us are running BC, but not all of us.

Hey Eric, Do you post your own updates to Play With Six? We added your mod to our group using the network for the updates but noticed it hadn't been updated since Jan 5th. No big deal but having played with the newer sounds of the newer versions, it's hard to use the version six is using since it's using the vanilla sounds still.

Hey Eric, everything to date is looking really good. Couple things: 1. We've noticed through VAS that attachments cannot be added to the weapons pack. You can however add them to weapons outside of VAS (e.g. through ammoboxes and from items on your person). 2. After getting attachments on the new weapons and saving through VAS then loading up that slot, the attachments are removed from the rails and gone from inventory (even though they showed up as in that load out through VAS). For the time being we just throw the attachments in our rucks and then slap them on after loading a load out as a workaround. Any idea why this could be happening? We are using ASDG Joint Rails and ASDG Attachments with the right configs in place. Nothing game breaking and we will use them regardless, just some icing on the cake if you may know why this could be. Thanks

These look really good. You've done an exceptional job EricJ.