ianbanks

Try comparing histograms too; this histogram of one of the A3 buildings for example shows they aren't using any RGB colour values above around 200:

"Cannot generate ST coordinates" errors occur when your UV map has a triangles or quads with co-linear or coincident points in the UV or 3D (it might only be UV, but your model shouldn't have colinear/coincident points in either 3D or UV because if nothing else it's a waste of polygons that will never display). Arma needs to be able to convert from any point on your UV map to a unique point on your 3D faces and vice versa. If all your UV points for a particular face are on the exact same point, or all 3-4 points fall on a straight line, then it's ambiguous which 3D coordinates correspond to the UV point.

Altis and Stratis have fairly strong "middle distance" textures that roughen up the areas that are too far out to have clutter or parallax applied (which means the blending between clutter and distant terrain is much smoother). You can only have one middle distance texture though, so a rough one that looks good on grass and rocks probably doesn't look any good on snow. It might just be that you're noticing the jump to mid/far textures more, rather than the distance of the clutter itself.

Heh, that mission looks pretty entertaining. Hmm. Raptors are based on CAMan, I think, which means it should actually be possible to make a Santa uniform for them. Pity there wasn't more time before Christmas!

Santa's Combat Sleigh By Jeck and ianbanks Download Link: http://foxhound.international/arma-3-sleigh.html A magical flying Christmas Sleigh for all deployments into and out of the North Pole. Sling loading and fire-from-vehicle enabled. Merry Christmas to all, and a happy New "Tanoa" Year!

To sum it up, you want your SMDI maps to use the full range of each channel. The channels should be used to modulate the values (specular and specular power) that are in the RVMAT, not to try to "turn them down" everywhere. Also, have you tried adding small amounts of noise to the normal map? I see DXT1/DXT5/related artefacts in game all the time (even in satmaps), but I think I'm a bit special that way.

Unlike call and execVM, spawn doesn't have a unary (right hand side argument only) version. You need to pass something (usually an empty array, which can later be extended to include arguments). Also you don't need to put code blocks into arrays. The execution of code in blocks is always delayed until some command (like call, spawn, waitUntil, etc) executes it.

DXT1 is used on SMDI which gives you 4 colours, which are equidistant linear mixes of the two colours you mentioned. DXT1 picks those two "endpoint" colours and then the extra two colours are 1/3rd and 2/3rds between them. One issue might be is that the two "endpoint" colours are only encoded with 6 bits (for specular) and 5 bits (for specular power). If your maps have a low dynamic range (for example, a channel only uses values 0-20 instead of 0-255) you could try scaling the channels up and then reducing the specular or specular power in the RVMAT. The specular power (B channel) in an SMDI file simply multiplies the specular power and the specular (G channel) (almost) simply multiplies the specular value. Also, TexView2 can show you the compression error while you are trying to tune things. You change the pulldowns that are under the menu to (for example): RGBA RGB Difference DXT1 ARGB8888

I've done a fair bit of digging into the oddities of nil and have written them up in an article: The Dark Side of nil Seems like a pretty unexciting topic but I've found knowing the details very helpful in troubleshooting SQF problems! The lack of distinction between a private variable containing a nil and an undefined private variable also crops up in code (even BIS functions) at times: http://feedback.arma3.com/view.php?id=20643"BIS_fnc_getFromPairs is unable to return nil when key cannot be found" http://feedback.arma3.com/view.php?id=15259"BIS_fnc_areEqual returns true if both param's are nil" (And many more!)

Private variables in SQF can be pretty confusing, especially with misleading statements like this in the Biki: "Local variables are only visible in a specific script. The whole code in this script has access to the variable, that includes also functions called within the script." Once you try adding an event handler that has references to private variables, as one example, you'll discover it isn't quite as the above suggests. I'm hoping with this article that a mental model–that matches more closely how the SQF engine actually works with private variables–will help people out: The Article

Hi whiztler, I've done a small update to correct some typo's and also made the gray text slightly darker. How is it now? Too little a change?

If you use spawn, none of your private variables are available to the spawned function. The two sets of scopes (the spawning and spawned) are unrelated. Anything you need to pass in privately needs to be passed in as an argument: [_a, _bunch, _of, _privates] spawn { params ["_a", "_bunch", "_of", "_privates"]; ... } Also, if you fail to use "private" in any "call"ed functions, they will overwrite privates.

I often find myself going back to the same biki pages on SQF to check basic syntax or look for commands for the basic types (especially after coming back to SQF scripting after a break). To save a bit of time I've done up a cheat sheet for all of the core language elements in SQF: ARMA 3 SQF Cheat Sheet It also includes a copy of the operator precedence table I've previously posted. I'm keen to get any feedback, especially any suggestions or corrections. The sheet doesn't include game related commands (since there are over a thousand if my memory serves me correctly) but I'm also considering doing a second page with some of the most frequently used game related operators.

Worse still is links from places like Armaholic to mod discussions are all broken now too.

Yeap, you can replace: class ThrowMuzzle: GrenadeLauncher { ... } With just: class ThrowMuzzle; You want to avoid including any settings from the A3 configs (e.g. "aidispersioncoefx = 6") because like I said before if they change your addon will take them back to the old values and might cause issues. Also it looks like you removed your own muzzle from "class Throw": class MGI_LacrymoMuzzle : ThrowMuzzle { magazines[] = {"MGI_Lacrymo_mag"}; }; If you add that back you should fix the error you're getting. You can remove: class HandGrenadeMuzzle ... Too, as it is part of A3 as well.