Awesome, just tried the dev version and it seems to be working fine.

Similar crash can be found by placing a radio trigger and hitting 0 to bring up the radio command menu.

Even if this is not reproducible in this test, this is how the code performs. Please look at the code and see if it is doing what is described.

This issue is still occuring with BLUFOR pilot models.

Also can we get a detailed idea of the fix, since it seems to be occurring on specific models and the same issue has been seen on RHS content.

I would like to help them fix it, but I am not sure where to start.

Yup, this seems to be working now. Thanks!

Yea people seem to still be experiencing this issue, especially with Arsenal. It seems like if you go into Arsenal in multiplayer with ACRE, switch through a few random sets of gear or change weapons or do anything that replicates the original scenario in this bug report it will trip the bug and the clients and server will begin to desync gear.

Any word on this bug being worked on? Highly frustrating.

Is this fixed? I can no longer replicate it as of the current dev version 128936...

This issue still appears to be present, or there is another issue that is causing gear desynchronization.

Fun!

Yes, when you corrupt the gear via the client, the server cant add items at all. If you do the repro above on the client, then execute something like this on the server: (playableUnits select 0) addItem "FirstAidKit" (assuming there is only one player in the test) you'll not see it on the server or the client.

Yea, it totally breaks the gear system on the server.

Can this please get a good look into? It is a game breaking bug, especially in ACRE which relies on clients and the server knowing about the same gear load outs

Sorry for the snarkiness of my ticket, but after finding that driverAction and driverInAction have no relevance to a unit being "turned out" in the internal state of the game (as in used by the sound system, see the ATV with its internalDampning factor of 0.9 and no driverInAction vs. driverAction) I got fed up trying to implement a reasonable solution to determining the in/out state of a vehicle position.

So I replicated the engine functionality in SQF (didn't know you could pull the animationPhase from engine defined animation sources). Can probably put this task down extra low right now since it seems to be working 100% now

Except that is generally considered bad practice, in that you assign a vehicle role, move the unit in, and then remove their role when they leave because the assigned vehicle role is not dependent on a specific vehicle type.

So in good, proper practice, yes, it is associated to where they are in the vehicle.

Yes, YOU can do it incorrectly, BUT further countering your argument you can assign a cargo index right now to a unit outside of the vehicle as well.

It is a moot point either way because like I said, adding it to that function might possibly break previous scripts that check the length of assigned vehicle role.

If someone is being lazy and checking length of assignedVehicleRole instead of the values to determine if it is a turret position or not.

That is actually incorrect.

assignedVehicleRole is used to determine turret locations for units that have been assigned (and then occupied if done correctly by a scripter or the unit moved in through the normal game interface). It is used to return vehicle positions in indeterminable slot roles already. It returning the cargo index for cargo assigned roles would be a somewhat natural extension of that functionality.

This could also be returned in assignedVehicleRole, though adding a new function would most likely be the best option due to the possibility of people checking the return length of assignedVehicleRole.

The only command that does work is allMissionObjects, but that seems overkill.

Vehicles command doesn't work for me with WeaponHolder.

Not sure why this was closed as a duplicate of the other issue. This is a different issue (and I was asked to make a ticket on any issues that result from the first ticket).

This is a bug. Numerical values are not displayed to the user correctly. This presents a fundamental problem in that what you see is not what you get, which leads to lots of issues. If you are having to do large integer math (like ACRE needs to do on frequencies in some cases) then it is helpful to know if you actually have an integer or not in your math, so you don't get unexpected results.

I am NOT asking for floating point precision to be increased but for the allowance of seeing what values we are actually working with in the engine (and it'd be nice if the scientific notation was dropped too, not sure what the benefit of that is).

Basically, the value stored internally should be shown when represented as a string. Truncation or rounding not performed by the user is disingenuous and can lead to problems.

Suggested fix is a function that converts the single point float values in the SQF engine into their string form with out any manipulation, or extending the functionality of an existing command like str (though there may be backwards compatibility issues where developers relied on this flawed behavior in their displays).

Also subtraction on large numbers is inaccurate: 33000011-33000000 = 12.

This bug also occurs in NON-SCHEDULED code when executed from the "action" parameter in dialog button controls!

I just removed all but one spawn in ACRE2 haha. Everything except about 10 lines of code runs in non-scheduled events now (was pretty much already there though before this bug, scheduler space is evil).

This actually occurs on JIP as well.

Client.

This is a really frustrating bug. I have had to add quite a lot of code to suppress errors that shouldn't be occurring because SQF is executing in some strange context.

http://www.youtube.com/watch?v=XFEnwnCcZ2s&feature=youtu.be

As requested elsewhere I have tried to add fuller documentation to the Biki but there seems to be some technical issues for me at least that are not allowing me to edit pages.

I will continue to try.

It would literally not impact the server at all. It is a simple model addition.

If the developers have any questions/concerns please let me know. I would love to get this in the sample models at least before tools are released publicly so the community has them from the get go!

The main benefit of this would be obviously for soldier models where everything but the resolution, shadow, and pilot LOD are the same. It would allow for easier standardization across models and faster editing of large numbers of models.

This is a hedge against my memory points in the other ticket not being added... :P

Though this would be nice for other things, like improving BIS models by the community, or overriding base models, etc.

I am confused why you would want any of these commands in simulation scope. I mean... maybe in some very edge case scenarios.

I guess the best of both worlds is good though.

So I think the simple solution for this is to compensate in modelToWorld and worldToModel for the interpolation. This is where precision is being lost it seems. The memory LOD seems to move correctly with the reso LOD, because doing manual coordinate space conversions seems to be smooth and correct, but those two commands lose precision because the origin is updating more slowly for the math that it is using (and that origin doesn't align with the origin used in the FIRE lod in this case, if that origin did align, then we'd not have any problems).

Possibly a visibleModelToWorld/visibleWorldToModel command would be an easy fix for this? Ultimately the best possible solution would be these commands, but taking a LOD argument so you get the specific conversion for that LOD (for example, the FIRE lod seems to be projected in front of the player for predictive impact calculations, and that origin doesn't seem to match whatever origin that modelToWorld uses, etc).

This is assuming of course that only position is projected forward or interpolated and not direction or up vectors, in that case, those need to be compensated for as well.

Actually I have a video now that shows how bad this problem is, and that it is a desynchronization between all the LODs (well at least the HIT and memory LOD) and the resolution LOD.

This is a MAJOR bug in my opinion.

Here you guys go: http://www.youtube.com/watch?v=oFDbyZyKxt4

Hopefully this is addressed soon!

So what I have derived from working this over in my head is that all LODs move independently of each other when animated and moving on character models. The FIRE LOD does not match the Memory LODs location, the FIRE LOD doesnt match the Reso LOD location, etc. They are all existing in world space at different locations each frame, totally desynchronized.

Here is a video demonstrating the problem: http://youtu.be/Qn0Iz9HoN28

Possibly. If this is true hit detection possibly is not where the model visually is.

Eitherway the impact location (where it is doing the intersection with the FIRE geometry) is wrong in comparison to where the visual geometry is. They should match.

Is this possibly a problem with interpolation of the impact data? Just something I thought about just now. Maybe the impact is being interpolated for the time it travels between frames and that interpolation data is off (a hit is registered but its not where the reso lod ever was because its where it was "between" the frames)?

Yes, I noticed some oddness last night with this while testing a couple things.

Something odd is happening with the Spine3 and Spine1 definitions, it seems like Spine2 needs to be there in some level on the FIRE LOD to make it cover everything. Also the left shoulder sometimes lacks hit detection, I think depending on the angle of the arm. Seems like the FIRE LOD gets some significant gaps in some animations.

Uh, I believe that was the point of my making this ticket Killzone... I feel like we are going in circles now.

Jaynus did it in Jaylib via patching, it sucked, was very complex, but I can't imagine it'd be harder to do it at the source level.

From how I understand they store the SQF functions there is essentially a list of function pointers for each command. If you just have two lists, one that can be manipulated via override, changing the pointers to the override function and is used by default, and another that can be referenced by callOriginal you'd be pretty close.

It is a pretty niche request but it'd provide a lot of power to advanced SQF users.

As in replace functionality or add code that is called before/after the internal function is called.

For example, I am working over in my head how to get rid of the action menu. A lot of that information is stored in configs, but since there is the addAction command to dynamically add items to the action menu it is a point where I'd have no control over the what is intended to be in an action menu (or its replacement). If I can override the addAction function I can seamlessly integrate a new action menu system into any previously existing content.

Other examples would be for debugging code, error checking risky calls, and any number of other things where intercepting the internal BIS call would be ideal.

Yes, that is just one example of what I was suggesting this could be used for.

There are numerous other things which it could be used for such as debugging, like overriding createVehicle to log to the RPT on every vehicle creation to see what/when an addon is creating things.

I have no idea what you are trying to say Killzone and I don't think you entirely parsed my last post. Please re-read it. I want to create an alternative to the BIS action menu.

Yea, I can get an addon and mission up in a bit.

Yea, looked like the bug report I had was mistaken from the reporter. Though there is still some other positional bugs related to head direction vs. body direction reported by other users. If they end up being a result of eyeDirection I'll make a new ticket.

Apparently there might be some bugs with eyeDirection though. ACRE2 is going through testing right now and some people said they were experiencing issues with sound location relative to their view. I changed the head vector output to use the camera commands and they are now claiming to get the correct positioning of audio.

That was the only change made in the two releases where the problem was identified and the problem was fixed.

This might explain some things with ACRE2 that people are experiencing. As far as I know this bug came up rather recently because I had tested this command for positioning sound sources before and it worked fine.

Yep, seems to be working, thanks DarkDruid! I think the documentation needs to be changed some now. It seems that inDirX is just a vector, in the documentation on the biki for it it says the speed vector. To get that you need to just multiply by inSpeed.

Also, I might make this a separate ticket but to make really nice explosions we really need a vector rotation function that can be used in these configs so particles can be imparted a velocity perpendicular to the direction of the projectile (which is where a majority of the energy goes in artillery shells, aircraft bombs, or any other warhead that is a cylinder in configuration).

Check out these following videos to see what I mean:

http://youtu.be/5FxhaCuGNm4
http://www.youtube.com/watch?v=v8eLH3VbJOQ <-- you can clearly see in this one that there is a smoke ring that forms perpendicular to the direction of the round, and there is a small column of smoke that travels in the velocity vector.

I don't think this is possible right now unless its on a fixed vector, which doesn't really cover many situations unless the round is coming straight down.

Internally the arrays are a custom type.

They _probably_ already have a method for doing this on them internally. _Probably_.

:)

Because I looked at the actual opcodes, its a wrapper to setDammage. It calls the normal allocation functions for both, but setDamage just is a wrapper that calls setDammage and then performs the return.

If it is indeed actually faster with more operations then something odd is going on in the SQF engine, or I am not seeing some sort of optimization they are doing.

Nope, its factual. I can confirm it. Trust me.

I am literally feeling seasick right now from having these idle animations going while working in the debug console for the last 2-3 hours. Spending any amount of time being "idle" is really frustrating.

Seriously? There is no way to get the bitmap from when the render of the dialogs occurs?

This is a serious drawback! There is an extreme amount of potential in allowing customized drawing to render surfaces! This is _literally_ the single most inhibiting factor in the RV engine right now. Allow this and you open up a multitude of possibilities for Arma and future IP.