10t

Updated 2014-06-13 Version 0.2 of Stratis, Takistan and Zargabad added (slope shading improved, but the colours might be a bit too dark). Added Chernarus. Completed zoomable Altis . Click the pic below to see it in action (apologies for the slow server it's on; it's very cheap): Here are some example thumbnails of the first maps I've finished I thought I'd finished but find myself continually revisiting. Click the thumbnail for zoomable version: Stratis: v0.1: to v0.2: Takistan: v0.1: to v0.2: Zargabad: v0.1: to v0.2: Added 2014-06-13: Chernarus: Altis: Feedback: I'm not sure the colour balance and intensities I'm using are right for the sorts of things people might want these for. The latest set seem like they're probably too dark. I'd appreciate people who are thinking of using them letting me know if the maps would work better for them looking some other way. Usage: In themselves, these don't change gameplay at all (but if someone can generate PAAs or something to replace the in-game map with these then please do!). They're just available for people to use in their other out-of-game tools and things (like the AAR generator, Realtime Browser Map, DayZ loot maps, etc.). If you are planning to use them, be warned that the 100% zoom images are NOT 1px:1metre. They're (mostly) 2.2px:metre. Make sure whatever web app thingo you're doing can handle that or not care. Download: While you can write a wget or use a website downloader to grab all the tiles off the server above, I'd prefer you didn't. There are zipped collections here. New maps will be added as I upload them: Stratis v0.1 Stratis v0.2 Takistan v0.1 Takistan v0.2 Zargabad v0.1 Zargabad v0.2 Chernarus The Altis tiles are split into three, since the two highest-resolution zoom levels are enormous and may not be any use to some people anyway: Altis (zoom levels 2-7: 251MB)* Altis (zoom levels 8: 627MB)* Altis (zoom levels 9: 2100 MB)* NOTE: The zoom level folders in the Altis zips are named wrongly as 0 to 5, 6, and 7 respectively. This works fine in openLayers maps, but will mess up Leaflet. MAKE SURE YOU RENAME THEM as per the Zip filename. Background guff:

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.

Hey Nex. They're a combination of screenshots of the ingame map and shadow maps and height fields generated from the map.wrp in the map PBO. I know that the topology cheat lets you get an EMF, but I was having issues exporting the files (solved by running as Admin, duh) and then when I finally got them out I've struggled to export them to raster images at the resolution I want. I've been playing with translating them into SVGs and manually cutting them into layers (roads, trees, buildings, MGRS gridlines etc) to recombine again later in different ways - which also reduces the filesize - so I may go back to that later. To get the screenshots at the resolution I wanted (I needed 3090 for Altis...) I wrote a script to pan the map around at a given zoom and trigger an external Python script to press the Steam screenshot key. A bit overwrought, but it did the job. Then imagemagick made it easy to trim the screenshots and stitch them back together ready to edit in Gimp. There's an example of how I put Stratis together here. I like what you're doing with Axyl's AAR generator/viewer. If you can get these tiles to work with leaflet without being misaligned from the unit markers, let me know.

Hey Axek, inexus, I'm having some issues with markers being offset when I try and use the Leaflet AAR viewer with my own tiles. I've had a crack at fiddling the scripting in both the MAAS viewer v0.3 (here) and with the code inexus posted (here). In each case the scaling's off but fixable, but I have no idea how to fix the offset (the map appears too far south, relative to the markers). I explored customising the projection using proj4js, but I'm pretty sure that's a dead-end unless I go and adjust the marker placement too - and that's what I want to avoid. I also thought it might be because the Altis map is wider than it is tall (I left some rows out) after reading some things about Leaflet disliking non-square maps, but I have the same issue with my Chernarus tile set, which is square. Can either of you think of anything obvious I'm missing? I'm sure it can't be that difficult to include a global offset for each tile set - at least I hope not, because the bottom-left extent of my Altis set isn't at 000000.

Absolutely! The more places I see pretty Arma maps, the happier I am. Give me a shout if you need to work on getting file sizes down or any particular resolution. Yep - I'll post them here and PM you when they're done. Nice work on the Real time browser. Altis - if I do say so myself - is looking good. First post updated.

Updated first post with Altis developments.

CC isn't compatible with this clause: I think it's pretty reasonable for BI to limit the use of their work to the Armaverse.

The '%1' is saying "Replace this %[number] with value of the the FIRST thing after the comma". If you have multiple things in there that you want to display, you can use multiple %[number]s. e.g. hint format ["m1 position: %1 m2 position: %2 m3 position: %3", markerPos "m1", markerPos "m2" ,markerPos "m3"] ^ is one I've used while debugging to check that my markers were in the right spots. The '%3' looks at the THIRD thing after the comma (in this case 'markerPos "m3"') and translates it into text that 'hint' can display (something like '[111.01, 909, 0]'). More information about how format works is on the BIKI. The '_this select 3' is special part of the addAction command that gets any arguments passed to the function. You can see that the argument in your example is '_playerHealth'. So that variable gets given to the script you gave the addAction(everything in the '{ }'s) when it's triggered. The format sees it, decodes the value of the variable (in this case some number between 0 and 1), converts it to text and hands it over with the rest of the string to 'hint', which displays it to the player. '_this' is a special case of variable, called a Magic Variable. All the links above are to the BIKI which - once you can figure out how to find what you're after in there - is an excellent resource for understanding Arma scripting.

Hey Democore, just going to pimp those tiles I mentioned :p Hope to see them in your browser.

_playerHealth = (1 - (damage player))*100; Because of BODMAS. And yes, multiplying it by 100 accounts for turning it into a percentage (from "per cent", or "per hundred". i.e. "divided by 100" - so multiplying it by 100 at the same time as adding the '%' means it stays the same number).

Hey DemoCore, this is looking freaking sweet. Dunno if it helps, but I've just recently been working on making some Google Maps API-compatible tiles of the A3 & A3MP topographical maps, but with better height-shading (because I can't stand the current flat ones in-game). I'm planning to use them with Axek's awesome Automatic AAR generator - if they're any use to you you're most welcome to them. I should have the A3 maps and most of the A3MP tile sets done in the next two weeks. There's a very early (ignore the watermarks, the broken tiles, and the lack of height-specific colours) draft of Stratis here. And here are some samples of Takistan: Full map: Larger (1024px - 1.7MB) 100% zoom: Larger (1.1 MB) Another (400 kB)