User Details
- User Since
- Mar 7 2013, 2:13 AM (599 w, 3 d)
Thu, Aug 15
Tue, Aug 13
The repro is identical, just change the vehicle and class in init.sqf. If you still want another ticket, I'll do it.
Sat, Aug 10
I think checking if input backpack was nil as a flag to keep old backpack would be the best solution here. Best backwards compatibility-wise.
Aug 1 2024
Jul 8 2024
Jul 3 2024
Jun 4 2024
Another related issue is that backpack UGV which uses similar model and same texture re-textures differently, would love both vehicle and backpack to be made re-texturable together.
May 23 2024
May 19 2024
May 15 2024
Haven't tested it yet, does it trigger for countermeasures on vehicles?
May 14 2024
Will this trigger on mode and muzzle change too? Perhaps all 3 can be included somehow.
May 12 2024
If this ticket has a chance to be implemented, let me know and I'll make scripts to quickly test it.
Found through comparison with alpha where it works, you need to have hit > 10 for it to work.
class CfgAmmo { class Grenade; class GrenadeHand:Grenade { hit = 10.00001; }; };
Really weird choice but seeing that alpha uses same grenade config as OA probably means this engine part wasn't touched for years.
May 11 2024
Bug found in inAreaArrayIndexes, it ignores c for height:
private _area = [positionCameraToWorld [0,0,0], 20, 20, 0, true, 20]; [ [player] inAreaArrayIndexes _area ,[player] inAreaArray _area ]
> [[],[B Alpha 1-2:1 (Sa-Matra)]]
May 8 2024
May 7 2024
May 4 2024
May 3 2024
May 2 2024
Apr 30 2024
Sure, but they already do that with proper cheats bypassing SQF and creating own shot messages. Is it really *that* much worse than creating shots with createVehicle and createVehicleLocal? You can already do a lot of mess with {createVehicleLocal ["HelicopterExploBig", getPos player, [], 0, ""]} forEach allPlayers and its not even logged in createvehicle.log. (Censor this if needed)
Apr 27 2024
Apr 25 2024
Since source for roadkill damage changed from being a driver to an actual vehicle, damage from physx objects is still unit itself.
v = createVehicle ["Land_ToiletBox_F", player modelToWorld [0,10,0]]; pos = getPos v; onEachFrame {v setPos pos; v setVelocity [0,100,0]}; u = group player createUnit [typeOf player, v, [], 0, "CAN_COLLIDE"];
Here is a repro script to kill a unit with PhysX object.
v = createVehicle ["C_Hatchback_01_F", player modelToWorld [0,10,0]]; pos = getPos v; onEachFrame {v setPos pos; v setVelocity [0,100,0]}; u = group player createUnit [typeOf player, v, [], 0, "CAN_COLLIDE"];
Same repro with a vehicle instead of object properly attributes the vehicle as damage source
They aren't visible in Eden, but these wrong icons are explicitly defined in the config. Maybe just remove these definitions so there are no pictures for them at all.
I wonder if we can just get general engine-driven calculation for predicted projectile hit position? This way you could run it in Fired to find out where AI was firing. This will differ a bit from where AI *wanted* to fire though.
Apr 24 2024
Nice. I guess its fine with closing the ticket until there somebody has a really big need for single-return syntax.
Command return is very different in nature - model name string, skeleton boolean, placing point vector, mass number. Pretty sure in 99.9% cases you'll only ever use a single value (like I do in all my usages), thus the suggestion to have it return only wanted value. I don't REALLY need it but it would be nice to have.
Apr 6 2024
Or maybe call it setCustomEntityInfo by analogy with getEntityInfo, getModelInfo commands
I'd like to also ask for custom picture.
Apr 5 2024
I'm pretty sure that remote units camera state is broadcasted because it changes for you automatically when you watch remote players with _remotePlayer switchCamera "INTERNAL" it follows whatever camera view that player is having on their client.
Apr 3 2024
Mar 22 2024
Repro
Mar 21 2024
Not sure if this can be considered resolved, it doesn't solve the issue where it matters the most.
Version with RHS tank, still broken.
Mar 19 2024
Mar 10 2024
Feb 21 2024
Okay, here is the repro:
Feb 11 2024
Feb 9 2024
ENTITY Explosion is called alongside ENTITY HitPart has projectile entity and source in it, might as well have instigator there.
Repro hint output:
Feb 8 2024
Repro RPT example:
Server:
22:20:45 ############################################################# 22:20:45 # ProjectileCreated: 10: rocket_rpg7.p3d (R_PG7_F) 22:20:45 local = true 22:20:45 source = B Alpha 1-1:1 (Sa-Matra) (B_RangeMaster_F) 22:20:45 instig = B Alpha 1-1:1 (Sa-Matra) (B_RangeMaster_F)
Client:
22:20:45 ############################################################# 22:20:45 # ProjectileCreated: 10: rocket_rpg7.p3d (R_PG7_F) 22:20:45 local = false 22:20:45 source = B Alpha 1-1:1 (Sa-Matra) REMOTE (B_RangeMaster_F) 22:20:45 instig = <NULL-object> ()
Feb 7 2024
Is this related to lack of vehicle or instigator on the entity in lastEntityCausingDamage @ T178711? I think it would be correct for entities to store both last damage vehicle and instigator and then use it for proper Killed event handler arguments and these explosions parents.
Feb 3 2024
Feb 2 2024
Okay, after lots of testing, here is a patch that fixes all vanilla flare issues:
class CfgAmmo { class FlareCore; class FlareBase:FlareCore { intensity = 500000; }; class Flare_82mm_AMOS_White:FlareCore { intensity = 1000000; effectFlare = "FlareShell"; }; };
40mm flares inherit from FlareBase. From my tests 100k intensity (that RHS has) is nowhere close to OA or early A3 GL flare brightness, I tested 500k and it seems to be too bright it seems to be close to whatever original A3 had:
original A3:
500k intensity for 40mm flare (what I suggest to have):
250k intensity for 40mm flare (not enough, 100k is even less):
Here is what RHS does it:
class rhs_ammo_flare_m485: F_40mm_White { intensity = 100000;
and vanilla config only has intensity defined in 2 classes, checked with
"'intensity' in (configProperties [_x, 'true', false] apply {toLower configName _x})" configClasses (configFile >> "CfgAmmo") apply {[configName _x, getNumber(_x >> "intensity")]}
Jan 27 2024
Jan 26 2024
Jan 19 2024
Test script snippet to reproduce the issue with visible values
t = 0; st = 0; z = 0;
Jan 18 2024
Works great, can be closed as resolved
Jan 11 2024
Jan 4 2024
Here is a suggestion on how getVariableCall can be incorporated into existing command with backwards capability and also address original ticket idea:
getVariable ["var", {123}] // Return {123} code if "var" is not found getVariable ["var", {123}, false] // Call {123} if "var" is not found and just return it getVariable ["var", {123}, true] // Call {123} if "var" is not found, write into "var" and return it
Perhaps it can also work with non-code 2nd argument and true 3rd argument. You'll need code returning code if you'll want to default set the code though.
Dec 28 2023
Looks like its fixed @ T120107
Dec 22 2023
Dec 17 2023
There is isUAVConnected that checks it and it works in multiplayer, remote units get true when somebody is connected, isn't there a link from UAV to whoever is connected to it? Thought it is technically possible to have several players connected through a bug, then this command won't tell the full picture. Is there any other list in the game that could help with this, apart from iterating through every unit? Add an event handler that fires when somebody connects and disconnects their terminal so such list can be tracked by script perhaps?
Ticket can be closed as resolved.
Dec 13 2023
Tested, works great now!
Dec 12 2023
Dec 9 2023
Semi-related ticket: T177724
This also happens in RHS, when you fire HEDP grenade ammo rhsusf_40mm_HEDP (shotShell), it has submunitionAmmo = "rhs_ammo_40mmHEDP_penetrator"; (shotBullet) which is also duplicated. It does damage only on one client but effects are multiplied by number of clients (lots of craters and thick smoke deleting all smokes from the scene due to hitting cloudlets limit).
Dec 7 2023
Can make a repro with event handlers logging if needed.
Nov 30 2023
Better repro mission:
Nov 26 2023
I'd prefer this to be a fully local setting.
Nov 24 2023
Tested, both network sync and save-load work properly now.
Nov 21 2023
Confirmed, units with VisualSensor see targets through objects, including in repro, knowsAbout return 4 right away
Nov 19 2023
Nov 15 2023
Nov 12 2023
https://community.bistudio.com/wiki/remoteControlled
https://community.bistudio.com/wiki/isRemoteControlling
This was recently added too
I hope command doesn't broadcast and its just synced in generic update message. Personally I'd preferred if it wasn't synced at all, but I'm fine with either.
Nov 11 2023
Nov 10 2023
Seems to be related to my ticket again @ T172490 something isn't propagating scripted damage right over the network.
Nov 7 2023
[ diag_codePerformance [{player isNil "testnil"}] ,diag_codePerformance [{isNil{player getVariable "testnil"}}] ]
>
[[0.000365157,100000],[0.000616879,100000]]
Perfect, pretty much twice as fast!
Did some testing, works great!
Did some testing, works great. Doesn't sync as expected but also doesn't save in a save file, might be worth mentioning that on biki.
Nov 5 2023
Engine broadcasts result of HandleDamage at some point, not the event handler itself. The issue is that engine seems to ignore result of HandleDamage when storing damage values for map objects that will be sent to JIP clients, but correctly broadcasts them for existing clients. Logic:
- Building get damaged, should get 0.2 damage
- HandleDamage fires, adjusts damage to 0.1
- Engine broadcasts updated damage of 0.1 to existing clients
- Future JIP clients will still get original unmodified 0.2 damage
Might be related T172490