madrussian

Thanks for your time and energy ironing these out. Â The broken animation transitions have indeed bothered me more than anything else regarding ArmA. Â I can hardly wait to see them all working seemlessly! I have a some dynamic mission ideas in mind... Â Fixes like yours really go a long way to provide the motivation to keep creating!

I have always been extremely bothered by this as well. Â Thanks for calling attention to this Crunch. Maybe BIS include a disable for this in the next patch? Â And while at it a toggle for the god-awful mouse-auto-center? Â Assuming that ain't gonna happen for ArmA, hopefully for ArmA2? Â (Mouse-auto-center toggle was in the top ten voted for of reported issues in the bugtracker.) In the mean time, can anyone who knows configs clue us in on how to disable this automatic look "feature" described by Crunch... I will owe you one hundred beers!!! Â

Awsome fixes indeed!!! Â Many thanks for this great work. I can only find two animation transitions that are still broken. Steps to repeat the problem: 1. Stand (rifle raised or lowered, doesn't matter) 2. Press and hold "Turbo" 3. Press and hold "Strafe Left" 4. Finally press and hold "Move Forward" Substitute "Strafe Right" into step 3 above for mirrored problem. Â (These produced with no other mods running.) Is it possible for you to fix these two as well? Â If so, we will finally have a completely glitch-free stand alone animation system... for the first time in the history of ArmA! Thanks again for the mod.

Hope this isn't a repeat, but this is from IGN's E3 preview: I really hope they follow through with this!!! But why just two players? Â Maybe because certain missions only have two men, like maybe a sniper mission? Â If that's the case then why not just limit it to two in that mission?

You may also want to look into: PROPER Animations Fast Forward Transition Its purpose was to speed various things up, but I was able to tweak it a bit to slow various things down (mostly jog and sprint). Â It's possible you'd be able to get at what you are after as well. Good luck with it.

Thanks for the heads up Victor. Â I actually just got done submitting my last post and then realized the new trailer was out when I saw your post above mine. edit: Still need to get home and watch the new one for myself! btw- Â In case any have missed it, check out the teaser trailer too.

These OFP2 screenshots may be renders, and they definitely are amazing, but what I am most interested in is: Are the animations real? Some of them are staged obviously, but what I'm talking about here is the way the soldiers move.  If these are the real animations, we are in for a huge treat!  Go back and watch the teaser video again (or hopefully the new video tomorrow).  Those guys hunker down in a most realistic way, and they do so to different degrees.  Watch it again if you are not sure what I'm talking about.  Based on the switching back and forth between different combat stances, I can only surmise we are watching real animations.  Also in OFP2 (again based on the teaser) the men move at spot on realistic speeds as compared to watching real footage of the soldiers in Iraq... indeed in OFP2 they move just like you would expect in real life.  The human body has limits, and there's complete fidelity with respect to real life physics in the way the bodies of the men in OFP2 are capable of moving.  Immersive as it gets. So many games speed things up (as compared to real life) and that's a real immersion-breaker for me.  ArmA is no exception.  In ArmA, this is especially noticeable in acceleration/deceleration.  I'd love to see someone in real life loaded down with full combat gear accelerate/decelerate from a dead stop like that!  It just doesn’t happen.  (And I'm not just talking about the broken transitions here.)  Also note that in ArmA the leaning is not realistic at all (i.e. bend at the waist and everything below the belt stays.completely static).  These observations are not meant at a slam against BIS or ArmA (probably the most versatile and capable simulations in existence thus far), but simply to offer a comparison to what I'm seeing with OFP2.  Hint hint BIS for ArmA2!  Let's hope these movement animations in the OFP2 teaser video are real!!!  And let's hope nothing has changed in this respect with tomorrow's video! (since the teaser) EDIT: Oooooo... now I gotta go see the new trailer for myself!

First of all, the fact that BIS is looking to use revive in the campaign tells me that they are aiming for a coop campaign.  If this is the case then I’ll be jumping for joy, along with the vast majority of you out there who are into these types of games! I make this revive->coop campaign conjecture from a design perspective.  Unlimited revive (as opposed to limited revive) is a coop mission designers crutch, if their target is accessibility.  (Gears of War anyone?)  It certainly makes things easy for them.  For example, with unlimited revive, if at least one squadmate is alive, the mission can continue.  If all squadmates are killed, then the mission ends.  Convenient, no?  But this is a very lazy way to go about it imo.  Not to mention that for all the benefits of a revive system, lets face it, revive is quite unrealistic.  As in, “Oh look, my buddy just got shot… Oh well.  Here, I’ll jab him with this needle.  There, he’s back up and at it, right as rain!†Imo, there are much betters ways to handle death in a coop campaign.  For example, what is wrong offering up replacement soldiers between missions or perhaps periodically throughout certian missions?  For that matter, why do we need to replay the current mission at all (tedious) if we all die?  We’re in the middle of a war, right?  Shouldn’t the conflict go on?  We all just died in blaze of glory…  Why not track the results of that mission (where we all succumb) and let we the players continue, taking over as other soldiers who continue the fight nearby in a new mission which occurs, in part, based on our previous brave and posthumous actions?  Now, keep the fear of death alive with appropriate consequences, of course, but do we really ever need to replay static missions?  I think not!  Much more immersive that way I think (my opinions of course).  For any games coming out anytime soon, I’ll keep my fingers crossed, and my expectations low. (i.e. Fewer disappointments that way) In the mean time, if there is to be revive in ArmA2, please allow us maximum latitude to configure it as we see fit, including a “limited†option (see below) and the ability to turn it on or off, in multiplayer, and in single player as well. In terms of revive options, I feel that at a minimum, we need the ability to adjust the following: 1. Whether a revive kit (inventory item) is required and expended per revive. 2. Number of times a player may be revived per mission. 3. Number of times a player may revive another per mission. I’m anxious to see what BIS comes up with.  Of all possibilities, please, please for the love of god, avoid an imposed, hard-coded, and worst of all unlimited revive. Â

I'm really looking forward to this island! Â Great work so far! Without having read the entire thread, any chance for two seperate versions, one with buildings/roads, and one without? This would make the perfect uninhabited island in the middle of the ocean, for a /shipwreck(or plane crash)/exploration/survival type mission. Â Then once you get in a ways, maybe it's not really completely unihabited after all... Â

Some great stuff here Kegetys... Many thanks!!! Now, maybe someone will use a combination of these beauties (setMousePos, getMousePos, and/or getMousePosRelative) to combat the evil ArmA hardcoded mouse-auto-center while driving!

Hello. Â With the final patch out now, there are still some missing animation transitions. Â Sakura-Chan had thankfully fixed some of them a while back, but there are still a few problems left. Â With so many things working so well now in ArmA, I thought I'd take a crack at fixing the remaining broken animation transitions for once and all. I've got a decent handle on how the transition system works after looking at what Sakura-Chan did... or well I thought I did. Here's a chunk of the code that should affect transitions from Sprinting Forward Erect with Rifle Raised, or in the anim code "AmovPercMsprSrasWrflDf". Â (You may want to widen your browser to see this correctly): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">... class AmovPercMsprSrasWrflDf : SprintBaseDf { connectTo[] = {"AmovPercMstpSrasWrflDnon", 0.025, "AmovPknlMstpSrasWrflDnon", 0.1, "AmovPercMsprSrasWrflDf", 0.1, Â "AmovPercMrunSrasWrflDf", 0.1}; connectFrom[] = {"AmovPercMstpSrasWrflDnon", 0.025, "AmovPknlMstpSrasWrflDnon", 0.1, "AmovPercMsprSrasWrflDf", 0.1, Â "AmovPercMrunSrasWrflDf", 0.1}; interpolateFrom[] = {"AmovPercMstpSrasWrflDnon", 0.025, "AmovPercMrunSrasWrflDf", Â 0.02, "AmovPercMsprSrasWrflDfl", 0.05,"AmovPercMsprSrasWrflDfr", 0.05}; interpolateTo[] = {"AmovPknlMstpSrasWrflDnon", 0.1, "AmovPercMstpSrasWrflDnon", 0.025, "AmovPercMrunSrasWrflDf", 0.02, "AmovPercMsprSrasWrflDfl", 0.05, "AmovPercMsprSrasWrflDfr", 0.05}; ... First of all, it seems obvious that the numbers here are lengths of time over which the transitions occur. Â So in an effort to see how everything here is associated, I started to modify specific numbers to see if I could detect any change in game. Â Idea being, if I set one of the periods of time to a big number, like 3, that particular transition would be easily recognizible. Â (btw- I was using the animationState command in the editor to verify which animation state I was transitioning from and to.) Unfortunately, I wasn't having much luck, so I tried a blanket approach (changing all of the numbers to 3) to see if that would do the trick, like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">... class AmovPercMsprSrasWrflDf : SprintBaseDf { connectTo[] = {"AmovPercMstpSrasWrflDnon", 3, "AmovPknlMstpSrasWrflDnon", 3, "AmovPercMsprSrasWrflDf", 3, "AmovPercMrunSrasWrflDf", 3}; connectFrom[] = {"AmovPercMstpSrasWrflDnon", 3, "AmovPknlMstpSrasWrflDnon", 3, "AmovPercMsprSrasWrflDf", 3, "AmovPercMrunSrasWrflDf", 3}; interpolateFrom[] = {"AmovPercMstpSrasWrflDnon", 3, "AmovPercMrunSrasWrflDf", 3, "AmovPercMsprSrasWrflDfl", 3, "AmovPercMsprSrasWrflDfr", 3}; interpolateTo[] = {"AmovPknlMstpSrasWrflDnon", 3, "AmovPercMstpSrasWrflDnon", 3, "AmovPercMrunSrasWrflDf", 3, "AmovPercMsprSrasWrflDfl", 3, "AmovPercMsprSrasWrflDfr", 3}; ... Still no change. Anyhow, I'm a little baffled here. Â Does anyone have any experience in this area or perhaps some suggestions? Thanks in advance. MadRussian

Awsome! Too bad I am stuck at work atm. Â Anyone tried out the new Southern Sahrani yet? Â I'm curious what is different specifically?

@Nicholas Bell If you get them up and running in Visitor, are you going to add them to your Schmalfelden map? Please? Â Pretty please?!? Or have you started a new project? Maybe they fit on Schmalfelden (setting wise) and maybe not, but they sure looked spectacular when I added a bunch of them kind of ad-hoc like to an empty intersection in the editor and used setVectorUp [0,0,1]. Â If an expert map-maker like you gets to working with these, I can only conclude that the results will truley amaze. Someone help this man!

Just came across this... Sounds very interesting. Â A quick question for you Rommel: One of the things that has always bothered me about ArmA/OFP is the lack of self preservation the soldiers seem to have. Â The biggest part of my frustration here is related to how a group of soldiers (most without any AT weapons) will just stay put and get wiped out when, for instance, an enemy tank rolls up. Now it's not like they don't see the tank coming. Â Due to the way ArmA is set up, in almost all cases the infantry will detect the tank well before the tank detects them. Â One would like to see the infantry clear the street and seek cover immediately, scared to death of that steel beast rolling up. Â Instead they just stand there and get wiped out. From what I'm reading so far, it appears your script would, in this case, cause the infantry to scramble for cover, but only once the tank started firing at them. Have you considered adding the ability to take cover before the shooting has started? Â Maybe your script is just the place for something like this?!?

Yeah, I have to agree with NoRailgunner on the pajama camo. Â It's not really camo at all like that. Anyhow, I am really looking forward to the full release. Â Can't wait to see some civies!

This one sounds interesting: But I can't seem to get it to work. Â Can anyone confirm this still works as of the latest Beta? If so, please elaborate on just what you did. Â Thanks!

I was just doing this the other day. Haven't tried forceSpeed, as people are reporting is does not work currently. Â Instead I used limitSpeed. According to Kronzky's note on limitSpeed: So I used limitSpeed on a loop, and it worked like a charm. Â I don't exactly recall the delay I was using. Â I think somewhere around 1-2 seconds. Â Worked great though. It would be nice to have these commands working as they are suppose to be though, w/o having to resort to such things. Another idea is to put your truck in the same group as the infantry, making sure the group speed mode is set to "LIMITED" or "NORMAL". Â But if you do this you'll run into all kinds of trouble with pathfinding, especially with trucks, and especially when there are many obstacles (i.e. in the cities). Anyhow, good luck with it.

Thanks supershooter. Â I will check that out tonight!

A while back, I was having an interesting problem: After creating a camera and targeting it on the player, I could still control the movement of the player. Â After doing some fiddling, I eventually solved the problem, taking away player control over his character while the camera was focused on him. Â At that time, this was a big issue until I fixed it. However, for a mission I am creating now, I actually need this ability for the player to move his character while the camera is focused on him. Â But for the life of me, I can't figure out how I made this happen in the first place! Unfortunately, experementing with disableUserInput has not helped thus far... Does anyone know how to make this work again? Â How to retain control of player movement of his character while the camera is focused on him? Â Thanks in advance!

Great news... Happy to see the Yomies live on!

Personally, I think it's much worse when the arms clip through the body... and that's very easy to make happen.

Overall, great patch BIS. A few issues: MG gunners used to be quite ineffective while standing up (due to recoil), as it should be. Â Now they can just stand there, blasting away, without any difficulty what-so-ever. Â Seems this change is by design? As mentioned previously, ai still walk through walls, and temporarily occupy the same space in certain cases (like on roads). Â IMO, this really should be ironed out in ArmA1. (i.e. before ArmA2) I tried testing out the supposed bridge fix on a couple of ai infantry and armor groups with waypoints (each seperately). Â While things seemed a bit better, not many of those poor bastards made it across to tell the tale. Amen to that! The forced mouse auto-center while driving (i.e. lack of option to disable) remains among the most voted for issues on the ArmA bugtracker. Â Please BIS, give us the option to turn horrible mouse auto-centering off! Again despite these issues, the fixes are appreciated and please do keep em coming!

Regarding addaction for one-player-only with no "humping" (as Sickboy put it) allowed: According to Celery, Igor's code here works: As Sickboy mentioned, player is local to every computer, so it appears that checking the condition (local player) is likely unnecessary. Â In addition, instead of checking to see if the player is in a particular group, why not check if the player is the actual intended unit to see the results of the addaction command? I proposed the following simplified solution. In init.sqs put this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">PlayerID = player Then, where intended, put this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (PlayerID==<intended unit here>) then {player addAction [blabla]} I would test this, but unfortunately I only have acces to one computer with ArmA right now, b/c my apartment burned down recently. Â If anyone is able to try it out, please report back! btw- Thanks for the solutions for adding radio commands to specific player. Â Been wondering about that one for some time now.

Well said regarding not having insignias on the resistance side Wolfrug. IMO they are far more versitile without any symbols. Plus if you choose to use the organized force of bad guys, the freedom fighters of the resistance side (as they stand currently) are clearly in oppsosition to them, without the need for any symbols. On a related note, I really like the idea taking the resistance side survivors, and randomly assigning some to west side and some to east side (probably using DAC) and then when the player sees some of them off in the distance, he won't know right away if they are hostile or indifferent. Â Kinda reminds me of that book "The Road". Â But this idea (and many others) would not be possible if all the resistance end up with symbols... btw - Love all the new stuff agamoth.

Couple of vegetation related questions... Is there any consensus yet on whether we still need Durg's vegetation fix anymore as of the 1.11 patch? (i.e Do the 1.11 a.i fixes related to sight and sound make Durg's now go too far)? Also, same question about lowplants... any consensis on whether we still need it as of the 1.11 patch?