Millenium7

wtf? Horsepower is relevant to power surge by the clutch. Torque is what keeps you going, torque is what will propel you from 100kph to 140kph. Horsepower is how quickly it happens. If you have a high horsepower low torque engine and you crack the throttle open at 100kph you will crawl your way to 140kph unless you are within that high horsepower range, meaning you need to bang it down a couple gears or slip and dump the clutch to get anywhere Torque is relevant at any and all RPM's, go and have a look at the power curve of a 4 cylinder 250cc bike engine compared to a 1 cylinder of the same capacity. The 250 4cyl will almost definately make WAY more horsepower because it revs up to 20,000rpm or thereabouts, but look at the dyno chart. There is sweet f all torque until about 14,000rpm. Up until that point it couldn't pull the skin off a rotten banana. You need to clutch it all the time to get anywhere and you have utterly miserable roll-on power in 4th gear at 80kph Swap over to the 250cc single cyl. It's a comparitively high torque lower horsepower engine because it doesn't rev anywhere near as high. Look at the dyno chart, it makes WAAAAAY more torque everywhere in the rev range below 12,000rpm. It will easily out accelerate the 4cyl in a roll-on test. I should mention these bikes have around the same top speed despite the 4cyl making significantly more 'horsepower', why? because torque is "how far you push the wall", the 4cyl will get there quicker up to a certain point, but the single has more torque to fight against weight and drag. Uphill or with more weight the single will have a higher top speed because it pushes the wall harder than the 4cyl does Now lets take it up a notch, come and sit on my 650cc single, it only makes about 45hp. Compared to what 90hp of a 4cyl racing bike. I want you to go along at a measly 2000rpm on both bikes, infact screw it you can have a 1000cc 4cyl if you want, go something big at least 130hp at the rear. Now crack the throttle open WITHOUT clutch the 4cyl - a miserable display of weakness the 1cyl - you are on your ass because 'torque' ripped the front end sky high in an instant

i'm hugely in favor of 'scripted' AI on demand. As well as certain other scripted events but for now lets stick with AI This diversity of the ArmA2 AI works both ways, its great in that it adapts to any units/vehicles/islands/buildings/whatever on its own accord, but it also has a huge downside in that it does not allow fine control of what it does. In most games if you want an AI to stand still, follow an exact path, fire an exact number of bullets at a precise point etc it's easy to do. But they are also completely brain dead and sit there doing nothing unless manually told what to do In ArmA2 they are semi capable at all times, however they are bored sheep and tend to wander on their own doing, you have no fine control over what they do. How many times have you seen a cutscene and the AI decides to turn the opposite way, or turn their head in a random direction, or get stuck pathfinding midway through their 'go to here' sequence. Bloody annoying!!!! I'd love to see the option to turn off all or specific AI function. And also a more stripped down version of shoot/move/lookat/stance/etc that makes them do exactly what they are told and nothing more! if told to 'fire at that tree 3 times' it bloody well does exactly that and nothing else. No sudden running into cover before firing, or changing its stance, or any other arguements!

holy crap to anyone who thinks the current implementation of speeds is accurate. Guys.... I own a 650cc dirt bike, so for now lets just concentrate on the bikes/quads in the game Want to have a guess what my uphill speed is on a 30 degree slope? 140kph. On a flat surface? 160kph Uphill speed in arma2? about 70kph I believe Why does Arma2 suffer from a massive speed drop off, whereas in reality its a very minor speed drop? torque to weight, NOT horsepower to weight I'll give you another example, a 250cc dirt bike producing exactly the same horsepower will also have approx the same acceleration speed in a drag race (little faster due to less weight) but it will have a much lower top speed, and as soon as you add any additional weight such as climbing an incline, it's speed drops massively whereas my big torquey engine just keeps on powering along. Why is this? well horsepower is how quickly you hit a wall, torque is how far you push the wall once you hit it Stop comparing horsepower, an abrams only produces around 1500hp, but it makes a whopping 3800ft-lb of torque. Compared to a veyron making 1000hp it only makes 922ft-lb of torque. Huge huge huge difference in usable power. Obviously the abrams also weighs a crapload more, but it isn't gonna slow to a crawl on a minor incline. Put the veyron engine in the abrams and it'll barely move, soon as it hits a pebble it'll stall. Do the opposite and the veyron will climb a 45 degree gradient and barely lose any top speed

working fine here also, with all kinds of driver versions across both XP and win7 try reseating the card, or use a different slot

I've dabbled a bit in programming and the one thing that continually evolves is theory, since there's no limit on how many ways a program can be written. This makes determining exactly how the ArmA2 engine works quite difficult and thus what is possible. Anyway... One of my biggest gripes with OFP/Arma/ArmA2 is the vehicle physics, but to be more precise the complete lack of torque. Every vehicle feels very weak, theres no torque whatsoever its just a case of "uh oh, an incline, i'm going to slow down dependant on how heavy I am". It seems to me vehicle physics are pretty much a determination of 'weight', 'onroad top speed' and 'offroad top speed' with everything else calculated in real time according to them. I may be wrong and if so forgive me, but thats how it feels when playing My question is how difficult would it be to redesign a few of the core components of vehicle movement. What i'd like to see is 'torque' and 'friction' added to the mix, and remove 'top speed' as a determining factor of how well it moves on various terrain and hills. Torque should be a predetermined value * throttle percentage, such as 3000ft-lb for an M1A1 at 100% throttle. 'Friction' is a dynamic changing value, determined primarily by surface type, weight and angle The way i'd see this implemented would be through a fairly simple formula, friction is a measure of vehicle weight, contact area (tracks/wheels larger/more contact areas = more friction), surface type (grass, mud, rock/tarmac etc) and difference between wheel/track speed and movement speed (I.E. vehicle moving 10kph, wheels spinning at 20kph = less traction) and finally, divided by the vehicles propulsion angle (facing uphill = less traction than a level surface) If torque > friction then (ok so we're on a slippery section with a big powerful engine) -> increase wheel speed according to torque amount (which in turn reduces traction, ie wheels start spinning more and more if excess throttle is applied) -> reduce applied vehicle speed by weight * vehicle movement angles (reduce much quicker going uphill, much slower or even increase when downhill) if torque < friction then (grippy section compared to engine power, i.e. cars fine on dirt, tanks may spin a bit if they have gobs more torque and thus break traction) -> apply more forward speed determined by torque / weight & angle So for example an M1A1 with an enormous amount of torque but equally enormous weight, if positioned on a 30 degree tarmac or solid rock incline will easily have enough grip to move forward, and at a reasonable pace. When positioned on grass (even better lets say wet grass, because its raining) at a 30 degree incline will apply far too much torque and just spin the wheels, which actually reduces its friction and may start sliding backwards. If wheel speed is kept independent from movement speed and torque is a constant factor. Then the only thing stopping a vehicle from moving quickly is the surface its laying its torque down onto, and the angle at which it is facing. A heavy vehicle with low torque will do very bad at climbing hills since its influenced by the vehicles weight and angle a lot. An equally heavy vehicle with lots of torque will climb hills far easier/faster, though it risks spinning its wheels and reducing traction if given too much throttle. Though won't necessarily go much faster on a level surface. Lightweight vehicles such as dirt bikes will climb hills effortlessly, sure they have less torque, but they also have less weight to carry around and grip better. I cringe at how slow they are in the game when uphill. So ultimately, how viable is it? I don't have access to the engine so I don't pretend to know how you've implemented it or how hard it may be. But just going off my experience it's not a whole lot more than changing a bit of math and modifying each vehicle to have a predetermined torque value. Since surface type and weight are already included in game. It's not perfect and probly wouldn't allow serious drifting or alter any other vehicles physics (hit tiny pebble and launch 100m high etc) but it would at least allow vehicle propulsion to work much better than it currently does

the above example can be coded very fast, with no more of a performance hit than there currently is. It's basically just a fairly simple set of math calculations, everything else is already in place aside from perhaps wheel speed in multiplayer, which is a purely cosmetic thing anyway since the vehicle position is determined client side for whoever is the driver, and then sent to other players In regards to surface type, doesn't matter. The engine already knows what is grass, dirt, tarmac, rock etc. The friction values do not need to coded into the terrain surfaces directly. They can simply be a single config file added to the game data with a number attached to it I.E. tarmac = 100.00%, rock = 90.00%, grass = 60.00%, dirt = 40.00% that number is referenced in the movement calculations to determine the friction multiplier. I'd love for them to then go 1 step further and add a countdown timer and additional multiplier for rain. So the longer and harder it rains the less friction is given for each surface, with rock suffering the worse perhaps going from 90% down to 15% within a matter of minutes on a heavy downpour, and grass staying relatively high even after a big shower. And then for it to creep back up to normal levels after the sun has been out for several hours I really can't see any downside other than coding time. But I personally believe this is LONG overdue

I added a 2nd GTX275 which added a grand total of 0fps, but allows me to run at 3840x2160 instead of 1920x1080 with almost no performance drop. On average I get maybe 15-20fps, 35fps on a nice smooth mission I built a computer for somebody with a GTX460, 1 of them is only about 40% faster in an absolute best case scenario than a single GTX275 though on average about 15% faster yet it runs about 3x smoother than my comp. Why? i've got an X2 6000+, the one I built had a 955BE cpu More cores, and more clock, forget the GPU for this game!

you can buy a little adapter like this http://cgi.ebay.com.au/2-Molex-6-pin-PCI-Express-Graphic-Card-Power-Cable-/250643029725?pt=AU_Components&hash=item3a5b7d1edd which will do the trick I'm running 2x GTX275's on a 650w PSU using 2 of those adapters. You'll be fine in regards to 'baking' a card, what temperature? I have a SB X-Fi card that isn't working

I agree that it should be greatly simplified. As was already mentioned we have EIGHT!!!! move forward commands, it's just ridiculous. They should all be combined into simply 'move forward' When on foot, it moves you forward When in a car, it moves you forward and if you want to go slower just dont hold it for as long When commanding, 1 tap = forward, 2 taps = fast forward 'Shift' is a variable, with shift held down you move forward slower or command 'slow' Which it pretty much already is, but its just unnecessary commands flooding the controls screen which make it a real PITA if you ever want to reconfigure anything. Another suggestion is why not group all of the 'do the same thing' commands into one so you reduce it from ~100 keybindings down to ~25. And if you want to get more precise then right click on the command and it brings up another list with the individual commands grouped. I.E. left clicking 'fire' allows you to assign one nice neat keypress/mouseclick to 'fire' 'command fire' etc. Right clicking allows you to then manually go in and assign 'fire' to click but 'command fire' as right ctrl. And then highlight the command in blue/orange instead to indicate different sub-mappings if its free/conflicted instead of green/red

not a bad map. Round 6 my first go I do kind of like the fact that you've barricaded everything off, arma2's open endedness does have its draw backs at times especially when it comes to zombies, you just never get that 'oh shit i've got nowhere to run' feeling, instead you just run for 10 miles and all is well My suggestions 1) coop, definately. Perhaps even restrict/open up more areas depending on how many players are in, as it's a little confined for any more than 2-4 players at present, yet if you open it up for just 1 it becomes too large and loses the confined and tense feeling 2) additional 'stuff' to do for replayability Purchasable/movable barricades perhaps? areas dynamically opening/closing between rounds? optional random side objectives such as AI/objects spawning that can be recovered/defended/destroyed. Areas that can be closed off by the player to reduce the number of zombies spawned that round, either costing money or time

dont' mean to be a buzz kill but with the disgusting state of AI pathfinding on roads and around buildings, this would fall flat on its ass Besides arma2 does not play like ghost recon/vegas/cs/bf2/whatever. It doesn't do urban fighting very well

well, I can run arma2 everything maxed out (minus antialiasing) at 10k viewdistance on basic missions without 'too' much trouble, but when you start throwing in triggers and a bunch of other stuff no chance. An empty map though? no problem at ~30fps ---------- Post added at 05:03 AM ---------- Previous post was at 04:52 AM ---------- I was about to point out your incorrect math, however i'd forgotten i'd wrote 50% instead of 100%. Anyway back on topic, massive horrendous FPS loss...

guys i've installed this but its not working, whats wrong? I have the @MWVD folder in the arma2 folder correctly I.E. D:\Program Files\Steam\steamapps\common\arma 2\@MWVD\addons\[2 PBO FILES] D:\Program Files\Steam\steamapps\common\arma 2\userconfig\MWVD\MWVD.hpp i'm using a launcher that picks up the mod folder, I run it and NOTHING! holding CTRL+ALT+rolling mousewheel does a grand total of nothing whatsoever

yeah sorry my bad. I clicked an addon on when I restarted without realising, one of the addons in that folder changed the FOV. After removing it its back to normal

I was holding down the right mouse button and opened the options menu midway, played with some settings and now my FOV is permanently stuck at half zoomed in. If I hold the right mouse button it only zooms in a little bit, holding down minus on the numpad zooms out A LOT. Even after restarting the comp its still there. I have fovTop=0.75; fovLeft=1.3333334; in the profile .cfg but it's still the same, changing aspect ratio ingame also has the same 'half zoomed in' problem just horizontally wider/slimmer. How can I fix this? its bloody annoying :o

I can confirm this as well. I'm using 2x GTX275 in SLI With regular 1.57 and using a specific testing area, 18fps when looking at a particular church + buildings 38fps when looking at a field with lots of trees in the background (GPU usage: 50%) 60fps when scoped in and looking at the trees (GPU Usage 85%) with the beta 18fps when looking at a particular church + buildings 38fps when looking at a field with lots of trees in the background (GPU usage: 50%) 15fps when scoped in and looking at the trees (GPU Usage 95%) ***edit:*** using 50% 3d resolution 70fps when in and looking at the trees (GPU usage 22%) WOWZORS 75% drop! :eek: that's probably because i'm running at such a massive 3d resolution. Res: 1920x1080 (3D Res: 3840x2160) VD: 2000 Textures: Very High Vid.Mem: Default Aniso: Very High AA: disabled (so ATOC isn't utilised??) Terr.Det: Very Low Obj.Det: Very Low Shadows: Very High HDR: High PP: Disabled Vsync: Disabled ----------------------------------------------- I will say that in the beta patch LOD swapping is drastically different, the trees are super sharp when scoped in vs not super sharp on 1.57 when scoped in. But that much of a difference? just doesn't seem right edit: given the framerate different on 50% vs 200% (yeah yeah I know its rendering 4x more) i'd say it's something to do with some sort of behind the scenes AA? i've tried ATOC=0 and it makes no difference, are you absolutely sure its disabled? edit: build 77159 yields same results as 78188. Build 76815 yields same results as 1.57 so as was mentioned before its almost definately [76871] Reduced lod switching in dense (forsest, town) scenes. it couldn't be [76930] Fixed: More reliable VRAM detection on Vista/Win7 (using DXGI) because i've tried setting my video ram setting to normal/high and it yields the same results I don't mean to blow the whistle here but wouldn't it make more logical sense to add a few new commands into the .cfg file along the lines of LOD_TreeDetail = 0.0-1.0 LOD_VehicleDetail = 0.0-1.0 LOD_CharacterDetail = 0.0-1.0 LOD_ObjectDetail = 0.0-1.0 Allowing us to manually define LOD swapping priority rather than relying on a predetermined value set by the devs that will never suit everybody's hardware. And for the people in the year 2020 who can finally play this game smoothly can opt to set 0.0 and have no LOD swapping even over 10k

CMSS-3D (found on the X-Fi cards) is about the best consumer grade 3d positioning system you will find. I guarantee you will not find anything better Also the issue with holophonic is it needs to be pre-recorded, it is not done in realtime. It uses real world acoustic properties so the only way to get that in realtime with mono sounds (yes 3d game sounds are mono, and then positioned at a 3d point) is to exactly emulate those acoustic properties at all angles. Pretty much exactly what CMSS-3D already does....

I think its great that you have the ability to place symbols and text anywhere on the map for players in the specified channel. However it's not exactly intuitive enough to come up with a gameplan other than "go here/attack this" Here's a snapshot of a typical map in a rescue or assassination sort of mission nothing wrong with it. This is a pretty basic mission, get to the mosque and rescue/kill the [insert] then head to the extraction. But how do you coordinate with your team? you may do something like... Which is fine but its get a bit messy and its difficult to interpret whats going on. As its essentially just a bunch of clutter. You can use the up/down keys in combination with shift to choose different icons or text however this can literally take minutes to do, and still looks pretty average. If however we are given a 'draw' ability and utilising Shift+Up/Down for colouring we can in 2 seconds show something like.... Which is far more intuitive and with nothing more than a quick glance you can in a split second see, ok guys this is the route we're taking both in and out. Being an ex programmer I can't imagine this would take much to get going either. There's multiple ways to go about it but the easiest would simply be that when the mouse is dragged it places '2d waypoints' if you will on the map, and then a line is simply drawn between each one in sequence. Once completed the position of each waypoint and number sequence is sent over netcode to appropriate players and each client renders the lines between them. This method is a little more crude in that it only allows you to draw straight lines, however it utilises very little traffic and is quick and easy to implement from scratch. Implementing this in mission making as well would allow for drastically improved/simplified/easier visible objects and instructions such as... http://img715.imageshack.us/img715/4531/arma2oa4.jpg > 100 kb Now this could be drawn at design, briefing or midgame and it very quickly and easily illustrates what each of 4 squads should be doing and which path they should take. Trying to replicate something like this with the current ingame tools during mission/briefing is VERY time consuming and just leads to a mess of icons all over the place Thoughts/Comments?

ok just look a look at controls, bank left/right is obviously to bank and is used for flying at high speed left/right pedal is the yaw, and is used primarily at low speed, map those to the shoulder buttons

probly to do with the fact that keyboard is digital (either on or off) and a joystick/controller is analog (any value between 1 and 0). The 'turn left/right' command is just a combination of roll and yaw, it only yaws when the aircraft is at low speed, and it only rolls when at high speed. Because of the analog inputs the game is probably only using roll and not yaw. You should be ignoring the turn left/right command and instead mapping directly to bank/roll and yaw

your controls sound funky to me. I set left stick (360 controller but same thing) to pitch up/down and roll left/right Right stick to freelook left shoulder button to yaw left right shoulder button to yaw right The last 2 are what you want, forgot exactly what its called in the options but its not the 'turn left/right' option

I think your missing some key information here. In RL you have access to much more than the WASD keys, simultaneously. It's not difficult to shift your head 2cm to the side and upwards quickly in order to get a line of sight to your target. In the game we have access to 10 fingers and some wrist movement (interpret that how you will), usually only half of those are used. And without the ability to make minor height variations its incredibly clunky to operate within grass in the game. OP is correct with the transparency thing which will NOT block your view anywhere near as much because you can see objects through it. Close 1 eye take your finger and move it right up close to your open eye, now 50% of your visibility is blocked, that's how it looks in the game. Now open your other eye and what happens? miraculously you have about 90% visibility again with a transparent out of focus finger

perhaps we need a 'free move' key along the lines of free look? I.E. instead of using Q/E for leaning left right at a fixed distance, you hold Q and move the mouse incrementally to lean further left/right and also raise/lower stance. This would also help a lot with buildings as a lot of the time you have top pick between standing up and not being able to see more than 10 metres out the window, or kneel which is too low to hit anything <200 metres. But if you could fine tune it you can line up your viewpoint through or over any window, wall, grass etc

seems like a step backwards, as this was present and working in OFP. I also hate the fact that mouse look is not possible in vehicles like it was in OFP which makes targetting an absolute BITCH of a thing. In OFP you'd just put the mouse pointer over something and right click, now its not possible unless you line the actual helicopter/plane up exactly in line and hit right click, or use the hopeless 'cycle targets' button I believe this should be overhauled, ideally a dynamic (and invisible) countdown timer should be implemented. I.E. if you see a tank up close in plain view it should be targetted instantly upon right clicking. If in the distance and behind a bush there should be an appropriate delay - say 4 seconds - where you have to hold down right click on the target and then it'll force it to be revealed/targetted. The further away it is + how much concealment between you and the target = the length of time you have to hold the button down for before targetting. Would work much better than relying on the 'AI vision'

forgive my ignorance but from the games point of view doesn't a game see a single quad core exactly the same as 2x2core cpu's? the number of physical cpu's shouldn't be relevant, merely how well multi threaded the program is as to how many cores it can take advantage of and the motherboard will split the load as necessary? I've never written a program to be multi threaded though so may be completely wrong here