Sniperwolf572

It's going to be Tselinoyarsk obviously!

http://www.reddit.com/r/arma/comments/38ilhv/arma_3s_new_terrain_reveal_countdown_e3_pc_gaming/crvhbdg

Yep, that describes it better than what I linked. :D

There are two lists, CfgRemoteExecCommands and CfgRemoteExecFunctions.

The core problem is that animation blending/interpolation isn't a first class citizen in Arma engine and the logic in Arma is inverted in regards to what animations do. As with many things Arma in the past, it was made to address very specific concern (Reloading) when it was implemented, and from there it was barely expanded. Blending currently is used mostly for minor cosmetics instead of complementing the really bad points due to those limitations. In Arma, when you press W to go forward, you're initiating the animation and the animation configuration is what (mostly) determines the parameters like your speed, etc. In most other modern engines, this is the other way around. The game logic gives the animation system all the parameters, like "ok, this guy is moving forward at this speed, in this stance, etc." and the animation system chooses the appropriate animation to play on top of the movement of the character. Many things in Arma feel "clunky" because you're limited to a single animation in such cases. You can't blend multiple animations with ease. And the animators need to put in a herculean effort to add or change minor things because changing the parameters requires change at more than one place/level. When people mention BF4, they aren't talking about how something "looks", they're talking about how things work in the background, and the Arma system isn't that way because BI desires it to be that way, but because the animation system was made in the "ye olden days" when things like "animation blend trees" were non existent and everyone did it that way. It is currently like that in Arma because no effort was put in to change it. It's one of those changes that requires a lot of work to accomplish and would pay off in the long run, but nobody is willing to say "Yes, this is the game iteration where we'll change this". I'm quite confident to say BI animators much rather work with the second type of animation system than the current one. ---------- Post added at 15:32 ---------- Previous post was at 15:27 ---------- Yes, but not without problem. For example, you'll see the character body rapidly "jerk" because of the transition from "I'm in this set of animations where I'm wielding a rifle" to "Set of animations where I'm wielding a pistol". The hands themselves move without problem because they're blended in two phases and are literally the same animations from the base game, but are the "blended versions" forcibly triggered with scripting on top of whatever animations you are doing at the time. It can be illustrated as a timeline. Regular arma switch: [Hit key] ---- Run with rifle forward ---- > ----- Begin putting away rifle ---- > ---- Start taking the pistol ---- > ---- Run with pistol forward ---- > ------ Hand gesture to grip the rifle in the correct place ----------- > -------- Hand gesture to grip the pistol in the correct place ------- > My scripted switch: [Hit key] ----------------- Run with rifle forward ------------------------------ > ------------------- Run with pistol forward ------------------------ > | ---- Begin putting away rifle ---------- > ---- Begin taking the pistol ---- | ------ Hand gesture to grip the rifle in the correct place -------------> ------ Hand gesture to grip the pistol in the correct place -------- >

TB expands on my views, as to why this is an overall benefit to Valve, that I mentioned in the first two paragraphs of the previous post.

I'm looking forward to this. EU and EW are amazing to the point where they used to consume my days. I find such games very rare these days. Hopefully they'll keep the good track record.

I don't think EU laws had much to do with it. A standardized pipeline for refunds with defined rules probably benefits Valve more than not having it. As Steam has become much less curated and everyone and their dog jumping on the early access, many more titles have become riskier buys. It helps slightly with that issue by allowing customers being able to backtrack on their potentially impulse decision. It's much easier to impulse buy something when you have a "I can return it" in the back of your mind, and even such purchases are probably not going to be refunded anyway. You now have a grace period to reconsider in cases where it's obvious that what you thought you were paying for isn't what you actually got. Origin and their refund policy for their own games also probably had some minor impact. Competition is good. :) Another thing to mention which might not be obvious right off the bat, is that preorders are also refundable this way (but if I remember correctly, they were before too). Even if you preordered ages ago, you still get 2 days / 2 hours with the game when it's released to back away.

While it's uplifting news that he'll be gone, cutting off one head of the hydra doesn't do much. After all, new president will be elected by the same people, with the same motivations, who elected him a few days ago. Unless things drastically change within the organisation by the time the next elections come about.

Valve has changed the Steam refund policy. Baseline rule for refunds is With some exceptions for specific cases, full read here.

That's like saying that 99% of people worldwide have health problems because you polled people waiting to see a doctor at a hospital.

Yes, at least one lucky guy who won a Steam giveaway.

I'm just advocating that common libraries are there for everyones benefit, the word used is irrelevant. Pretending they don't exist, aren't run alongside your mod 99% of the time and proceeding to reinvent the wheel, in my eyes isn't exactly best practice. But your reasoning is your own and as I said, I understand it, you don't need to explain or justify it. There's no need to whip out your dick and shove it in my face, I'm already amongst those 200k who silently appreciates it on a daily basis.

Yes, I agree with you. My point is when everyone splits off and decides to make their own standards, nothing is actually standard. Nobody would benefit from having multiple "standards" like multiple CBA's, Joint Rails, Joint Mags, etc. And that's my biggest gripe, isolating yourself from the community which is small enough and everyone is approachable and pliable to agree on certain things, which CBA does well. But I'll stop here, this is more suited to some kind of an ideals thread or something. :p

Considering how many things in RHS fall outside the common sense compatibility/standards, I don't find it surprising. All in the name of "standalone" which, let's be honest, doesn't exist in this community and in reality never did from the moment we rode pink ponies in WWII settings on our Wanzers. Your content will be used with other content. Considerations and compromise for that have to be made for an enjoyable experience. I'm sure if MANW was not a thing, common sense in regards to such things would be much more readily available. While I understand and respect their reasoning, I liked RHS more when it was a focused content mod (because the content is awesome) rather than a forced standalone mod which in reality is almost never used standalone. :)

SteelSeries Siberia v2

I have a test mission with nothing but a truck named truck, and 3 units in a group named u1,u2,u3. I launch this on my dedi and I connect as a client. I've enabled the debug console for the MP and I execute the following via server exec. (I do this because I have a much more complicated system which actually executes the same code on the server, but I've isolated it for this test case) { [[_x, truck], "moveInCargo", true] call BIS_fnc_MP; } forEach [u1,u2,u3]; I execute it on every machine, purely to make sure it will also execute on the machine where _x is local. Replacing "true" with "_x" to execute it only where _x is local yields the same results. Case 1 - Player is u1, the group leader, AI is u2 and u3: Everything goes as expected, all three units are moved into the cargo space of the truck Case 2 - Player is either u2 or u3, AI is the other two. On first execution of this, both AI are moved into the cargo space. Player does not get affected. On the second execution of the same script, player is also moved into the cargo space. Time between the mission start and the first execution is irrelevant. Player never seems to move into the cargo on the first attempt unless he is the leader of the group. Executing this without BIS_fnc_MP, everywhere and by manually checking locality yields the similar results. What am I missing here? I've seen similar threads where nothing happens on the first execute, and I've seen solutions mostly revolve around spamming the command until the unit is actually in the vehicle. Surely this brute force way can't be the only solution to this.

You might be having the same issue as I once did.

I want an hour of my life back ... :cryy:

Technically that single "asdg_mags_stanag" string, is the major benefit of magazineGroups. It eliminates the need for the middleman addon and it does not introduce hard dependencies that need to be resolved with compatibility pbo's. With it, "Joint Magazines" addon could be a fully optional enhancement by mere presence, just like feature mods can selectively improve experience by reading vanilla-inert config properties that the addon maker can choose to use. The option to have a hard dependency is still there, as authors might choose to use such an addon as the only source for the mags, without bothering to define their own at all. Either way, I believe the hard part in such a project would be coming up with and agreeing on values and variants.

There are ironsights. Scroll up/down when aiming.

https://community.bistudio.com/wiki/setAccTime

Not fired, just expended. With that setup, one click would fire one bullet, and the bullet count in the magazine would go down by 3. The single bullet that was fired still behaves like a single bullet. Burst property controls the amount of bullets that the weapon fires on a single click, so burst = 2 would fire 2 bullets, 3 would fire 3, etc. They still fire on separate frames, not at the same time, and the delay between each bullet is affected by reloadTime of the fire mode. Multiplier just controls the bullet count reduction for each bullets. So burst 2 multiplier 2 would fire 2 bullets and the ammo count would be reduced by 4. What BI used to do and what created lag and other issues, was add submunition to each bullet, which would create more bullets before the impact (think cluster bomb). Since submunition creates global projectiles, they ended up being transmitted over the network and caused lag.

Some people already have problems using the new interaction menu on models with 2 arms, 2 legs and 1 head. :p

Not sure how Rockstar translates to Steam. :p