PLRSniper
Member-
Content Count
193 -
Joined
-
Last visited
-
Medals
Community Reputation
-3 PoorAbout PLRSniper
-
Rank
Sergeant
core_pfieldgroups_3
-
Interests
Millitary<br>Computers<br>Computer Games (Especially OFP)<br>Cars<br>Motorcycles
-
On the subject of swearing. All i need to do is take one step outside to hear kids anywhere from 7 years and up talk about how they are going to F* each others mothers and butt F eachother etc. I don't see that as a problem personally considering the irony of it all. It's just the way it works, they learn the "harshness" of the word and abuse it to bits taking the edge off of the whole thing. In the past it was considered ill mannered to say "hell". These days it's a valid replacement for sh*t. In 20 years time F***, S***, A** will all be considered valid replacements for whatever new words are worse to say that kids will say to get some attention. Beyond that, swearing happens in war. Swearing happens in the military period, no matter what nation that military belongs to. Not simulating that immersion aspect of the game to stay "politically correct" just makes for a bleak and gray experience. Anyways, where i live, the only people that complain about the constant swearing are elderly people. They rest just don't give a F, it's perfectly normal. EDIT: Oh and the only reason i censor these words here is because the forum rules might prohibit the use. Doesn't mean EVERYBODY here know exactly which words i am talking about. Once again, i don't see how that makes any difference if i replace the "bad" letters with asterisks. We all know the words, why are we so offended by them?
-
First off, experiences vary. Secondly, don't go for personal attacks just because you personally disagree. That just shows your age. Third, as much as you believe you are right and perfect at everything... You are not and never will be. The AI can at times see through bushes, it all depends on the situation. And even when they can't they will keep on shooting at your exact location until they become "unaware" of you. Even when you move around. And if the AI didn't have an aimbot then how would they aim considering they are bots with an artificial aiming system... Hmm? It doesn't matter if they have an accuracy penalty or not, they still SNAP ONTO you like a mom would if you painted her curtains.
-
On the contrary, the more you have to "redo" the mods the better IMHO. This points to the fact ARMA 3 would be a completely new game and not just an "addon" like other developers do with their titles. (hrm hrm CoD hrm hrm Battlefield, though BF did get an engine makeover since BF2) I'm not saying modders should have to re-write everything and there will be some sort of familiar territory (OK, plenty) that allows them to port their mods after a few tweaks here and there. But in essence, new features need to be exploited. New ways of doing things need to be adapted to for the better. They won't have to start from scratch because they have a working concept already and have ironed out most of the "how to solve this" issues in titles past. ---------- The very first thing i hope for in terms of ARMA 3 mods are: Bringing the time back to the modern era (weapons and vehicles etc) between the years 2000 - 2012. I am not too fond of railguns and lasers. (I know it isn't THAT but I'd just like to have something i can relate to) An ACE style mod, I.E ACE 3. Controlling (input), Physics and Graphics tweaks (performance and visuals) etc that work better than what we would get at release. Sure BI is good but the community are more numerous and have more data to go on. And anything that adds to the general content and complexity of the title.
-
As far as my experience goes the AI is much more "aware" than any player can be in vanilla. But let's compare a human to the AI shall we? Situation: Lie prone in a random bush on the outskirt of a random forest, fire ten M16 single fire rounds at enemy that is 300 meters away. AI: Knows your exact location and returns dead accurate fire killing you. There is rarely a situation where the AI doesn't find your exact position because the AI doesn't "see" you, he passes a threshold where he either fires at your exact XYZ coordinates or he doesn't fire at all. In short, the AI has an aimbot that is triggered once you make enough "noise". Human: Struggles to figure out the exact direction where fire is coming from, unless he sees your tracers he is very unlikely to find your exact location. If he has a general idea of where you are then he will fire randomly close to your location. If he finds you then he returns dead accurate fire killing you. But it still requires the player to aim capably and there are more factors at play than with the AI. In short, being found is mostly due to player error. And a bad player will miss those 10 shots and a good player will (if he sees you that is) kill you with less. --------- All FPS games suffer the same fate with AI. The AI doesn't suffer the same difficulties that a real human would. And anytime i play against AI it pisses me off, once they open up on you there is very little chance to escape their fire because they know your XYZ coordinates and doesn't use hand and eye coordination to kill you. Whenever i play a new FPS game i turn the difficulty up to max and work my way through it carefully to kill one AI at a time. Each time i die it's due to the AI seeing one pixel of my character and they unload on that pixel. Then i turn the difficulty down to "noob mode" and run through the game again but this time i don't have to worry about dying because i can take the first hit and still kill each AI. But ya, AI uses aimbots (duh?) and that's the real issue with all AI. If BI would make the AI not shoot at the exact XYZ coordinate but instead narrow down their fire based on just how visible you are to them and add proper suppression effects to the player then we would probably be golden. And i agree with the pathfinding, it was bad in OFP and it's bad in ARMA. So many hours spent fixing pathfinding in OFP when making simple missions. Don't get me started on two way traffic.
-
Is this a joke? I sure hope so! Above poster saved me the trouble of writing anything more about it...
-
Disable mission ending completely?
PLRSniper replied to PLRSniper's topic in TAKE ON HELICOPTERS : MISSIONS - Editing & Scripting
Looks very promising. I remember these from the good ol' days in OFP i think. (onPlayerKilled.sqs that is) Will get to work with this when i get back home! Thanks guys! -
Disable mission ending completely?
PLRSniper posted a topic in TAKE ON HELICOPTERS : MISSIONS - Editing & Scripting
I am trying to make a "never ending" mission where one takes on tasks from a list of available jobs. It will start with you simply leasing a light helicopter and take people on tours or taxi jobs to/from airports and various locations on the map. If you manage to make a profit after fuel and maintenance and lease related costs you would eventually be able to afford your own helicopter(s) and take on ever more difficult tasks with a higher profit margin. As it's still a game i want to keep the mission going even if you happen to crash a helicopter into the side of a building at 250 Km/H. Replacing the "death" event with a visit to a hospital ala GTA style but with a hefty bill and the loss of your helicopter. (Hope you had insurance etc) Game would only end when you run out of money or can't take any jobs because you have a reputation for crashing a lot. So my question then... Is it possible to make an SP mission never end on death? I have searched for hours and found nothing, i have tried using a "description.ext" file with "respawn = 3;" in it and added the corresponding "respawn_west", "respawn_east" etc markers but on death the mission still ends. -
Well, it's not as simple as pressing a button you know. And based on the feedback from the dev(s) that have responded to this thread it makes me think they never really planned in multithreading beyond splitting each element (physics, AI, rendering, game logic) to a core each. Proper multithreading would split the workload of each game component over multiple cores but requires the code to be designed to do just that from the bottom up. It's too late for that now and i said similar, not the same.
-
I don't think you get the point so lets try a real world equivalent... A kid is about to go to sleep, his mother is tucking him in (the gameplay) and reading a story (the storyline) while the father is doing the dishes and keeping things tidy in the houshold. (the engine) After the father is done with his duties (loading the scenario) he can choose to either prepare a trip with his son to seaworld (the underwater element) or he can join the mother in the process of tucking the boy in and reading the story. The boy doesn't fancy seaworld that much, but it will be an pleasant experience and he gets to spend some time with his father who otherwise is busy working 10 hours a day to provide for the family. (minimum game requirements) And there is nothing wrong with the mother, she is perfectly capable of tucking the boy in and reading a story to him. Should the father decide to join her in the tucking in process the whole thing would become over saturated and the boy would just get confused. As the boy grows up (progresses through the game) he will not have seen seaworld (the underwater element) and would not know of the many diversities of the world around him. He would never have explored the world outside the sandy beaches that border the ocean front and it would simply serve as a flat arid desert land (out of bounds regions), a waste if you ask me. ------------- Now, i am not particularly fond of the ocean myself. But i have visited underwater worlds in my life. Seen sharks, exotic fish and many other of the mystic things that reside underneath the oceans. It doesn't give me much direct pleasure, i don't seek to dive into the ocean and explore it but i appreciate it's existence and have a much broader understanding of how that environment and it's ecosystem makes our planet whole. The same applies to underwater elements in games, it doesn't provide much direct content but it completes the experience and without it the game would just feel well developed at certain key parts while you look at a perfectly flat water grid that is mostly not used for anything at all. In my little "cool story brah" above i touched on the subject of the father, instead of planning to take his kid to seaworld, would join the mother in the tucking in and telling the story. While that can enrich the experience slightly for a specific part of life you might later wonder why you never went to seaworld. As more and more fathers decide to do what all other fathers do (tell the story), seaworld goes out of business and you never get to see it at all. Maybe the real question is, have you ever seen what lies below the ocean surface in first person? And do you understand how vitally important that environment is in a military aspect? The militaries around the world don't go under the ocean surface very often but when they do... They do so to exploit the immense tactical advantage undersea operations give those militaries. In fact, up to 40% of the USA and Russian power comes from below the surface assets. It's not that there's half the number of people or assets situated below the surface but the few personnel and equipment they have under the surface is enough to wipe out the planet or insert special teams that can (under the cover of the water surface) cause more damage than a force 5,000 men strong could by going on the surface. ... Not to mention just how little you understand of how big game development works. But that is a completely different subject and one that i would love to see changed. But simply put, each developer team is focusing on their respective elements of the game. Bringing in more people to do the same job is not always a good thing. Same as having two parents tucking you in at night at the same time isn't necessary and can in some cases only serves to saturate the experience beyond absurd. The same as having two chefs cooking one dish at the same time, they just end up stepping on each others toes and the end result isn't as good as it would have been if each chef cooked one dish each.
-
Because it can be done and it does give a whole new dimension to play with. It's not THAT expensive to do. (A few extra animations, models, gravity and movement speed settings and some shader code) I always considered games that have lots of water on their maps that doesn't allow you to dive under said water to be horribly limited. Not even BF3 allows swimming under water and when you compare the two titles, if one allows you to swim under water, then ARMA 3 will get 1 point over BF3. Same thing with FarCry 1 and Crysis, why did they let you swim under water in those games? Not much content was designed around being under water but it did add to the completeness of the games and that is good enough to warrant it being added in ARMA 3. EDIT: And i did use underwater routes in Crysis in my assault on certain objectives. Once again, totally worth it!
-
While i too try to follow the "Impossible is nothing" mantra at every turn one still has to remain realistic... Do the developers know enough multithreading code fu to make it work well? Can the code be (re)designed to work well in a multithread environment? What are the (un)expected side effects of converting something into multi threading? From a completely uneducated standpoint... and lets face it, we are all uneducated when it comes to the code behind ARMA 3 except the developers that are writing the code... We can assume something is easy because we have done some multithreading code snippets ourselves and it was beautiful and very optimized. But neither of us has made a fully featured title like ARMA or BF3 on our own. There is so much more to it than just sitting down one day and writing a small narrow demo on how good results you can get from a specific multithreading solution. That said, if one particular task takes 90% of one core leaving other cores at 20% it would (at least in my humble opinion) be worth it trying to make the routine that uses 80% of one core spread out over all cores and prioritize the heavier calculations over the less heavy ones. What i am getting at is, make the heavy operations overtake all cores and squeeze as many cycles as you can out of all cores and let all other routines suffer a little. So now, the 20% routines wait for the HOG to finish and then do their work whenever the core is available again. You guys are saying the AI routine is the culprit and it's sequential. Well, if that alone takes 80% of a single core then there must be a number of calculations in it that can be prepared in advance or reallocated onto other cores. It's all about making a "roadmap" on what's going to be needed. So entity X needs to go from A to B through obstacles 1 to 4,000. You have 4 cores at your disposal. Divide the trip into 4 equal parts (straight line) with a rough estimation on the number of obstacles per section to circumvent. Each part will have their own respective A to B start and end points and each section is allocated to one core each. The final route might not be the most optimal one to take but at least it doesn't bog the game down. So now, a process that would use one core at 80% would use all cores at 20% and the remaining 80% of CPU time of each core can be spent dealing with the not so heavy routines. But then again, as the rest of us, i don't really know what the real problem is because, just like the rest of us, i don't have the source code in front of me and thus have no idea what can and cannot be done under the limitations of what's already there. If whatever suggestion someone comes with means re-doing too much code then the game will fail due to one of the following: The developers simply don't know how to make it work, so they would need to spend tons of hours learning. Time lost that could be spent on actually making the game in the first place. The time spent re-doing the whole thing means the game features suffer. Time spent makes the game miss it's deadline which means the budget goes out the window and the game becomes vaporware and developers are out of a job. So in conclusion... Prior Planning Prevents Pi** Poor Performance It's most likely too late now and the next release will suffer similar problems to those of ARMA 2. For whatever next release in the future (no matter what game studio we are talking about) they need good developers that actually are capable of harnessing the full power of both CPU's and GPU's of the future. And of course, this should be taken into consideration from day one! //Cadde (Known as PLRSniper from 14 years ago playing Delta Force 1 and OFP 1985)
-
The trouble with getting people into Arma
PLRSniper replied to instagoat's topic in ARMA 3 - GENERAL
To be quite honest. The reason MY friends never gave the game a fair chance was because of the clunky controls. It had nothing to do with it being too hard to get into the game and running it but more around the fact new players feel absolutely paralyzed. Even a player without hands would have greater success in CoD/BF than they do in OFP/ArmA games. Not due to the fact CoD/BF is easier but because of the character controls. If BI studio can make the controls feel more natural then i am sure more casual gamers could get into the title and play it the way it's meant to be played. There's nothing wrong with a realistic simulator but when you feel like a man without arms and legs controlling your character you quickly lose interest in the game. It just feels so offset from reality where we can walk, run and jump without having to think twice about it. Another way of saying it is... Where in real life we just DO it, in ArmA we have to make a complicated instruction set to simply point the weapon at another person. -
Does anybody know how many DoF A3 will have?
PLRSniper replied to cpl_hicks's topic in ARMA 3 - GENERAL
Ultimately we would have something that is better than TrackIR. (Not that TrackIR is bad) I am thinking VR goggles with at least 1920x1080 resolution and motion tracking allowing you to move your head freely while controlling the weapon with your mouse and your legs with the keyboard. Or in the case of aircraft, your head / targeting systems with the tracker attached and jet/helicopter with the joystick, paddles and throttle. Unfortunately there is no affordable (consumer grade) VR goggles that actually work yet. (AFAIK) But the moment a company makes 1920x1080 goggles with tracking i will be on it in a jiffy. And in the future we should be seeing better interfaces such as intercepting our brain activity and translating it into actual in game actions. We try and walk in real life (at the PC that is) but the game hijacks the signal and makes the avatar (solider) walk in game. Yeah, one can wish. For now though, VR goggles and 6 DOF will have to do! :D -
I would like to see dev blogs on how you are going to tackle the gameplay side of things. So far all i have seen is screenshots and videos but what is most (or at least more than equally) important is gameplay. Especially multiplayer! * Will the control scheme stay the same? (If it does then i will not get the game, seriously) * Are you dedicated to fixing lag issues until they can't be noticed anymore? * Performance issues, in titles past we players have reached a point where hardware updates simply doesn't make the game any faster no matter what we do. (For instance, OFP1985 still isn't as smooth as it should be on today's hardware) These and many more points revolving around game play where one can actually enjoy the game beyond the simulation aspect of it. I want to feel like I AM the soldier, not someone sitting at a computer monitor remote controlling a fleshy robot in a fishbowl.
-
Arma 3 with 1,000 players online .. possible?
PLRSniper replied to CaptainBravo's topic in ARMA 3 - GENERAL
A lot of posters in here assume a lot of things... First off, the difference between an MMO and FPS is that MMO's are effectively turn based and as such doesn't rely so much on real time feedback. Say you want to cast a spell in an MMO, it doesn't matter that much if it takes 20 ms or 1 second for the spell to take effect. However, you fire a sniper rifle at a target 1,000 meters away at a moving target. If your latency (ping time) is around 100 ms that means the target might have already moved (server side) away from the bullet impact (client side) even if you "see" the bullet hit. This can be somewhat remedied by lag compensation where you are "close enough" to being accurate so you are awarded the hit even if the target isn't in the position you see it being in client side. The problem with "too much" lag compensation is now other clients will get killed in seemingly impossible situations. For instance, walking round a corner thinking you are safe but getting caught by a bullet that seemingly flies round corners. So, in a perfect world... Everybody would have a ping time of < 50 ms thus making it hardly noticeable that there is any delay at all. This is only possible when players are CLOSE to the server in question. (or at least have a nice clean line to the same) The other difference is the amount of information shared between server and client. Where an MMO sends simple information per player like position, rotation and the very most basic health and appearance information... A FPS game might send the same information ALONGSIDE information about each (*) bullet flying in the air. It's direction, speed and type. There are vehicles involved which each are equal to a player and then some. (turrets facing their own ways etc) So the amount of information being passes around in a FPS game is greater than that of your average MMO. Assuming a pretty standard 24 bytes per player/server frame that is 24,000 bytes * 20 = 480,000 bytes/s at a server frame rate of 20. That alone would require a 4 MBit internet connection to receive. (Myself I am sitting on a 100 MBit/s so i wouldn't even break a sweat) But now, all players are shooting their weapons. That's an additional ~16 bytes of information per bullet (that is, bullets seen by clients) which ups the requirement to at least 8 MBit and that is before we consider all the other events happening on the server. So there is a large hurdle to overcome in terms of client internet connections alone for a 1,000 player server. * - Most games doesn't send ALL bullets to the clients. For example, full auto fire is reduced to something line 2 bullets per second where the server gets information about 10 bullets per second from clients. ... Now, the server itself needs to cope with 1,000 players doing all sorts of stuff. Consider that clients on full auto will send information about up to 10 bullets per second. That "may" be 16 bytes * 10 = 160 bytes just for the fire event. Now, multiply that by 1,000 (160,000 bytes/s, 1.28 MBit) for bullets alone. The server deals with ALL these bullets ballistics to ensure the server gets the final say in who gets hit and who doesn't. (Unlike BF3) That is a HEAVY load to take server side. Additionally, the server now have to decide who is lagging and who isn't and when a "miss" is actually a "hit". --------- I am not saying it is impossible to make a 1,000 player FPS game but we might want to take smaller steps instead of simply upping it to 1,000 players because "we can". As for other games allowing 256 players etc, that boils down to "what did they drop in quality in favor of player count?" Quality over quantity any day! As for teamwork, it doesn't matter if you have 10 players or 10 million players. If a chain of command exists that WORKS the teamwork will work just fine. It will be a larger logistical challenge but it's a matter of effort...