First, what you are describing is not what this ticket was about.

Resolved according to the author.

Duplicate, closing on authors request.

It is implemented to prevent you getting addicted to the editor and spending too much time with it. ;-)

14 years too late for that. ;D

Oh, I think I noticed what you mean. Can you confirm we're talking about the same thing?

For example, when you attach the first waypoint to the unit in the 2D editor, the unit respects the speed mode from the instant the mission starts. The unit never starts runnin.

While doing the same in 3DEN, it takes a few seconds for it to take effect and the unit is running for a second or two.

Not sure if you missed this, but 3DEN has the concept of a "group entity" that 2D editor didn't have (it only had group links, but you couldn't edit the groups properties). Which means you can edit the group itself, and even set things like the groups callsign via Attributes without ever writing a line of code.

Editing the groups properties (double click the group icon in the viewport / right click the group on left hand menu then go attributes) allows you to do set their initial behavior, formation, speed mode, etc. without any waypoints. Attaching the waypoint to the group is kinda redundant in the 3D editor for these things, no?

Screenshot: http://i.imgur.com/z0uXIWv.png

I understand old habits are hard to get rid of. :)

Duplicate of http://feedback.arma3.com/view.php?id=25750 which will be resolved in a future build.

Duplicate of http://feedback.arma3.com/view.php?id=25750 which will be resolved in a future build.

This has been an issue for a long while. I reported the same thing 2 years ago (http://feedback.arma3.com/view.php?id=10766) and DH had a ticket even from Arma 2 days about this issue (You'll find it in that ticket).

Since this has been assigned, I'll close my issue and assign it as the duplicate of this one. Hopefully it'll get sorted out soon.

Why I think it's probably not intended.

This destroys the item completely from the game world, it no longer exists, it's not on the ground to be picked up again, it's basically gone forever.

The magazine was taken out of the player inventory which is not players inventory and because the reload was aborted, there was never the moment when the magazines would exchange places or returned to the inventory.

As if something like this is happening:

Begin reload -> Remove magazine from inventory -> Wait until magazineReloadTime is complete -> Put magazine in weapon -> If the magazine that was taken out of the weapon still has ammo, put it back in the inventory

The problem there of course being that if the reload was aborted, the fresh magazine would be lost from the game world.

This seems to have been fixed in todays build.

The reloading no longer gets broken, but you still lose a magazine (the one that was supposed to be the new weapon mag) if you play a gesture during a reload.

I do not know if this is the intended behavior.

LCTRL is the only modifier which can be used in combination with the mouse buttons in the key mapping menu.

I'm going to take a wild guess and say that you have something bound to LCTRL+RMB?

In this case, LCTRL + RMB combo executes and takes precendence over RMB by itself, and that's where the conflict comes into play, which kinda makes sense.

I am unable to reproduce this.

I have my "Walk or run temporary" bound to Left Shift and my sights on the RMB. (https://www.youtube.com/watch?v=qjF6M0Fd0i0)

Any mods that could be intercepting the keybinds or maybe it's just a specific key combination which you are using that is making this happen?

Confirmed.

Confirmed, but note that this only works when there are other units in either the pilot seat or bench FFV seats.

Empty helicopter or units only being in the cargo area that doesn't have FFV will prevent this bug from happening.

Added in 131477

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2964656&viewfull=1#post2964656

Wasteland is an unofficial community mission and this is something the maker of that mission has to fix.

Resolved according to the author.

I take it this can be closed as no change required then. :)

Good call on the exiting the vehicles, It's a great situation to illustrate the severity/annoyance of the problem. I've added another simple repro mission that demonstrates it.

Resolved according to the author.

Resolved according to the author.

Resolved according to the author.

Resolved according to the author.

Resolved according to the author.

Fixed in build 128997

Cycling waypoints already exist as described by SilentSpike.

Would be nice to be able to create spotlight type lights through scripting.
Creating believable lighting can't be achieved in many circumstances with just point lights.

Many are relying on solutions like creating and hiding objects which contain these lights to achieve believable effects.

Confirming as fixed in 123771

Also to mention, with 1.19.123679, I don't even have to Alt+Tab out of the game anymore. Pausing the game will crash the game.

Ok, figured it out, there is another step. It has something to do with "currentZeroing player" in the watch fields

I had the following in the watch fields:

• cursorTarget
• currentZeroing player
• "abcde"

Removing the "currentZeroing player" fixed the crash, putting it back, crashed the game again on pause, it crashes even when editing the watch field to type it in.

Executing it from the pause console while flying in the plane crashes the game as well, so it's not just the watch fields.

Current dev build: 1.19.123679 - Crashes with the repro steps (alttab_flying_paused_crash2.zip)

Current stable build: 1.16.123633 - Crashes with the repro steps (alttab_flying_paused_crash3.zip)

• The Steam overlay is running
• GPU drivers are NVIDIA GeForce drivers 337.50

Confirmed, but it doesn't seem to be either the sun or the moon.

http://i.imgur.com/i6sbIuE.jpg
http://i.imgur.com/9EWbsHN.jpg

If you read my last sentence, what i said its that i don't see that as "optional", its a really important part, as important as been able to add new inputactions.

Ah yes, my bad. I agree, it is important. Amended the "optional" sentence to better fit what I actually meant. :)

That's what I meant in the last bit, "An optional addition would be to add an event handler which could listen for a change in an input action."

I currently do this like so, but it's potentially performance intensive if abused:

while {true} do {

Listen for the input actions. Done this way so the switch is responsive, allows for any keybind that
can be mapped and avoids custom code for detecting the mouse keys and key combos in the keydown event handlers
waitUntil {

		_isAction = inputaction "User17";
		(_isAction > 0);

};

// Do stuff here

// Throttle if holding
sleep 0.3;
};

As you say, this can be done better with a dedicated handler that listens to input actions instead of keys. You can also use addAction combined with the shortcut parameter for a poor mans inputAction event handler, but it's not usable in all cases.

That could certainly work!

The potential solution to the second issue, relative costs when the bar is empty to the point where you cannot place even a single unit, could be that 2 segments of the bar appear. The red part that colors your remaining resources as it is now and another one, to its right, colored differently that shows how large portion of the bar you need for the unit.

To illustrate:
http://i.imgur.com/MjGQ2ds.png

Just because they do not have an even more specific name, it does not mean they do not behave like other types. They're all resources. Money is still money and behaves like money when you spend it even if you don't call it Euro. They can be called Zeus' farts, they still behave like vespene gas. :)

The problem comes from the fact that you might have 0.9998 resources remaining, and a unit costs 0.3333. Let's say you've already placed a very expensive vehicle that needs 3 crew members and you want to man it with 3 generic rifleman.

When you look at the bar, it seems like you can place three units.
After placing 2 units down, you suddenly cannot place the third because you do not have enough resources, even if to the user, the portion of the bar is visually the same size as it was needed for the ones that you placed down already.

Additional problem comes when you are low on resources to the point where you cannot place anything but you still have some resources. Selecting a rifleman, the airplane or a flare, colors the bar red completely and you have no idea what the relative difference between the cost of the three is.

The problem becomes incredibly annoying when you are a Zeus with limited resources that do not regenerate over short amounts of time, but instead you don't get them back at all or you get them at the end of a round (ZvP Defend Kamino). And it intensifies even more, when deleting objects you placed does not give you the resources you spent on it back (ZvP Defend Kamino again).

To me, the obvious solution were numbers, even if in the data they are represented as floats, you can still move that decimal point and convert them to ints with multiplication. 0.015625 can be still represented as 15625 in the UI.

If you do not think numbers are a viable, simple solution to the problems in the ticket and this comment, I ask of you to come up with solution which removes the above mentioned frustrations while playing a resource limited Zeus because your ability to plan ahead is limited.

Yes, that would be ok too, as long as the intent of new and old functions is clear unlike the current case of the comments littered in dirTo and relativeDirTo.

It's a point of view thing.

My counterargument would be, how many authors are not aware that their scripts are broken because they expected a 0 to 359 output but never checked?

Also, for the purposes of scripts that use setDir, which accepts -90 or 270, it won't make a difference.

Additionally, I think it's a mistake to use it in a script if you are aware that it returns values that were not intended by the author.

If you weren't aware that it returns values other than the ones it says to expect, then it will fix things rather than break it. As is the case with relativeDirTo.

Confirmed. It certainly does not do what the author of that script expected it to do if we go by the comments for that function:

"Returns the compass direction from object/position 1 to
object/position 2. Return is always >=0 <360."

Line 25 of BIS_fnc_dirTo is:
_ret = _ret % 360; //ensure return is 0-360

Changing the line 25 of BIS_fnc_dirTo to:
_ret = _ret - (360 * (floor (_ret / 360))); //ensure return is 0-360

Would fix the problem and return a value in 0 to 359 range as the author of the script intended.

I'm assuming this did not reoccur in the last couple of months?

I'm unable to reproduce this with build 113567 on GTX660 (Drivers 331.65)

http://i.imgur.com/cKbcdgo.jpg
http://i.imgur.com/jxca8Le.jpg

Can you please provide more information like the video settings, graphics card, driver version, dxdiag.

If it happens again or you manage to reproduce it reliably, please post here again with the information requested.

I'll leave the ticket open for now.

Nice writeup and solutions. Closing.

Confirmed.

Another benefit would be that the community could create interiors for BI vehicles that currently do not have them by overriding the pilot LODs.

Resolved according to the author.

Still present. Updated the repro mission so that you don't have to manually turn the engine off.

The bit in what you think BI did is wrong.

Autorudder was present at all times, it's nothing to do with turn left/right and mouse controls as the same happened with the keyboard controls which are not TURN bound as Imperator_Pete says.

You could experience autorudder by yawing on one side and then observing the autorudder overcorrect you on the other side and in many other situations.

If the good change of removal of autorudder resulted in planes not turning when banking then it means the "plane turns when banking" wasn't reliant on any aerodynamic simulation but the happy accident and reliance on the autorudder to do it.

I could present the same "But instead solution" in reverse to you and tell you to add a YAW bind to the same control your BANK is on.

Since I'm not a pilot, and I'd assume turning when banking probably happens in real life due to aerodynamic properties of the airplane, this is a bug with the aerodynamic model itself and shouldn't be relied on autorudder on/off either way.

Yes, this is very annoying. Ran into the same thing a while ago but figured it was covered partially with #5878.

It also changes when you are unarmed.

No worries, glad we figured it out. :)

As for locking, locked vehicle isn't locked in a sense of "you have the key or not". It's a tool to prevent players or AI from entering or exiting vehicles, like if you wanted a player to use a certain vehicle for the duration of a mission and not allowing them to exit out of it or not allowing player/AI to use a certain vehicle you've placed, for example, decoration purposes or later use.

I'm unable to reproduce this with the repro steps given, can you provide more information?

Have you maybe accidentally locked the helicopter in the editor with the "Vehicle lock" option? This is the only way I can get the same results as you do.

I just wanted to let you know asap:)

Thanks, the built number you gave and yesterday's build number were just off by one digit, I thought it was a typo!

I can confirm that the ComboBox scrolling is better now and I consider it resolved for the purposes of this ticket. It scrolls 1 line per mousewheel "tick".

While it would be nice to sync it with the Windows "lines per scroll" as sms says, it is no longer frustrating as it used to be.

The update today was 113238 and it's still slow there, will report back when 113258 is released.

Speed is the exact same.

Can confirm, still no change, dropdown lists are still painfully slow to scroll.

This has been made better for the lists like the controls list (1 notch scrolls 2 lines), but the dropdown lists are still scrolling very slowly.

I'd agree with sms' suggestion to use the OS mouse preference if possible.

Yup, useful offset is returned. Marking as resolved.

In this case this command is needed even more because without it...

Yep, that's what my argument in the description of the ticket is about. :)

If you shift it anywhere at all (using trial and error and see what feels best with the attached load), you have no reference as to where the old one was if you need to revert it.

I don't think it is as [0,0,0] refers to the center of the model not the initial center of mass. Mass can be distributed in O2 across the model and shifted anywhere from the center.

Simple way to confirm this is to place yourself as BLUFOR > NATO > Cars > HEMTT then drive in circles and observe the behavior. Then set the center of mass to [0,0,0] and try it again, the center of mass then seems to shift to the center of model and the vehicle stops behaving in the same manner.

Either way, even if that was the case and [0,0,0] was always the default center of mass, if you need to relatively shift the mass in any direction, you can't guarantee that the other scripts/addons that you have no control over have not already moved it somewhere else.

What is different with Zubr, compared to other BI handguns is that the "rotational kick" provided by the model.cfg animations is significantly lower and I believe it's on purpose to illustrate the effect the barrel positioning has.

As for the recoil generated by the config, it feels similar to the other .45 handguns. If that is the case in reality, I do not know.

Confirmed, added some screenshots as well.

Easiest way to prove George_'s point is to enter the Splendid Camera and move around at 0.1 speed.

This has been fixed.