PilusPrimus_aka_jONATHAN

Kitchener, Ontario representing - home of the University of Waterloo, RIM, Mennonites, and HQ for just about every insurance company in Canada... REALLY REALLY REALLY excited about seeing ONS in action. We rock. Cheers and Beers, J

@Kiljoy - thanks for the remarks. The sniper situation is just one example of realistically depicting the abilities and responsibilities of a soldier on the battlefield... but spcifically for snipers, if they tend to be the lowest scoring class then perhaps they could be assigned special targets, like a squad leader for example, that would be worth more? Which is typically what a sniper in the field will be expected to do - wait for the order to shoot, and do it (I have a friend who was a Canadian Forces sniper on loan to the US for the first Iraq invasion. Interesting stories there....but i digress...) The gist is that though I realize that ArmA has it's own in-engine scoring system, there's nothing preventing a scripted scoring system from supplementing it, is there? Just a thought. Cheers

@Frederf - I generally agree with all points. @Kiljoy - I'm not a scripter at this point, but back in my day I spent crazy time making a different game do things IT wasn't supposed to do using scripting (Jedi Knight and MOTS for anyone who cares). The emphasis of roles, to me, is not what your model looks like - I understand this is a engine limitation for all we know at this point. Pretty yes, gameplay oriented, no. The actual  implementation of roles is really about: 1) Restricting access to some features (ie vehicles) while enabling access to others.... To accomplish: Each player has a variable array called skills(n), where each array element corresponds to a skill area ie. for n1, piloting, for n2, armour etc. The value of each array element corresponds to the level of progression ie. skill(1)=2 means player has increased pilot skill two levels, and can pilot Mh6 for the first level and MH60 for the second. The restrictions are implemented by inserting a check against the corresponding player skill(n) value in the already scripted Rank check for each vehicle. 2) Players choosing what they can access from a structured hierarchy To accomplish: In the script which determines when the player ranks up, insert code to notify player of new skill point awarded. The player has to return to base to choose the skill from a window accessed at the Transfer desk. (This is more realistic than doing it in the field, and prevents the player from being distracted in the middle of a firefight.) Choice limitations are governed here, as well as implementing changes to the skill(n) variable. I don't think "selling" skill points to "buy" into another profession should be allowed, however if a profession change is desired, one could choose to retire a profession to begin another. ie.retiring from Air Force skill tree permits the player to follow another path, but prohibits them from using their Air Force skills to pilot until they retire again and choose to re-enlist in the airforce at the point they left off. (Enabling these changes over a re-spawn solves the potential issue of eg.Sniper re-enlisting as pilot and essentially having a dual role.) 3)Balancing roles To accomplish: This is actually not so difficult to do - avoiding the syndrome of everyone wanting to be a Cobra pilot for example is a matter of balancing the rewards with other factors - ie. like Frederf suggested, increase reload times is one strategy. Another is to instill a sense of responsibility by penalizing the player for lost equipment - a Cobra pilot who goes out and kills 3 tanks + crew and 4 inf, but loses his ride in the process gets the kill credits of course, but the actual points he gains might net to 1 instead of 21...which is realistic in the sense that pilots who lose their assets do NOT get promoted quickly!  Similar restrictions can be placed on tankers, or plane pilots. Where infantry are concerned, they take greater risk to themselves and could therefore have increased rewards, as well. This could mean a higher rate of skill point acquisition, or being the only class to have more than one AI, being rewarded for AI or teammate kills in some way while in a leadership role, having the luxury of diversifying more at the lower levels of all roles... So, in summary, the mechanics of implementing roles is absolutely doable with some scripting, and balancing the risk-reward factors for each role can make them each satisfying and unique in their progression. The benefit to clanplay, teamplay, and simulation which is this game's singular unique strength is huge IMO. Allowing the model issue to be the limiting factor, to me, is like saying the board game RISK is not worth playing because all the units look the same -it's still a great classic game and fun to play! ...and frankly, though inexperienced with the engine, I'm not entirely convinced that there isn't a workaround yet to be discovered for in-game model assignment (or perhaps, modification). Hopefully you'll consider my arguments here, and re-consider this issue for inclusion in what is to me the most promising mission scenario out there. Cheers and beers, - J.

Just a thought or two: The lack of role restrictions is the least realistic (and immersive) aspect of the whole Evolution mission to me, and makes it feel like BF2 in some ways. Real snipers don't hop into helis and fly themselves to their special snipey spots. And real pilots don't run off and jump into tanks. Saying that all sargeants can fly helicopters...or any Colonel can drive a tank and fly a jet AND fly an attack helicopter AND has access to any weapon ever made...is just too gimmicky for the ArmA experience. The specializations in the military are a fundamental to the execution of modern warfare, and are how each soldier defines their combat role. You can even hear the pride when they talk about their specific role - it's important to their identity as a soldier. In real life in the Canadian Armed Forces, everyone goes through basic training. Handing standard weapons, physical training, learning basic squad maneouvers etc. This is called QL2 (qualification Level). Following QL2 is training in your chosen field or profession. Artillery, Infantry, Air Forces (RCAF), Armoured transport etc. This is called QL3. Completion of QL3 commences your full time service. During your full time service though, you can still sign up for training courses in other (somewhat related) areas. Such as driving transports, or speccing out on non-standard equipment. I believe the various US forces are similarly setup. For the sake of realism, I would love to see an elective progression of "skills" or "courses" or what-have-you that enables a player to progressively use specific equipment that is appropriate to their chosen career, like in real life. I believe this would be a merit of this mission if implemented. For example, all players starting as Private are basic infantry. Once a certain level of experience is gained, they are promoted to Private FIrst Class (PFC...or Sergeant, doesn't matter) where they get to chose a profession. The profession choice unlocks A SINGLE vehicle or weapon class like the MH-6 for pilots, or all HMMVW's for Armoured corps, or Grenadier-class weapons for infantry-Grenadier, M240 for Auto rifleman etc. Progressing to the next level allows the player to chose the next level of their profession, or chose another professions basic level... I think a system in Evolution for career specializations will add a whole depth of realism and sense-of-purpose to our beloved ArmA Coop that is not available in any other game on this scale. Thanks for ur consideration. -J.

re: hotfix or driver first - don't need the normal 7.5's - just install the hotfix, as it has everything you need. That's what worked for me. Sidenote - I previously had a problem with HyperThreading enabled, which created artifacts in complex scenes-even with older CAT 6.7 driver. This driver update/hotfix seems to have corrected this problem also though. Boo yah, grandpa.

Another quick note on usage: Many missions give you control of a squad, that's two fireteams of four plus yourself. If you designate four members to the "red" team and four to the "green" team for example, you can easily give each team a different position relative to yourself. eg.1 red team advance + green team fall back = leader (you) in the middle eg.2 red team fall back + green team get in formation = leader at the front with green team, red team essentially covering the rear Spacing your fireteams like this can create some great tactical advantages. (This post is worth exactly 2 cents )

Although I totally respect the thinking behind your argument, and your obvious experience with the subject matter....Umm...It's a game kids. If we were talking about accurate mathematical modelling simulations of real-world classified US equipment, then perhaps there might be some classified white paper or IP out there that would be in conflict...but that's what VBS is for, right? I don't see that a generic emulation in a video game of an infra-red target designator is going to cause the US Department of Defense (or whoever) to bomb the Czech Republic, or dismantle the internet, or worse...take away our ability to play this game. :-) On a side note - if someone were to recreate this technology using DoD specs in real life for, say, a paintball gun, then I'd love to be around to see the p00p hit the fan in that case. Where technical considerations are considered to make it happen in game, an old school method for consideration would be to fire an invisible "bullet" with no ballistic properties and with highest velocity possible from the targeting device once per screen refresh ... when it hits an object or reaches it's maximum range, either event would create a trail of self propagating "laser" objects back along the trajectory to the source. Caveat - this would be laggy unless it's explicitly generated locally. Probably not hte best solution, but there's a concept there which may bear fruit. This input is worth exactly 2 cents.;) See y'all in the field - J.

Maybe this will help someone....if increasing the AGP aperture size doesn't work for you, try disabling hyper threading in your bios. See thread here: http://www.flashpoint1985.com/cgi-bin....t=62565 Hope this helps. See you in the field -J.

Found a solution on the BTS board that worked like a charm for me and my ATI problems, same as described below: Apparently, ArmA + ATI doesn't like hyper-threading. As soon as I disabled it in my BIOS, this problem completely disappeared. Ironically, this Bug-Tracker post lists this as a minor problem. If only they knew, right? Here's the bug-tracker thread for reference: http://bugs.armed-assault.net/view.php?id=2285 My specs: Toshiba P90 Satellite Notebook Intel 3.0ghz HT processor 2g ram ATI 9700 Mobility Radeon w/ 128M non-shared VRAM ATI Catalyst drivers v.6.7 (using DHModTool4) ArmA 1.06 See you in the field - J.

My comment was with regards to the severity not being changed. Sorry if I wasn't clear on that... Good suggestion....but... That was the first solution I tried, but it didn't work for me. I even checked Task Manager after loading a savegame to verify that the ArmA application processor affinity was only checked for one processor, which it was. Even if this had worked, however, it would only be a part solution, since I'd then be running the game on half the CPU horsepower. Read my post again Sleek. I specifically stated "Apparently, ArmA + ATI doesn't like hyper-threading. ", because in all the threads I've been scanning for this problem, I haven't seen any NVIDIA users describing the same symptoms. And it's not just an ATI problem, otherwise all of your other games (and mine) would have the same problems with HT enabled, so it seems more likely that is the combination of Armed Assault's handling of ATI driver calls that is causing the issue. Not surprising at all actually, when one stops to consider the BEST PLAYED ON NVIDIA logo plastered in the opening logos...conspiracy theories anyone? I mean who better to exploit a product's potential weakness than their COMPETITORS.... Anyways, hope this helped some other poor frustrated soul. See you in the field - J.

Found a solution on the BTS board that worked like a charm for me and my ATI problems, same as described below: Apparently, ArmA + ATI doesn't like hyper-threading. As soon as I turned it off in my BIOS, this problem completely disappeared. Ironically, this Bug-Tracker post lists this as a minor problem. If only they knew, right? Here's the bug-tracker thread for reference: http://bugs.armed-assault.net/view.php?id=2285 My specs: Toshiba P90 Satellite Notebook Intel 3.0ghz HT processor 2g ram ATI 9700 Mobility Radeon w/ 128M non-shared VRAM ATI Catalyst drivers v.6.7 (using DHModTool4) I will post this in separate thread also, since there's so many users affected. Thanks to Giova, who posted the bug and ended my headaches. See you in the field -J.