10t

People keep making that claim. Surely that only means that the display needs to update at 90 FPS (reacting to head movement), while the game itself could update at a far lower rate with no ill-effect. The two framerates are decoupled in the same way that monitor refresh rate and game FPS are. As long as the head movement is smooth and reactive, the game framerate should be no more important than normal, right? If I can smoothly look around at a static scene, how can that cause motion sickness? Sure - the rendered FOV would need to be much higher in each frame to allow for me to turn my head before the next frame's rendered, but that's within Arma's existing capabilities. Or can someone explain to me how I've got this horribly wrong?

I've long been frustrated by how short-lived the smoke clouds from explosions are in the Arma series. I'd love to be able to have some persistent post-explosion/bombardment dust as seen at 1:30 in this video from Syria (potentially NSFW, I guess) - something that lasts on the order of minutes, at least (for big explosions). Rolling into a dusty Kavala after a substantial MLRS bombardment is an enduring fantasy of mine. I understand the tradeoffs involved in traditional particle-based smoke-clouds, and definitely appreciate playing in clear air at 50 fps as I do now, compared to playing in satisfying dust at 0.3 fps, so this isn't just a complaint. My real question is, given the fog system that A3 includes (very well!), is it possible to apply that in some localised way? It can already handle several parameters (falloff, density, and altitudes). Could it be extended to have [x, y, z] co-ordinates, major- and minor- axis lengths, falloff, and shrinkage/dissipation rate? Or is this an engine/DX11/SimulWeather/something limitation (obviously I have no idea how fog's implemented in RV) that is just impossible? Obviously, even if it's possible at all, a million tiny instances of fog over the island would end up being yet another performance-eater. I have a vague idea of a Game-Of-Life -style mechanism which would continually combine and simplify nearby/overlaid clouds into single entities over time, which would reduce the problem. Anyway, are there good technical reasons this can't be done? Is my dream doomed? Or is it feasible that one of the devs could go on a caffeine-and-amphetamine-fuelled coding rampage and implement it one day? Lastly, sincere apologies if this was posted before. My searches of the forum were hampered by the word "fog" coming in under the four-letter search threshold. Similarly, if this should be moved, please go ahead.

Being dual-rotor (tandem/coaxial), you wouldn't expect either one to need anti-torque trim inputs, if that's what you're referring to. The rotor torques cancel each other out.

You already have this option: 1) Go to editor 2) Add unit -> Nato -> Air -> CH67 Huron 3) Make it "Player" or "Playable as Pilot, Gunner" 4) Preview 5) Try before you buy.

Of course. I just know that leaving it all up to the modders (who've already obviously invested an awful lot of time and effort into making the mods themselves) to also do all the legwork of chasing those infringing their rights has got to be exhausting and discouraging. If they can be given the form (by anyone, doesn't have to be AMAR) with all the pertinent details neatly filled in and ready to go, then they can just send it on in themselves or approve "or an agent authorized to act on their behalf" (to paraphrase the form itself) to submit for them. I'm no lawyer, so I don't know if "agent authorized to act on behalf..." has any specific meaning in this context, or if it can just be "my buddy who I told it's ok to do this for me". I get the feeling AMAR, or one of their representatives, might have more flexibility here. Most of the answers to the questions in the form are pretty much included in this thread, and the locked one. All we need to do is answer them for each of the aggrieved modders - that is, separate out Tonic's, Gnat's (I think?), RobertHammer's, and Milkman's content which has been used in ways that contravene the license and bam - four forms to trigger Paypal to start the investigation for us. For those who haven't clicked the link, here's the main bulk of the form content: The other required information is the IP Owner's identity which is why - if anyone's going to submit this on their behalf it should be someone they trust, who I guess would include some AMAR representatives. Or this can be left blank for the modders to fill in themselves before submitting it if they prefer. Lastly, although the answers are very similar in each case, one of these should be filled out for each affected modder (i.e. "IP Owner"). That's the way the form's structured the way Paypal expect and is probably set up the easiest for them to process effectively. If any of the IP Owners (or forum moderators, I guess) care to comment, or feel that this isn't appropriate, please let me know and I can butt right out. Otherwise, I hope this helps somehow. Edit: Oh, since this is notifying a private company (Paypal) of a breach of their Terms and Conditions by a third party, I'm sure you don't need to meet the same burden of proof as you would in a court. If Paypal decide that this duck looks, swims, and quacks enough like a duck that it breaches their terms of use, then they can take the action allowed by their Policies, NOT the law. They encourage people (not necessarily the aggrieved party) to report violations of their Acceptable Use Policy - as you'll see if you look around their Legal section. ---------- Post added at 12:02 ---------- Previous post was at 11:52 ---------- Are you sure that those donations aren't just the records of donations to the .com one, duplicated from the original website? I thought that the "donations" on the .net one stop on the 6th, making me think that's when GoatBoy copied everything. I'll admit I haven't looked into it at all, though. Didn't even click the button to see if it goes anywhere (it'd be pretty funny if the site was such a faithful copy that donations on .net accidentally ended up going to .com :p).

Additionally my suggestion above and according to the idea of "follow the money", I'd recommend all the affected Mod makers/IP holders to submit Infringement notices to Paypal. I'm in Australia, so this is the page Paypal directs me to: Infringement notices and this is the PDF Form to fill in. Depending on where you live you might want to visit the page yourself to get a locally-oriented one. It's available through the "Legal Agreements" link at the bottom of each page. eggbeast, is pre-filling a form like that something that AMAR could help mod-makers with?

This. The best way to test would be: 1) Start two applications with equivalent but different details (say, "Donald the Donor" and "Fred the Freeloader") 2) Donald makes donation, Fred doesn't. 3) Presumably Donald gets access, Fred doesn't 4) Donald plays for a few days, Fred waits. 5) Donald cancels/charges back his donation through Paypal 6) Presumably, Donald loses access Q.E.D: Access is paid for as a commercial operation, not free with voluntary donations 7) Evidence (transcripts, emails, dates, screenshots, client .RPT logs and dated gameplay videos), the BI EULA, Paypal and Hosts' TOSes, and mod licenses are bundled up and sent to BI, Paypal, Microsoft, Crytek, CloudFlare, and A3L game and website hosts. 8) ????, but hopefully it includes the website coming down and Paypal freezing the account 9) BI forums celebrate resounding victory, I guess. No need for BI to stick their necks out or for getting any lawyers involved. We ought to be able to tickle Paypal and some hosts into taking action directly. And frankly, cutting the money and visibility off is where it's going to hurt A3L the most. What have I missed?

Calling it "malware" is quite the exaggeration.

I read through the thread, and noticed that someone mentioned that it had been removed from ModDB. It looks like they've resubmitted it, or something: http://www.moddb.com/mods/arma-3-life1 I don't know anything about ModDB, but someone might want to ping off another email and get this one nipped in the bud too.

What I was trying to say is that I feel about instant-changing pods (and, to Alwarren's point, fuelling and repairing) like a lot of people feel about the instant-heal First Aid Kits: they're much quicker and easier than the real activity would be. Which is why I'm not bothered that instant-changing pods aren't available. Don't get me wrong, I wouldn't complain if they added it - it just isn't an issue for me if it's "missing". Fair enough. I'm pretty open to the idea that they could be designed as quick-change units. It's only that I think the reason we don't have any comparable aircraft around now (that I know of) isn't because of a lack of technology (quick-release couplings have been around for decades) but because the weight/cost/complexity/reliability/tactical flexibilty tradeoffs don't favour it - and likely won't in the near future either. I'm ok with seeing boring engineering cost-benefit analysis take a backseat to gameplay awesomeness though. If anyone were interested in scripting a solution, my approach wouldn't be to use attachTo. Instead I'd spawn a heli of the appropriate variant, switch the crew from one to the other, spawn/remove the separate pod, delete the original heli and put the new one in the original's position. Ensures you have the appropriate Flight Model effects of the right variant and hopefully no wackiness from a confused engine.

Considering how many hours changing from Medivac to Cargo would probably take (supporting the pod; disconnecting it; disconnecting electrical, pneumatic, and aircon supplies; lowering and removing the pod; blanking off the electrical, pneumatic and aircon supplies; moving the Cargo pod into place; aligning and lifting it; and connecting the pod), I'm not bothered at all by the inability to insta-switch the pods. It's probably only one or two hours, which is pretty quick in a strategic sense and a great selling point from a logistics point of view, but not the sort of thing a pilot would do on a whim by hitting a button. I base my estimate on experience changing RB211 and CF6 engines on A330s, 767s and 747s. It's only 8 bolts and a couple of fuel, electrical, pneumatic and hydraulic lines, but it's a solid 12 hours work for 10 blokes. If it really bothers you, write a script that switches between Taru models and creates/destroys the separate pods as required.

Refer the previous page: and here, here, and here.

... and working great! Thanks again X39 - awesome work.

Glad to hear it. Imagemagick also has a nifty one for those who don't want to mess with Python: montage -mode concatenate That's weird - do you have an example uploaded somewhere that shows it? What do the two links I posted look like? Is the tms:true one rendering ok in your browser?: Is the other one showing up backwards?: Or is it something else? As for the scripts, I'll dig them up and put them on here. They're pretty ugly (really ugly) so you shouldn't expect a great user experience. Probably better - if it's still an issue - is to just rename all the tiles to the alignment leaflet expects (0 at the top, increasing to the bottom). Super quick and easy to do. Not sure about openLayers. It doesn't seem as fluid and pleasant to use at Leaflet. Might solve some problems though, which could make it worth it.

AFAIK, they actually are TMS. If you set the flag tms: true, in the tileLayer definition then they'll line up properly (very brief leaflet docs reference here). Here's one of the tests I was doing aligning markers to known points (you might need to scroll up, depending on your browser window size): With tms: true Without tms: true The second one's identical, except line 61 was deleted. Otherwise, if it's a tile numbering issue I can just knock together a script to rename them all in bulk - much quicker than regenerating the tiles, believe me.