Sniperwolf572

After 14 years wait for a 3D editor, I could only get so erect at the Eden Device's button.

I just want to let anyone who misses this that an update is incoming this week. This was potentially broken ever since BI updated some of the input actions that this addon depended on, and I had no time to update it any sooner. Version 1.1 will be a full rewrite of the system and will have CBA as a requirement (Keybinding interface). After 1.1 hits, there is another planned update that will introduce some quality-of-life features for further improvements in usability.

Seems fine to me. I rehosted the two images on Imgur for ya.

Nice. I wonder what the different sized, faction colored boxes around most entities are in the 2D view.

Unfortunately, it's actually a bug with the game. This is impossible to fix in a sane manner by anyone besides BI. It is impossible to get out of this state without resetting the animation via scripting. It's a problem with the way freefall and/or "edge drop" is programmed to activate, and not the model itself. This will always trigger when an object exits a vehicle on a surface that is higher than 100 meters ATL. The distance isn't checked as unit-landcontact-to-nearest-collider but as an ATL which does not take into account any surface besides the terrain level. This can trigger even with properly setup LOD's. A simple crack in the ground will result in a faceplant. There are extensive repro steps on this ticket, with the eager_triggering_vehicles.VR.zip being the relevant repro for the case presented in the video. The ticket has been filed for over a year now.

I'd like to offer a counter-argument (counter-question?). Is it a bug that the attachments slots for launchers show at all in the gear menu because no vanilla launchers can use attachments? :P Launchers absolutely can accept optics and other attachments. The fact that no default launchers exist that do make use of the feature, doesn't mean Arsenal should be "broken" for the users when used with community content. There is a reason that there is a whole row of attachment slots below the launcher slot in the gear menu, even tho not a single vanilla launcher exists that makes use of these slots. Arsenal should be the same. Besides, it's a clear bug that the "<Empty>" selector in the Arsenal doesn't actually clear the attachments, even tho you can change them by clicking on other ones.

Sadly they are. You don't do a thing like this and take 3 days migrating it and end up with this. If the migration was an emergency situation, I'd be understanding, but they had months to prepare. It feels like nobody did paid attention to what was being done. "We'll do it in production" is really not an excuse.

You're lucky. The web dev in me is going between states of laughing hysterically and raging in frustration, and it's not even Monday. I don't know who approved the design (Like, 220px of global and local navbar? REALLY?), the post-post ads, or the half-assed testing of the DB migration itself, but I suggest to keep that person very far away from the web responsibilities.

My examples were over the top on purpose to illustrate the freedom available, while using nodes from your post. More common examples would probably be in the lines of: "BLUFOR", "Desert", "Helicopter", "Tandem Rotor", "Transport" "OPFOR", "CSAT", "Urban", "Marksman" "AAF", "Truck", "Transport" "Civilian", "Beachwear" "Russia", "Tracked", "Anti-Air" In the examples you've given, there are authors who make a pool of objects that they want to pick from on purpose (If you think "Habitable Greek houses with white walls, red roofs, intact doors and windows" that better fits into a tree structure than a descriptor structure then I see no point in discussing this anymore), and authors who would have literally needed at most two supercommon tags like "BLUFOR" and "Sniper" to get what they want. Freeform, "creative" and "willy-nilly" of the tags is their actual purpose to allow the content maker to describe their content without being constrained by a rigid structure that someone else maintains, and 2 months in you get feature requests for "Habitable", "Greek", "White Walls", "Red roofs", "Intact doors", "Intact windows" leaf nodes to be inserted somewhere, which then takes a commitee of maintainers to agree on what node it sits. But in turn, tags system requires only community adoption and could be coded up in an evening by any one of us here. And besides, there's no way you'll eliminate every single case of custom pre built arrays where you actually want a certain specific subset of things that might span multiple different parameters.

Much more flexibility is gained with a tags system. If you really want tag grouping, you might as well tag the tags themselves or have them have an optional set of parent tags. If we take an example of an editor search dialog, it's a much simpler and more encompassing to describe rather than find. Select "Structures", "Source", you get back all structures that are a "provider". You might be looking to make a small hub of utility providers. Oh you need a water cistern, remove "Structures" add, "Vehicle". "Commercial", "Rifleman" gets you the PMC infantry. "Civilian", "Rifleman" are rifle armed civilians "Vehicle", "Fuel", "Sink" gets you SUV's, etc. "Animal", "TL" gets you a wolf pack leader The more specific your search need, the better you can describe it. And it works with procedural generation as well without having to check inheritance.

Yep. Hopefully 3D editor will have some improvements in that regard, "browsing" in the editor is horrible unless you know by heart where things are. But the major interest to me here with improvements to this is procedural generation.

I'll agree with X3KJ, tags are much more useful and flexible in general to be used for the sort of thing you're suggesting. The example you've given of availableForSupportTypes is an array of "tags" anyway. Besides, you can easily implement it via config as is. You can probably do so with both. But as usual, standardizing it is the problem.

... or they secretly cancelled the expansion and are actually making Half-Life 3.

Yes, anyone who has PiP active.

No. ASR_AI processes those files at each mission start via scripting commands. This change only affects file patching when you have the same folder structure in the core game as the $PBOPREFIX$ namespace of a pbo. Mods don't do customizing like that (at least I haven't yet seen any) and if any mod is relying on filepatching for customisation purposes, the authors should be given a stern talking to. For example, as it is currently, ASR_AI3 has the namespace of x\asr_ai3\addons\main so if you had that folder structure in your Arma 3 directory, and a file inside it called "fnc_canCover.sqf" it would overwrite the existing ASR_AI3 script, unless you had -noFilePatching. BI is changing it so that instead of having to disable it with -noFilePatching, you have to explicitly enable it with -filePatching. This shouldn't affect the general user and is really a good change as it's mostly a tool for addon authors. For the mod devs who use file patching, it will now be necessary to explicitly enable it via -filePatching. I'd actually argue that the dev branch should follow the same default of no filepatching by default as the stable, for consistency's sake. It's not like it's a critical thing to have active by default there to catch errors and launching the game with same params, if anything, it can provide false positives and whatnot. More information on how to work with unpacked data is on the BIKI already.

A command to get the 2D distance between two points in space?

Captain Obvious here. What builds are you three running?

This was proposed when this first became an issue in Arma 1, but the core problem was, you'd still see the person with the naked eye/lower zoom when the grass isn't there. A ghillie sniper at a distance in the grass would still look like a lone bush with a lower zoom factor. Yes, but only within the very close distance. On the other hand, their midrange textures look perfect. While the long range they are similar in quality to Arma. Up close: Arma Midrange: GTA Long range: Similar Tho it's easier to say GTA has better overall presentation of terrain because while yeah you can say up close is kinda bad, it's consistent and there are no situations like this that make you want to throw up (Screenshot by NordKindchen).

Is there a reason opportunistic XEH init is not an option? It doesn't incur a CBA dependency, but is still XEH compatible if CBA is installed.

It's even simpler than that. The forums are using the iframe method to embed vids, iframe just needs the "allowfullscreen" attribute.

I'd assume it's because it boils down a large chunk of data and behavior into a single nondescript number.

It would be nice to have some commands for getting and manipulating that knowledge. For example, it's very hard to make an AI "forget" a unit for custom purposes.

[_unit, true] call ACE_captives_fnc_setHandcuffed;

Does the PP effect from the initial optic you went into ADS with still stay when you toggle between them? Can't check right now. (Look down HAMR optic > Switch to HAMR red dot > HAMR optic PP (blur on edges) is still active > Leave ADS > Re-enter ADS > HAMR red dot PP active (none) > Switch to HAMR optic > HAMR optic has no PP)