The_Captain

From the VBS2 VTK website: "Hand Signals VBS2 now supports gestures (separate upper torso animation), which are used to provide hand signals and also reloading on the move." http://virtualbattlespace.vbs2.com/index.p....emid=79 If Arma 2 also supports hand signals and reloading on the move (which it is purported to), with separate upper torso animations, does this mean we could see weapon-specific carry animations? IE, a separate upper torso animation could be defined for specific types of weapons, like rifles with grenade launchers, so we see less weapon-clipping. Not for all weapons, but just for the ones which would be most likely to have visible clipping problems. This would be a welcome development, but since I don't know how much effort this would entail, I don't know how feasible it would be. Still, defining separate upper torso animations for different weapons would be a LOT easier than doing a brand new set of full body animations for a new weapon type. Here's hoping. (Hey, maybe it's even possible to have a few weapon-specific reload animations too...)

As has been mentioned a few times, AI grenade launcher aiming seems to be buggy. AI tries to kill you and always manages to miss, usually by 20-100 meters, even at point blank range! Unless the target has a wall or hill behind it, AI grenadiers are pretty much useless. This eventually frustrated me to the point where I decided to see why their aiming was off, what the problem was, and how it could be corrected. So, here's... The Captain's AI Grenadier Fix EDIT: v1.01 had a nasty bug where all rifle fire from grenadiers got messed up. Download v 1.03 below! (Short) Youtube video of default behavior, and the fix: Download v1.03 from: Armaholic: http://www.armaholic.com/index.php?m=single&id=3656 ArmedAssault.info: http://www.armedassault.info/index.php?cat=news&id=1155 ePrison.de: http://www.eprison.de/files/148/4539 FileFront: http://files.filefront.com/TCN+Gre....fo.html Change Log: ---------- v1.03 - 08/16/2008 - Added server key (TCN) and signed addon, Fixed possible unneeded text display in 1.02 (sometimes showed grenade name in chat when firing) v1.02 - 08/15/2008 - Fixed aiming offset being applied to all fire modes of grenadiers. Added 2nd example mission showing grenadiers using both grenades and rifles. v1.01 - 08/15/2008 - Functions only compile once now, instead of once for every unit. v1.0 - 08/14/2008 Multiplayer: Can be used Server or Client side. (Server needs it for server AI, clients need it for client AI. Can be used just on a client, but fix will only affect that client's AI). MP Key uploaded to OFPEC: http://www.ofpec.com/tags/index.php?action=details&tag_id=1655 Requires Extended Init Eventhandlers addon. http://www.flashpoint1985.com/cgi-bin....=70816; Example mission included. This addon corrects for an Arma bug that seems to have been present since grenade launcher sights were introduced. AI Grenadiers aim about 10 degrees too high when firing their grenade launchers and thus they will always miss their target. It seems as if their AI code raises their arms too high, probably having something to do with the memory points on the weapon. It was pointed out to me that "GL look" and "GL_Eye" are about 11 degrees offset from the direction of the barrel. This addon adds an 'fired' eventhandler to every unit that changes the flight path of AI fired grenades to be 10 (or so) degrees lower than their original flight path, allowing grenadiers to hit their target almost every time. The addon is essentially a hack, since it doesn't actually fix the problem, but instead corrects the aim of launched grenades. My hope is that the bug will be noticed and fixed officially in the next patch, so this addon is never actually needed. The eventhandler only works with predefined weapons. To add your own weapons (or change the default settings), edit the TCN_GrenadeFix_config.hpp and add your own types and their proper offsets. I'm not sure the offsets I included are correct, so feel free to change the default settings. AI With low skill levels (.25-.5) seem more willing to fire grenades, while highly skilled AI (>.75) tend to fire rarely at isolated infantry targets. To test the addon, try AI with lower skill levels. Hopefully the aiming bug will be fixed in the next Arma patch. Bug List: --------- AI still think they're firing at their old elevation, so they may assume they can fire over the head of someone in front of them, while the script moves their grenade 10 degrees downward. Sometimes this results in friendly fire. Fixed in 1.02: All fire modes of the grenadelauncher had the offset applied, causing all rifle fire to hit the ground in front of the soldier. Fixed in 1.03: Occasional display of unnecessary globalchat text when grenadiers fired their weapons. Fixed. Notes: -------- The addon uses General Barron's GetPitchBank and SetPitchBank functions. My script is inefficient, as it first gets the pitch and resets it again. I plan to rewrite it doing a single vector transformation instead of running the getpitchbank/setpitchbank functions. Because each weapon model is different, each offset must be defined separately. Checking ammo and muzzle type don't work: GP25's actually use 40mm ammo, and M16's and M4's both use M203Muzzle. The addon does use a settings file in the DTA folder for custom weapons, and I think it throws an error if you try to run the game without the file. However, since I had to define weapon types explicitly, this does make it easier to add new weapons. Troubleshooting thread: http://www.flashpoint1985.com/cgi-bin....1275057

Looks like, in the most recent screenshots, some weapons have weapon-specific carry anims (especially the grenade launcher weapons). Good job BIS.

Sorry you've been having problems, popcorn. I think the issue might be due to the missing semicolon on the line where I call the grenade handler, as it probably stops the events for the tank FCS from working. I downloaded the TankFCS and I did not have any compatibility problems, however (Only using TankFCS, ExEh1.7, and AIGrenFix). I'll release a hotfix with the typo corrected which will hopefully solve the issue. Popcorn, did you have any other addons loaded? I'm curious as to what is causing this issue because I can't reproduce it yet. Thanks for your help.

RE: the video. Things I liked: -Animals, vehicles, etc. -Terrain detail and large viewdistance -LOTS of vehicles and factions in the editor, including LAV which I was hoping they'd add. Variety looks incredible. -First person fighting and movement in the village. Looks pretty smooth. -Smaller, more realistically laid out villages. Things I didn't like: -'heart' symbol showing health in the helicopter, unless it was an armored shield instead. Seems a bit unprofessional for some reason. -No 3d option for the editor yet, it seems. Hopefully this will be included as this is WIP. -Looks like you still can't move while holding binoculars. -Vehicle destruction: -> turn black, then explode, without a good 'hit' effect. Why can't the 'turning black'/texture swapping be after the explosion? It looks odd. -No demonstration of actual missions or MP, would be nice to see some snippets from these. -AI movement and pathing which required them to go around small fences. This makes their behavior seem less intelligent. I think if the villages have so many tiny fences, AI and players need to be able to climb over them... otherwise AI is just going to end up super confused in urban areas (And players are going to be annoyed). Of course, I'm nitpicking. Overall it looks incredible and already quite polished. Great job BIS, I'm looking forward to playing the final version next year!

In the third picture his hand is going under the launcher. My guess is the "safe" anims haven't been redone, but the regular 'combat/ready' ones have.

Not sure if this has been noted, but it looked like we get animated machinegun reloads: (Feed tray cover on this M240 is up) http://images.gamestar.de/images....rop.jpg

Thanks for the report gl33k, I'll check that out tonight.

I think you're going to always have to update every client's money variable (with the name of the player) to the server whenever they change it, since when a client disconnects you won't have access to his local money variable. Then, when a new player connects in that slot, compare the names, and if they're equal the server should set the client's money to the stored value. What I would do: (or something along these lines) Make a unique variable for each client slot that each client will use to update their money (EG w1_money, w2_money). Add an eventhandler on the server for each of these variables that saves the current player name and money variable in a small array w1_money_array = ["DaChevs",10000]. Then when a player connects, check the array for their slot to see if the names are the same, and if so, have the server update the money for that slot (W1money, etc) to the new value. You'll need to make sure, though, that when a client connects he doesn't initialize the money to 0 AFTER the server updates it to the correct amount. Also, since the publicvariable event handler doesn't fire on the computer that updates the variable, you'll have to save the array + name locally in case it's a player who has a server+client on the same arma instance. I can help more if you need it.

Thanks for the mirrors and feedback everyone. @Popcorn: That method would work as long as the "muzzle" of the RHS weapons are also the same as the BIS muzzles. The muzzle definition only applies the fix if the weapon's muzzle is the same as the definition. I don't know if the RHS weapons use the same muzzle name (or if they inherit from BIS weapons), but I can go download them and check. (It would be in the cfgWeapons.cpp). I also don't know if the aiming offsets are the same, but since most AK's use the same launcher, it should also be 10. If you have a new muzzle name you could write: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class RHS_AK103GP30 : AK74GL { muzzles[] = {"[RHSMuzzleNAME]"}; }; DMarkwick: Gah, that's also my fault for not adding a semicolon in the exEH definition. Thanks for catching that. I've been using exEH 1.7 (and also using your smoke effects) so I didn't notice the error.

Thanks for the feedback and testing everyone. Okay, one last update, this one adds a dedicated server key for those who want to use it in multiplayer. Thanks for being patient with the updates, guys, as this is my first addon. (Normally I make missions...). learned a lot about the process of making an addon... more work than I expected. And all I wanted to do was write a simple vector transformation for grenades... Next time I make an addon I'll do all of these steps before I upload the first version (server key, better example missions, etc), as well as make sure to test any last minute changes before I pack something up! v1.03 will be the last major update of this fix. If I update/rewrite it, I'll simply put the update in the addon pack I'm thinking of releasing (see below for details). Change Log: ---------- v1.03 - 08/16/2008 - Added server key (TCN) and signed addon, Fixed possible unneeded text display in 1.02 (sometimes showed grenade name in chat when firing) http://files.filefront.com/TCN+Gre....fo.html Key uploaded to OFPEC: http://www.ofpec.com/tags/index.php?action=details&tag_id=1655 I'm considering also releasing a pack of addons with some of my other personal fixes. Some of these include: -Tank Damage Fix: Tank crews stay inside tanks when the tank's treads/engine have been disabled. Modifies fuel value to trick AI, without modifying vehicle configs (and therefore can apply automatically to all armored class vehicles). -Javelin fix: Adjusts trajectory of Javelin as it approaches a target to guarantee a hit (default BIS Javelins tend to miss by <1m or clip through vehicle). Much simpler than Mando's javelin replacement. -BMP/Shilka Commander Turret Fix - Adds a dummy weapon to the commander turret of these vehicles so you can look around when turned out, in external view, and use the command menu which is broken by default. -Disembark Troops from vehicles - The commander of a vehicle with more than one cargo position has an action which tells all AI troops under his command to disembark in order and move away from the vehicle. Useful when player is commander of a vehicle and needs troops to quickly exit without needing to use the command menu. -Keep original vehicle commander Fix - When a player gets in the back of a stryker (or any land vehicle), he becomes the 'commander', and the Ai crew turn out for some strange reason. This fix makes sure that when a player gets in a vehicle and his AI are the crew, that the AI retains command of the vehicle. Sound like a good set of addons for a small pack? Would you prefer the fixes bundled into one addon or separated so they could be used individually?

Anyone ever wonder why grenadiers never hit anything? Well, it seems to me that AI grenadiers in Arma tend to always overshoot their targets. It seems like their point of aim is too high, and the grenades go way too far. I've been noticing this in general gameplay for a while but I don't know if it's been fixed. I made a quick test mission where I tell AI to target enemies (but not shoot), and give them a manual command to fire using a gamelogic: they completely overshoot the targets by about 100m or more when aiming at their selected aiming point. Looking at an AI soldier and elevating my weapon to reach the target, I noticed when I commanded the AI to target the same target they raised their gun by about double the elevation I did. I'm not sure if this is a problem with the AI aiming routines or the configuration of the launchers, but whatever the case it seems broken. ... Okay, a few hours later and some tests.. it turns out AI grenadiers aim exactly 10 degrees too high. I wrote a simple function that grabs a grenade when they shoot it and alters the vector to be 10 degrees lower. (Thanks to general Barron for get/set pitch and bank functions!. Now the AI consistently hit targets. I'm not entirely sure my 'fix' works correctly, but it seems that this is a genuine bug in the AI indirect aiming routines. Maybe it could be fixed in the next patch... If the fix is reliable I might consider releasing it as a small addon. (And maybe posting a video too...). Here's a bit of my test data when I was trying to see what the AI's aiming offset was, targeting a target at so many meters, the AI's vertical angle, and mine that actually hits the target: Tgt: 211m AI: 18.6559 Me: 8.01 Tgt: 162m AI: 17.22 Me: 6.33 Tgt: 137 AI: 15.6756 Me: 5.255 Tgt: 106 AI: 14.01 Me: 3.75 Tgt: 76 AI: 12.5085 Me: 2.5 Originally I figured it was a problem like aiming 30% too high, but it seems it's simply 10 degrees too high, always. Edit2: Here's a video of the default behavior, and the fix. You can download the 'fix' here: http://www.flashpoint1985.com/cgi-bin....1277024 The fix doesn't actually fix the bug, it just fixes the velocity vector of the grenades. Hopefully this will be fixed in the next arma patch...

72hundred over at armed assault.info noticed that grenadier's normal rifles are messed up: When I added in custom rifle handling last night, the check for which "muzzle" was being fired got screwed up, so at the moment their regular rifle shots are screwy. Fixing it now. Sorry for the mix up. Edit: Fixed version 1.02: http://files.filefront.com/TCN+Gre....fo.html

DMarkwick:When I was first uploading 1.01, I typoed when inputting Q's change, and quickly replaced it with a 'fixed' 1.01. It's possible you got the messed up interim version. All my fault. (The ArmaHolic (which I just downloaded to make sure), and the FileFront mirrors both have the correct v1.01. if you don't want to redownload, you can unPBO the addon, hop into config.ccp and make sure Extended_Init_Eventhandlers reads: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Extended_Init_EventHandlers { class All { // run init function to process custom grenade offsets TCN_GrenadeFix_Init = "if (isNil 'TCN_GrenadeInit') then { TCN_GrenadeInit = call compile preprocessFile ""\TCN_GrenadeFix\TCN_GrenadeInit.sqf"";};"; // Compile functions for fired EH to quickly run when the shot is fired. TCN_GrenadeFix_Fix = "if (isNil 'TCN_GrenadeFix') then { TCN_GrenadeFix = compile preprocessFile ""\TCN_GrenadeFix\TCN_GrenadeFix.sqf"";};"; TCN_GrenadeFix_Fired="if (isNil 'TCN_GrenadeFired') then { TCN_GrenadeFired = compile preprocessFile ""\TCN_GrenadeFix\TCN_GrenadeFired.sqf"";};"; TCN_GrenadeFix_GetPitchAndBank="if (isNil 'TCN_GetPitchAndBank') then { TCN_GetPitchAndBank = compile preprocessfile ""\TCN_GrenadeFix\GetPitchAndBank.sqf"";};"; TCN_GrenadeFix_SetPitchAndBank="if (isNil 'TCN_SetPitchAndBank') then { TCN_SetPitchAndBank = compile preprocessfile ""\TCN_GrenadeFix\SetPitchAndBank.sqf"";};"; }; }; One of those lines (can't remember now) had an extra '};' thanks to my cut-paste magic. If you don't get an error on boot then you have a proper version. Sorry for the mix-up.

Thanks, Foxhound! Uploaded version 1.01 with Q's suggestion to improve performance. I'll look into the model checking, might be able to get that to work as well. Clients and server both need the addon. Server needs it for server AI, clients need it for client AI. I could write a serverside version that modifies all ai, even non local ones, but I don't trust the server in that case. Also, it might conflict if a client is also running the addon at the same time.

Posted my clientside addon which corrects for the bug. http://www.flashpoint1985.com/cgi-bin....1277024 Hopefully this will be fixed in the next patch and the addon won't be needed.

My post mostly references berzerk but some other PvP maps fit my notes: It's hard to find something to communicate about when player density is often extremely low (10 players in 1x1km^2?), and when you run into an enemy, often he kills you without you knowing, or you kill him without him knowing. If I spot an enemy, I'll kill him. If I don't spot him, he'll likely have killed me. Since players can respawn anywhere, and often instantly, with high powered weapons (m24, javelin, etc), you have no idea where you will encounter anyone: they could be anywhere. Engagements happen at unpredictable times and they are over so quickly that there's no reason to spot enemies or ask for help. Not to mention, you don't lose berzerk, you just score points and wait for the time to expire. If *anything* the other team did caused a team to lose early, they might see a reason to communicate (telling each other where the tank is that's about to take the last CP and win, maybe). Communicating thus can't help you kill people, and can't stop you from losing. All it can do in this case is help players coordinate to kill others, but with freely respawning enemies, protected spawn zones, and no way to win the game early, there's not much of a reason to do that either. Thus, there's not really much to communicate to someone on my team about, and no reason for me (or other players) to do so. If players figured they could win by communicating, or realized that a lack of communication is what caused them to lose horribly and embarrassingly, they would start to actually communicate. It's more the mission's fault than the player's fault, in my opinion. Missions that punish players (killing lone players, etc) for acting alone/not communicating/etc give *negative* reasons for players to work together, but you might as well design the game so that people have a positive incentive to perform the behavior you want. My cents.

I was surprised when I finally got around to watching the first episode, because I didn't realize I had already read the book in 2004 and enjoyed it. (The title of the show was so generic and I figured it must have been more of a documentary). It was quite nice to see the book brought to life, with all the colorful characters. Not too many books actually are done justice when brought to TV or film.

http://community.bistudio.com/wiki/unassignVehicle This command will make the player be no longer assigned to the vehicle. You could attach it to an eventhandler for "getout" like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _vehicle addeventhandler ["GetOut",{if (isPlayer (_this select 2)) then {(_this select 2) unassignvehicle true};}];

Spooner from OFPEC gets the credit. He wrote a script (SPON_Status) which overrode the built in scoreboard with his own order of battle display. I pored over it for a long time trying to figure out why it stopped the scoreboard from displaying, and it turned out it was the return value of 'true'. His core package: http://www.flashpoint1985.com/cgi-bin....=74601;

Inside your display event handler, return true' as the very last statement. That will override all default arma key behavior, for any key. (I had to use this trick also to make use of F1-F12).

Aha! Nice find heinbloed! This probably changed when BIS enabled the gl-iron sights in one of the patches... but AI still raise their barrel the 'correct' amount without realizing they're overcorrecting. Also, I made a quick clientside addon that uses the velocity change if anyone is interested. (Though might be better to fix it in the actual model...)

Also, from the tests I did, it seems ai grenadiers of a lower skill use grenades more often while high skill (>.75) just aim and don't fire like you mentioned, vilas. Maybe it has something to do with their cost routines, or their perceived "chance to hit target", but the "smarter" soldiers never use grenades. Skill of 0.1 and they use them nearly rapid fire. You can test this by removing all regular magazines from a group of grenadiers, eg: {_x removemagazines "30Rnd_545x39_AK"} foreach units group this; I wouldn't really want a scripted fix in the community configuration project... I'd like it to be fixed either in the code or configs. I'll look into what SLX did... maybe it can be fixed in the config after all. (Edit: one small bug already: AI might think it's clear to shoot over your head, but the script pulls the path of the grenade down.. sometimes right into you.)

Disable map = when you bring up the map, you get a black screen? http://community.bistudio.com/wiki/Description.ext#Miscellaneous You can disable the map (and gps, etc) by setting the showMap option in the description.ext. I think you can also disable it in mission with the scripting command http://community.bistudio.com/wiki/showMap If you mean disable the GPS (which has the red circle), you can use showGPS instead.

In short, that probably won't work. The respawn delay is hardcoded once its defined in desc.ext. You're going to have to write a custom script which keeps respawned players in a "holding area" until your respawn script waits the amount of time set in the param (and probably shows a camera view of their body and a timer countdown), then kills the camera and puts them at the respawn zone you want. In this case you should probably set the desc.ext respawntime to be 1 or so so they always end up at the holding area before your script manually 'respawns' the players.