10t

Without in any way suggesting where it should come in the development priorities list, I just want to add that I'll appreciate some furniture in buildings. I've just finished building a (clumsy, inept, but personally satisfying) mission that involves entering a few key buildings. I spent frigging hours learning about SetPosATL and AttachTo in order to furnish some of the rooms believably. My reasons were threefold: 1) Camouflage - Clearing buildings is so much more of a challenge when it's more than just "There is something in this room that isn't a featureless wall: shoot it". It's the indoor equivalent of the trees and rocks all over the outside portions of the island. 2) Immersion - It makes the buildings feel about a billion times more lived in, which helps me (and hopefully the dudes I'll play it with) get into the vibe ("It's Mabo, it's the Constitution...") of the story. Without which there's not really much point. 3) Eye candy - Fine. I like pretty things. I'm ok with that. Sure; it took ages to do, the AI pathfinding in the populated buildings is a bit messed up (but still works where I need it to), and I might have lost 2 or 3 fps because of it but I was happy to do it because of the above rewards. I guess that all I'm saying is that several mission makers will get a lot of value out of a bit of furniture in places. I have no idea what the best implementation will be, nor who should do it, nor when it should be done. Trying to balance ease (just pre-populate the buildings with stock furniture!), with flexibility (and this will be the briefing room, and that will be General Gubaslavislav's office!), and performace (give me All The Polygons!) is not something I'm equipped to do, but any increase in furniture (including optional furniture) will be an improvement on the Island of the Damned vibe we've got going on now. And whoever does it will have my gratitude.

It was the relevance to point I was trying to make to Windies that I got. Hence my "I get the relevance of what you're saying...". The fact that the headless client (and and the concurrency it involves) increases performance I've been well aware of for some time. Maybe February. You'll notice that nowhere have I suggested that concurrency can't, won't, or doesn't increase performance. But given how unclear I must have been for Windies, and possibly you, to have missed the distinction since page 19 - yes: those posts have all been pointless.

I'm more and more convinced you haven't actually read anything I've written in this thread. You've written 1188 words (each one of which I've read at least twice) disagreeing with my point so far, all I ask (again) is that you summarise what it is you disagree with in two sentences: Until then, I can't imagine that we're actually communicating so anything more I write would be a waste.

I was actually after a summary of my posts, but I get the relevance of what you're saying now. Yes, that is an excellent example of increased concurrency leading to better performance (measured by performance, not by CPU usage). I think if this discussion were made entirely of examples like that, it'd be much shorter, get less resistance, and have a better shot at convincing the devs to invest time in increasing the concurrency or threadedness (or whatever) of the engine. That single example (especially considering the overhead of running a second entire executable) should maybe even be enough to settle it all on its own.

Ok. I get what you're saying. I don't have any idea how it's relevant to anything I've said, let alone the bit of my post you quoted. Could you do the summary thing I mentioned (in the paragraph immediately before that) for me? Otherwise I can't reply sensibly at all.

Laser would be tied to the stencil/binoculer movement. And yes, I doubt it'd be easy to implement, since it would make binos/rangefinders/designators the odd ducks out when it came to weaponry sway. Definitely an idle, hypothetical comment. Still, would be interested to see how it would feel to use in game.

To address the issue of eyes doing a good job of compensating for sway while still making lasing while standing realistically difficult, what if the view was still but the stencil had the sway. Best of both worlds? His video is a direct response to someone's complaint (quoted immediately above the video) about sway while prone.

Well, yes. If you had used different words, then what you wrote would have meant something different. And the distinction between those two things and why it's important is what I was pointing out. Though, if you had put it that way, it would have been a little at odds with the rest of that post. Even the rest of that paragraph. You're quite right - saying it's unimportant would be misleading. That said, I've seen no-one say that process concurrency is unimportant. Maruk's post which you responded to was in fact him pointing out the difference between the statements "concurrency is not a goal" and "the number of threads avaiable for resource handling won't improve current RV's state". To which you replied (in part) "hardware usage is exactly what you want to measure". Which prompted my post, re-stating the difference between those things. I truly hope it doesn't, since what I'm saying applies not just to process concurrency but to "ways of trying to make things better". In any field. IT, business, medicine, gardening, cheesemaking. Do me a quick favour, if you would. Summarise in a sentence or two how you'd express "my whole argument" - the one that goes against the tide of technology. It'll help me work out what I'm saying that isn't sufficiently clear and we can work from there to some common understanding. For my part, I'd summarise your point as "All else being equal, an increase in hardware usage (under load) means an increase in performance. Therefore the focus should be on increasing the amount of hardware usage available to the engine and the success or otherwise of that effort can be measured by hardware usage".

Actually, how about I quote it, as I did in my first reply in this thread: No. "Better" concurrency is a way to achieve better performance. Even in your own quote of yourself, it's clear that you said "better concurrency is the way to achieve that goal" (emphasis added). And everything I have written since has been in response to that. You're right, it should have begged that question. Because I don't think I argued anywhere in any of my posts in this thread about how performance is achieved within the engine. All I have said anywhere in any of them (collected here for your convenience: 1, 2, and 3) is that it's important to be careful to measure the right thing to achieve your goal in order to achieve it the most efficient way. Again, I really think you aren't actually reading the words people have written. You might want to re-read the posts you're complaining about being full of "smoke and mirrors" with an open mind, because I think at least some of the smoke is a misconception or prejudgement on your part about what they actually say.

This might be a semantics thing. Concurrency is the wrong metric (standard of measurement) for Performance. It's also not the goal. Goal: Performance increase. Relevant metrics: FPS, graphical quality, number of objects displayed simultaneously, responsiveness, entities simulated (bullets, vehicles, weather, etc). Tools available to achieve Goal: Concurrency; code efficiency; other clever things I don't know because I'm no programmer. How about this hypothetical example: What if BIS rewrote the code in a way that was totally multi-core aware and could exploit 100% of the power of every core when needed? That sounds great, but if it didn't improve my experience (as measured with the above metrics) then it's no help. And it's possible it wouldn't improve them. It's even possible that a rewrite to that model would reduce performance (the spawn idle-loop threads mentioned above is an extreme example). And sure, doing that work to make the engine worse would be ridiculous - but it demonstrates that measuring concurrency on your machine now is not a valid way of measuring the performance of the game. Then again, if the rewrite did improve those metrics, then it would have improved performance. Or another example. I was nearly going to write "complexity of simulated entities" in the metrics above. But I was about to make the same mistake. I don't care how complex the algorithm defining the behaviour of flocks of birds in a game (for instance) is. All I care about is their veracity. Increasing the complexity is one way to do that (e.g. individual neural networks and self-programming expert systems for each bird), but if I can come up with a simple algorithm that mimics flocking indistinguishably (the "maintain ideal distance from neighbours" idea) then I've done a better job. Similar things could be said for armour penetration. Simulating every rivet and internal stresses around weld seams would be one way to increase the armour penetration veracity. But a cleverly weighted random dice roll with a few key input parameters might do an equally good - or superior - job, and therefore be better. Really, I'm not saying anywhere that "increasing concurrency won't improve performance" or "BIS should not invest effort in increasing concurrency", just that it's not a valid proxy for performance and therefore not a goal in and of itself.

I hope not; I wasn't trying to. I was trying to say the exact same thing Maruk said and has said before. And what Ondřej wrote back in 2009 which Maruk keeps referring to. Particularly the paragraph "Goal and Means". What I wrote could maybe be restated as "The performance problem is multidimensional, and focusing exclusively on only one of those dimensions may not be the best way to increase performance." Let me put it this way: If BIS can improve performance overall by 10% in 2 years (assuming it can be objectively measured and expressed that way) by working on increasing concurrency, or they can improve performance by 20% overall in 1 year by doing "something else"0, then I hope they ignore concurrency and focus on the "something else". I've re-read your post and mine a couple of times, but I'm still struggling to see how you're interpreting my post. Particularly the "Yeah man, that must be why ArmA 3 is the bastion of typical PC gaming performance....." bit - I don't know where I said anything that could be read as any sort of comment on Arma's current performance, let alone "Arma performs well". Perhaps you could read through it again with the above in mind? At any rate, all this has been discussed already in the threads I linked to above.

Well... (putting my pedantic and off-topic hats on) it depends how many decimal places you want to measure to. It doesn't "remain absolutely same" - F = G* (m1*m2)/(R^2). As you descend, you get (veeerrryyy slightly) closer to the planet's centre of mass, so R gets (veeerrryyy slightly) smaller, and so gravity gets (veeeerrrryyy slightly) stronger. Of course, it's difficult to measure - and for almost all practical purposes 9.81m/sec^2 is accurate enough over the altitude range most of us will ever care about. But I wouldn't be saying "absolutely same".

When I'm on public servers, I meet a fair few players who are new to Arma and have NO idea how the comms channels work. They're not the "headless chickens" of the earlier post, and they're keen to learn how Arma works and appreciative when given a quick run-through. But they're treating Arma like a game they can pick up without doing a full background dossier first. Which means that videos like the above, most in-game tutorials, or info on the website (let alone the wiki) just won't get to them. They're not even aware that the information could exist to be looked for. I take the OP's point that it would be good to easily and automatically let new players know how comms work. I don't know the best way to do it, though. Perhaps an extension of the Field Manual/Hint system? One where it automatically pops up the multiplayer comms guide the first few times a profile is used in MP? Or once the first time, and then again the next three times they use text chat and/or voice chat?

No. "Better" concurrency is a way to achieve better performance. And, to me, the definition of "better concurrency" is "some level of concurrency that improves performance" - not necessarily "increased concurrency". Measuring concurrency is only a valid measure of performance if nothing else changes. If something else changes in the way the engine works (as it sounds like it would have to in this case to increase concurrency) then we don't know what the actual effect on performance would be. And performance improvement is the whole point of the exercise. I, personally, would be happy to see a reduction in concurrency if that somehow improved performance. Because I don't care what my CPU's doing, or if my expensive GPU is somehow offloading calculations to the RAID controller, or if my RAM is being bypassed entirely and everything's being done on HDD cache - if all that nonsense somehow makes the game run better then I've scored a win. This whole issue reminds me of what I see in business or engineering, where people focus attention and effort on things that are easy to measure, rather than the things they should actually care about. They choose a parameter which is one of several important parameters and optimize that without an understanding of the effect of their actions on the whole system and therefore the final result they're after. For example, focusing exclusively on improving cashflow without proper consideration of the effect on long-term profit & loss. Or on maximising combustion chamber temperature (which is a driving factor in thermodynamic efficiency) without considering the related increase in wear, servicing costs, cooling requirements, and therefore the true impact on total cost to run - which is the real measure of success. BI should be maximising the ratio of game performance increase compared to their effort. If increasing concurrency is the most efficient (in the performance gain per effort measure), then that's what they should focus on. If improving the algorithm efficiency in a single thread can achieve the same performance gain for less effort on their part, then they should do that. And if changing 15 different things in 15 different ways (some possibly related to concurrency) is the best, then that's what they should do.

I'm confused by the Chernarus bit. If the forests are ok in Arma 3 on Chernarus, why would they be worse on Altis?

I just got my "has shipped" email. Any guides to setting it up with A2?

You really want the vocal majority to be bouncing around in the Dev version? The ones who struggle to tell the difference between vanilla and Wasteland? It doesn't hurt development that they're using the stable branch, so what's the problem?

And don't forget Lemnos is 250km (150 miles) North East of Athens, so the sun's up there 12 minutes before it is in the capital. FWIW, I don't disagree that the sun's up too early. daze23's screenshot is an obvious example. I just wanted to correct the notions that the sun should rise at 6am (mentioned by several in the thread) in the middle of summer, and that Greece is a single tiny place which sees sunrise all at the same time. Edit - ninja'd twice while trying to edit posts with my phone.

Um, you "Sun rises at 6am in Greece in July" people aren't forgetting daylight savings/summer time, are you? Wolframalpha shows a sunrise of 5:52am EEST on the summer solstice this year. So, "normal time" (and I'm guessing BIS haven't modelled winding the watch forward for summer time) puts sunrise at 4:52am. Followed by a 15-hour day.

There'a a (no-doubt known, but I haven't checked the tracker) bug where you need to drag some things from CRATE to GROUND, and then drag from GROUND to your inventory. I haven't had a case yet where that workaround didn't work.

I can see this thread getting moved to one of the Editing forums, but understand why it started here. "G throws Grenades" is more of an issue for long-time Arma players, who are deeply programmed to hit "G" for "Gear", instead of "I" for "Inventory". Players starting with Arma 3 won't have that disability though, so can safely leave Grenades on G. Personally, I bound Gear straight to G and Ctrl+G to Grenades. Works a treat. The "When UNIT enters LOCATION1 -> Action: Move all UNITS from LOCATION2 to LOCATION3" bit is pretty trivial to do in the Editor with a trigger. Create a Trigger of size LOCATION1 where you want. "Group" it with UNIT. "Synchronise" it with UNITS' waypoint at LOCATION2. Have another waypoint at LOCATION3. Have a read of Mr Murray's Editing Guide: Armaholic. It's old but an excellent resource to get started. Gear in boxes you can do now without "scripting", if you mean "without creating SQF files and calling them". If you're talking about putting including lines like this addMagazine "30Rnd_556x45_Stanag"; to the Init field of the box, then I doubt it's going to get any GUIer. There are tools you can download from (again) Armaholic which build gear loadouts for you though, so at worst it's a matter of copy-and-paste. Right now I'm enjoying myself making absurdly scripted, overwrought, unworkable, and buggy missions. They're basically unplayable and the logic's too easily accidentally bypassed by players, but I'm having the time of my life.

FWIW, it can mean "they are mistaken", which is very different to "they are lying". Back to the topic, no: I'm not interested in Arma trying to model a bullet's path through weapon optics. I *would* like to see weapon damage made possible. I get a bit frustrated when I see three rounds ping off an AI's gun, only to have him shoot straight back at me with it.

BIS don't seem to be pushing too hard. Most of their comms have been through arma3.com, their twitter feed, and Facebook (I guess - I haven't been looking there). They've been showcasing Dslyecxi's YouTubes on their channel too, but only a few and only occasionally. Most of the interweb chatter I've seen has been generated by other people and some of the Game Magazine websites. When you say "Not seeing a lot of replies to posts...", do you mean from BIS themselves or that there's not much movement on the forums? If the latter, I guess it might be because of the stricter/more mature/better-refined/banhammer-happy (pick the descriptive phrase you prefer) moderation here. Duplicate threads are cleaned up and threads that have wandered into an unproductive abyss of off-topic ranting get closed. I personally reckon it pushes the quality:quantity ratio up. There's less flurry than I've seen in other boards and that can make it look a little stagnant sometimes. If you're talking about replies from BIS, the BIS team respond to a few things on here but mostly only when they have something useful to add. And there's the feedback tracker, of course. AFAIK they took Arma3 to the last two (three?) E3s. What sort of info is your friend after? There's a good chance it's out there, but it isn't being rammed down anyone's throat by a monstrous marketing machine. Many of the questions he has are likely answered here, on the Armaholic site, or in user/reviewer YouTube videos. I'm not worried that there's insufficient advertising. It looks like there's already concern amongst the crustier veterans here that there's too much already and it'll "bring the CoD kiddies" in and, I dunno, Arma will turn into Tetris or something. My guess is that it'll grow slower than it would with a big campaign, and that will probably lead to "the right type of gamers" finding it - people interested in the genre and willing to put the effort into learning a new style of game. Because, face it, if someone's not willing to spend 15 minutes on DuckDuckGo or Google, they're probably not going to enjoy learning the bajillion different quirks to Arma anyway.

The main island was "re-named", not "scrapped". So don't get your hopes up.

In this context, does "terrain" include environmental objects like water tanks, railings etc? Obviously I, too, would like to see exposed metal surfaces appear hot in thermal vision systems during the day.