madrussian

Anyone know the location of the "report file" you can log to via diag_log? Unfortunately the command ref does not specify the file name or location: http://community.bistudio.com/wiki/diag_log (But apparently this command actually works and logs data somewhere because people are using it!) EDIT- Found it: http://community.bistudio.com/wiki/Crash_Files

Well, I haven't messed with vehicle cfgs. But I assume it's pretty straightforward. My guess is look for "speed" or something similar in there. I imagine you could get a vehicle going really fast with a tweak or two. One thing I'm sure of, by messing with speed in CfgMovesMaleSdr, you can get a foot soldier to run like a comic-book superhero. :)

I have put together a proof of concept Fatigue System that blocks sprinting when a player gets "tired". It works in the editor as intended. That is to say, when a player is "tired" and attempts to sprint, he is only able to run. When he recovers, he can sprint again. Pretty cool, huh? Unfortunately I've hit a (hopefully minor) snag. Here's the issue, but first some background. My system is predicated on the use of special new animations (in CfgMovesMaleSdr) used to invoke special new "action states" (in CfgMovesBasic). When the player is tired and enters any of the normal sprinting animations, my system interrupts the current sprint animation by playing one of the special new Sprint-Blocking animations (all running anims themselves), and thus forces the player into one of several new Sprint-Blocking "action states" (which determine what his controls do from there). That part works like a charm. However, in order to interrupt the sprint, I have to play one of the new animations on the player via one of the following commands: playMove playMoveNow switchMove switchMoveNow The unfortunate thing is that each of these commands plays the animation in it's entirety, and the player is stuck watching the entire animation until complete, before regaining control. I need a way to play only the initial part of the animation -OR- interpolate from one anim to another via script command only. If this doesn't quite make sense yet, think of the ArmA2 controls during normal gameplay. For most of the movement controls, you can switch freely at any time from one to the other. Then you go to switch weapons, and whammo, you are stuck watching that weapon-switch animation until completion, and in the mean time you can't interupt it. In CfgMovesMaleSdr, the example above is the difference between ConnectTo[] and InterpolateTo[]. So back to my fatigue system... For everything to work smoothly, I need a way to do one of the following: 1. Interpolate from one anim to another via a script command 2. Only play a small portion of an animation via a script command. 3. Create very small animation file that is a small subset of the existing animation Then we can have full robust fatigue system that slows the player down when he gets tired. Any ideas??? btw- I know that CfgMovesBasic and CfgMovesMaleSdr can be pretty intimidating. If nothing else, I hope at least someone can learn something by reading this thread. I've spent quite a bit of time in those two configs. If anyone has any questions regarding any of this anim stuff, however basic, please don't hesitate to ask here. There's a decent chance I can help. :)

There is a "duty" value built into the configs for each animation. I'm about 95% sure it's responsible for how much "aim shake" you get. It would be pretty easy to tap into this value to determine an ongoing amount of fatigue.

Yeah this mech really needs to put up more fire. Especially with all that freakin' ammo and firepower!!! :bounce3: I think tweaking some of these values in cfgWeapon would cause the AI to ante up it's volume of fire: minRangeProbab, midRangeProbab, maxRangeProbab, aiRateOfFire aiRateOfFireDistance That and Worldeater was kind enough to answer my post on affecting AI weapon selection which is affected by ammo cfg and may also be related to rate of fire (because it's affected by what type of unit they are shooting at): http://forums.bistudio.com/showthread.php?t=109538

Yes. Couple of things to try. First of all you can override the normal death sequence by creating a file called one of the following: onPlayerKilled.sqs onPlayerRepsawnAsSeagull.sqs More info on that here: http://community.bistudio.com/wiki/Event_Scripts Then, depending on which way the mission ends, you get a different dialog at the end. For instance, endMission and failMission present different end game dialogs I believe. Either that or using those commands with different "end types" will result in different end dialogs ("CONTINUE","KILLED","LOSER","END1","END2","END3","END4","END5", or "END6"). Finally if you just get killed in SP I think you just see that simple small dialog with minimal options.

I just ran into this same thing the other day. Almost pulled my hair out. If selectWeapon doesn't help (sure didn't help me), then try the "action" command, with the "UseWeapon" subcommand. You have to invoke it with a Game Logic for some weird reason (anyhow it's per the spec). Also beware, the "weapon index" is ALL the possible fire modes, including the AI-only ones. You may have to check out cfgWeapons to see what you list of modes will be, or just try a bunch of different values (some of which will be AI bursts of various lengths). Anyhow, in my experience, if you can't get something firing with "fire", it will pretty much always work with "action" ("useWeapon"). ;)

Alright, my Fatigue-Sprint-Blocking proof of concept works in the editor, but I've hit a bit of a snag. Started a thread on the matter here: CfgMovesBasic and CfgMovesMaleSdr - Some wisdom... and a few questions

Yeah I recall H&D2's movement speed system, which was very nice! IIRC, there were like 4 speeds, the fastest being the sprint. When you got tired, you would simply lose access to the sprint. It's that part I'm trying for first... losing the sprint ability when tired. In theory you could probably implement the H&D system close to 99%... main issue though is that H&D2 had really good animations for sneak which ArmA2 pretty much lacks. That's the basic idea... forcing a special animation (in CfgMovesMaleSdr) and thus a special "action state" (in CfgMovesBasic) to block sprinting when tired. btw- If you wish R3F-Clint, I can start another thread to discuss these aspects. In the mean time sorry for kind of hijacking, unless you are interested in this idea of course. For what it's worth, I definately think pairing the weight detection work you've done with slowing of movement due to being tired (optional) and visual (also optional) is the way to go. Anyhow I've run some experiments and getting closer...

OK DMarkwick, I accept your challenge! Two ways to make it work: 1. Block sprinting upon tired (easier) 2. Graded loss of speed the more tired you get (harder) I'll probably just try and prove it can work with one set of anims first. Then hopefully someone can step in and do the grunt work. :)

Here's a comprehensive alien invasion movie summary that starts with this years "Monsters" and goes out to May 2012 (i.e. almost out past the real life alien invasion that will really wipe us all out in late 2012): Your Complete Guide to Upcoming Alien Invasion Movies There is even a movie about "space Nazis" in the works. :D

Ever looked inside CfgMovesBasic and CfgMovesMaleSdr? Slowing down running speeds is entirely possible, even on a temporary basis. I can think of a couple of different ways to do it. If anyone is interested, I'll either explain exactly how or maybe even throw together a quick tech demo on how to accomplish it.

Thanks for that info Cam. :) Hmmm... When's the last time any of you in RL ran so hard or carried so much weight you actually blacked out? Can't say that ever happened to me. Anyway just curious. :p If anyone is interested in making fatigue do something beyond visual (i.e. slow down the player), I think I've figured out how to block sprinting on a temporary basis. edit: Btw R3F-Clint: I think maybe that would tie in quite nicely with your system.

That trailer is simply jaw-dropping! But... Then I look at some of the reviews of the director's previous work. I know the critics don't always know anything, but his movies are pretty much all getting Ds. And the three producer's combined list of previous movies isn't exactly knocking my socks off. Anyhow after seeing the slightly underwhelming Skyline earlier tonight (Quick Skyline spoiler- Aliens without projectiles? Come on...) Well I've still got my fingers crossed on this one. Could be a shocker! In a good way. Imo, we could all really use another good alien movie! :)

@R3F-Clint Interesting concept. However, I've read the entire description twice now and unless I missed it (which is possible) there's one important detail missing: How does being "tired" manifest itself to the player in-game? As in, is it just a audio/visual thing (panting, blackout), or do you actually slow down (i.e. blocking sprint or similar)?

Looks somewhat compelling... and of course buying will help BIS fund future development efforts.

AI cannot shoot through windows? This is really the case? Seems like I've been shot by AI plenty of time through windows. Come to think of it I'm always inside the building. So does it work like this? 1. When you are inside building looking out the window, AI can see and shoot you - BUT- 2. When AI is inside the building looking out the window, AI cannot see you. Is that the claim? If so, interesting find, and something I never noticed before. ;) If this is really a problem, then maybe it's just a matter of changing the building's underlying "AI-view-blocking LOD" or whatever it's called, right? As in, there's no reason to lose the visual model of the glass or anything... ? Anyhow, it's been a while since I open up Ox2 and looked around. edit- Just noticed you previously mention the LOD concern. :)

I used to just love playing original GR1 and the expansions in coop with my mate. Whatever you do, please get the coop dynamics true to form for GR1: Nine soldiers in three groups of three soliders each, with the ability to teamswitch. No respawn. That's the magic formula that made GR1 so much fun!

Sounds like you might have nailed it. Thanks! :)

Anyone know which specific values in the config govern which weapon the AI will select against a given target? So I've been pouring over the configs and biki for a few here and did some searches. I found the minRangeProbab, midRangeProbab, and maxRangeProbab, but these three along with aiRateOfFire and aiRateOfFireDistance seem to govern burst frequency and number of rounds per burst. What about which weapon the AI will select in the first place? Couple of examples of what I'm getting at here: 1. Where in the config to change the likelihood of an AI firing a RPG at a foot soldier? 2. Where in the config does it specify that soldiers don't shoot bullets or throw hand grenades at armored tanks? (i.e. Knowing this would enable creating, for example, those explosive bundles that Russians foot soldiers threw at tanks on the Eastern Front during WW2. I recall this being possible in a WW2 mod for OFP. btw- Anyone recall which one? ) Any assistance greatly appreciated as always. :)

This is actually possible, at least for foot units, by changing the anim configs. It would be a bitch though. Check out CfgMovesBasic.hpp, which governs which anim state is entered from a given anim state, based on which control is invoked. You'd have to change out all entry points to all the prone animations, which... would be time-consuming to say the least. If you want to prevent a unit going prone via a script (much easier but not necessarily what you're looking for), check out setUnitPos.

Awesome rebels! Much better than having to look at all those un-removable masks all the time. Great work!

Thanks for checking into it. :) I've had that release problem in two different missions I created in the past. Just thinking a bit on it, maybe I'm not doing an appropriate waitUntil before the release or something easy like that. I'll see if I can't repeat the problem again and maybe send you a test mission that causes it. Anyhow, thanks again for DAC!

Hey no worries and take your time mate. You've created this masterpiece for us, after all, and I'll never forget that. :) For now, you have at least confirmed there is actually a problem there with DAC? (As in, maybe I'm doing something slightly wrong to invoke release from DAC or something after, and thus maybe it's not DAC's fault that the released group will not respond?)

Greetings Silola, I sent you a PM a good while back when you were probably busy with all that pesky RL stuff. btw- I'm right there with you on RL rearing it's ugly cumbersome head from time to time. :) Question regards DAC_fReleaseGroup: DAC_fReleaseGroup works as expected, releasing the desired group from the DAC system. However, once the group is released, it seems not to respond to any forthcoming move commands. In fact, the only way I seem to be able to get the group moving, is to do a join and join all of the units within that group to a newly created group. Shouldn't a move command work on a newly released group? Any idea what might be going on? Hope this makes sense. Anyhow, hope all's well. Thanks!