Sniperwolf572

It hasn't happened. It's mostly tweaks that are currently on the dev branch. Click the link papanowels post to read about it.

BIS_fnc_vectorRotate2D You can also do 3D vectors if you don't need to alter the third parameter. It would be really nice to have additional 2D/3D vector rotation commands in addition to the recently added vector manipulation ones. BIS_fnc_ambientAnim / BIS_fnc_ambientAnimCombat They're great utility and used widely, but they should both be encompassed in a single more generic function which in addition to the current mode of picking a collection with a stringstring, could take an array of anims to random through. Exit on combat should be a parameter. All anims should be allowed to exit on combat with a default animation if one wasn't preset. Author should be able to manually override the exit animation. Additionally, when using the combat variant, _gear param is verified twice needlessly. Once in the Combat, then it's passed to ambientAnim which also evaluates it. BIS_fnc_findInPairs / BIS_fnc_addToPairs / BIS_fnc_getFromPairs / BIS_fnc_setToPairs These should really be a set of commands. There is currently no good way to have key -> value type of arrays. Maybe a new data type. BIS_fnc_selectRandom Should be a command. _x = arrayRandom [1,2,3,4,5];

Yes, that's a positive thing, but that's not what I'm talking about. I'm not talking about action menu actions, I'm talking about "inputactions", the things you bind your controls to in the controls menu. What gets called when you trigger a weapon switch is just a piece of code, it has nothing to do with the default game switch, it's still in the game and I'm not doing anything to it. If you bind the key to the default switch and it will switch like it always does. To do this moving switch, you merely need to execute: [player, [<switch info>]] spawn TEN_fnc_wpnSwitch_performSwitch; And it basically plays a gesture, waits, changes your weapon, resets your animation, then plays a gesture again. Now you can make so that piece of code can be triggered by the user in a lot of different ways. But none of them come without a significant downside, and most addons merely make compromises. 1) You can add an action to the action menu for the user to activate 2) You can use a Key event handler to detect keys being pressed by the user and activate it 3) You can use a Mouse event handler to detect mouse buttons being pressed by the user and activate it 4) You can listen for an "inputaction" (Basically, all things listed in the default arma controls are an "inputaction", for example the "CarFoward" inputaction reacts to you pressing a key that's bound to it (it has nothing to do with action menu actions). When you're press it, it will be 1, when you are not, it will be 0, when you are using an Xbox controller and it's bound to the trigger that you can partly press, it will be in the range of 0 to 1 depending on how hard you're holding the button. What I'm saying is that there is currently no sensible way to provide both the mod user and the mod dev with a satisfactory solution that covers all bases and isn't obtrusive. For this mod: 1) You can use the keybinding system CBA built, which is great for the user so they can rebind as they please and all mods that use it are located in the same location. It's great for the mod author as the addition of one of those actions if really simple. The downside is that it can't deal with mouse interaction which is caused by the ticket I linked in my previous post, which to me is a requirement for this, many people have it bound currently to Mouse 4 and such. If I do this, we can wave mouse switching goodbye. 2) You can listen for one of the default "UserAction##" inputactions to be activated (like the addon currently does). It's good for the user because it uses the default interface for binding controls, it's bad for the user because they're horribly labeled and unintuitive. The major problem here is that if multiple mods are using this, they will conflict hard because there is only limited number of those actions and new ones can't be added. The more of those actions I use, the more chances are that I will conflict with others and that we will cause problems for eachother. Nobody "owns" them, you can't namespace them, they're just there but they aren't really useful in the Arma ecosystem. You don't want to switch weapons and see that you also attached a silencer/folded your stock/ejected from your seat/whatever. 3) You can listen to the default game actions (Like "SwitchWeapon", "SwitchPrimary", etc.), but you can't reliably override them and they also inherit the problems from number 2 in regards to author concerns. 4) The simplest way is to hardcode it, but then the users will be forced to use the keys that you decided on and there is no way for them to change that. You might also be conflicting with other addons or base game depending on the users keybinds and there would be no way to change that for the user. This is absolutely not an option. As you can see within the community, the compromises are various according to the above. If we take examples of the most common ones, ACE uses CBA, certain things are hardcoded, RHS uses an amalgamation of hardcoding and UseAction system combined through their menu, AGM used their own menu again limited in various ways, etc. Hence my proposal to let the authors tap into the default game inputaction system, for the benefit of users and authors, but I'm sure we'll see the next iteration of Arma before something like that happens in Arma 3.

This could've been done even in the initial version, but the major reason it wasn't is because I was afraid of tying multiple actions to the "Use Action ##" keys. Technically, this is on my imaginary planned to do list. But the only way to do it properly would be to use the CBA keybinding system, which would fuck over anyone who is using the mouse as their system does not support mouse buttons due to this and I'm sure BI doesn't even have something like this on their radar. I have no problem with this, and as I already said to multiple people suggesting this over PM's, they (or anyone else for that matter) are free to take the idea and run with it. Besides that, the code itself would be of no use to them and I'd probably rewrite it to be something less shit if I were to update this anyway. Either way, RL isn't being kind at the moment, my time for modding is non-existent, let alone lobbying and supporting a feature in another mod.

He's asking about the API you guys promised and told everyone not to use the things you listed because they are not for public and are bound to change (and as such are marked as not for public in the script header).

:wub:

Sweet, thanks for letting me know. I'll replace the link in the main post. :)

I doubt we're going to be playing Kerry again. But I'm not a big fan of his character, so that probably has something to do with the way my opinion sways. Tho I hope we'll get to see more of what happens with the device and get some background on Miller and unit.

I don't use MCC or Zeus for such things, so I can't say. I'm too used to just doing everything in the 2D editor. :P But I'd say to stick to what works for you if your focus is the stable branch, until there is either a tool to automate it or 3DEN and the stable branch become compatible.

What tool are you using to extract? (I'm assuming the native Windows archive manager) If that is the case, it could be because of the LZMA compression. Here's an alternative link. Let me know if you can extract that. Thanks for the mirror!

They haven't said it explicitly anywhere, they just said what you just said. They stated that exported 3DEN missions won't be compatible with stable branch until 3DEN is on stable branch, and that is common sense. What you make now, might or might not be compatible in the future versions of the game, because the state of the dev branch is such, that in theory, even in the next dev branch push a change can happen which wouldn't let you load the missions. That's the whole point of the dev branch. Volatile playground that we have access to, where they can "do stuff cuz it's cool boiz". :p

Version 1.1.0 available in the first post. Full rewrite because I can Hold keybind now customizable through the CBA keybinding interface Now respects door status (No more opening script-locked doors) Fixed: In some cases, doors would take a few seconds to be detected if the object was not "revealed" to the player right away

I personally subscribe to what JFK said: :P

Thanks for expanding further, I already had understanding of the technicalities of it. :) And yeah, I get that it takes some time, and that doing disproportional amount of work for a smaller detail like that is unrealistic, no doubt about it. :) Zubr was probably a bad example, as it was probably done fairly late in the process, it was the first thing that came to mind with visible projectiles. On the other hand, I'm pretty sure we can dig out numerous assets that have an unnecessary amount of sections, and let's not even talk about assets coming from mods, people nuking the FPS with inconsiderate scripts and the amount of draw calls you can generate by merely having more of unique stuff in the scene. Fretting over a single selection in the context of all that can seem insignificant, as you can take from my first post, but I understand your reasoning. Especially considering there are people who go wild over single FPS loss/gain. Apologies if I sounded harsh.

Why not be consistent with other BI weapons in the game? Considering Zubr has 6 individually modeled and animated bullets that makes this explanation seems contradictory. Besides, detailed grenade in the Pilot LOD, less detailed one in the other resolution LODs is not going to be the end of the world, is it?

If I understand correctly. Tank cannon ammo was changed from "ShotBullet" to "ShotShell" simulation type.

From what I can tell so far, the things that changed are a small metadata header that stores some editor state info, the .sqm version number has been bumped, the way the entities are stored are no longer in separated into multiple classes, but instead are all inside one Entities class and a lot of object properties are now stored in the attributes class of the entity which provide a decent chunk of functionality. Theoretically, it's possible to convert the new format to the old format (just like it's theoretically possible to write a mission.sqm by hand :p), but doing it manually for a large mission would be impractical due to those last two changes. For the small things, you might as well do it in the old 2D editor and save yourself the hassle.

I'm not sure if you're aware, but you can already do that even in 2D editor by hitting escape when the mission starts and clicking on the "CAMERA" button.

While I agree with your sentiment and the suggestion of armor degradation in your previous post, this is simply not true. You can process the damage yourself, and I wouldn't call the HandleDamage Event Handler a hack.

This is great when you need something exactly like this, but I wouldn't call this fully resolved. Having to paste the copied value somewhere just to quickly glance at the classname of something is slightly tedious. It's also tedious when you just need a classname but the that option exports at minimum 2 lines of text to clipboard with formatting. :( The old way was very minimalistic and functional. It didn't require you to delete cruft or extract from a list just for the small thing you need before you can use a classname. Additionally, is there any chance that we can get a setting in the menu that would enable us to toggle classnames in tooltips and lists? So that when you turn it on, those lines of text show "Engineer [b_engineer_F]" / "Engineer (varname) [b_engineer_F]" instead of just "Engineer" / "Engineer (varname)"?

Directly, no. The .sqm file structure is slightly different. You might be able to gut the .sqm and make it compatible.

This sounds nice. :) Are there plans to extend to more than the hit points you listed? From what I can tell, only the face has any sense of "direction" (front of the head). There is no difference between left or right arms, the front and the back of the chest, sides of the head vs top and back etc. For example, some cases of asymmetrical protection, some common, some not: Vests that only cover front but not the back. Vests that have full cover for the front/back torso, but not to the sides. Vests that might cover one arm, but not the other. Vests that have shoulderpads, but no cover on the rest of the arm. (This might already be in as arms vs hands) Vests that cover upper legs, but not below the knee. Helmets that only cover the top and the back of the head, but not sides of the head. Helmets that cover only one side of the head. I'm asking this because while the increase in "resolution" of the hit areas are nice, a user seeing a vest that visually has no side and back protection, and then aiming for those areas and expecting critical damage, isn't going to exactly have trust or understanding that if the front of the chest is protected, it's actually protected from all sides. It doesn't exactly place confidence in visual acquisition of those "lethal zones" and in the well placed shots to them but rather understanding of how the various vests are configured, no matter how they actually appear.

It's an still an .sqm but the structure of it is different.

You can't from what I could tell. Rotation axis stuff on the toolbar is labeled as "Not yet implemented". I believe they also mentioned it on stream as one of the missing things to be implemented next.

It's in the menus under Scenario > Export > Export to Terrain Builder.