Jump to content

Recommended Posts

I think this works:

player action ["SwitchMagazine", player, player, 1];

edit. or selectweapon like h - said.

Hmmm could have sworn I tried both and neither worked. I'll have to take another look.

Share this post


Link to post
Share on other sites

Is the alternative syntax for ropeCreate somehow broken?

Because basing my code on the example ropeCreate [vehicle player, "fastrope0", 10, 10, true]; gives me error saying "Error Type Number, expected Array".. Or am I just doing something wrong :shrug:

No matter if I use rope type or a position, same thing happens..

EDIT:

Or is that only for ToH?

If so, the wiki isn't clear enough on this..

Would explain the error though..

Edited by h -

Share this post


Link to post
Share on other sites
Is the alternative syntax for ropeCreate somehow broken?

Because basing my code on the example ropeCreate [vehicle player, "fastrope0", 10, 10, true]; gives me error saying "Error Type Number, expected Array".. Or am I just doing something wrong :shrug:

No matter if I use rope type or a position, same thing happens..

EDIT:

Or is that only for ToH?

If so, the wiki isn't clear enough on this..

Would explain the error though..

I will add it to the documentation. The correct alternative syntax for Arma 3 is: ropeCreate [vehicle player, "fastrope0", 10];

Share this post


Link to post
Share on other sites

Thanks.

Realized that later, forgot to edit the post to reflect :)

Share this post


Link to post
Share on other sites

Don't know if this belongs in the Scripting Discussion thread or the more general Dev Branch one, but here goes.

Is there a particular reason why

(backpackContainer player) setObjectTexture [0, "#PATH"];

will work, and allow you to change the textures/materials of a unit's backpack on the fly, but

(vestContainer player) setObjectTexture [0, "#PATH"];

doesn't work?

As far as I can tell the backpackContainer and vestContainer commands return virtually the same information about their respective containers (with an ID and model name) and both containers appear to be functionally the same in almost every other respect other than they occupy different inventory slots: So I'm wondering why one is able to target an item worn by a player and apply setObjectTexture to it, and the other isn't?

Certainly in terms of modelling, animation and config there is very little difference between how a vest and a backpack are set up in themselves, or how they appear on the character model via proxy: So perhaps there something fundamentally different about the way vests are simulated in the engine compared to backpacks that means setObjectTexture wont work on them, and I'm mistaken in thinking it's to do with the xyzContainer commands

I'm aware that some BIS vests classes aren't set up for hiddenSelections even if the models are (so obviously setObjectTexture wouldn't work on those) but the command doesn't work on the vests classes that are set up for it either. In fact I've tried the above script on Teriyaki's addon which has a version of the BIS Rangemaster belt set up as a backpack and it works on the backpack-configured belt, but not the retextured vest-configured belt even though they're using the same model and hiddenSelections sets.

It'd be kind of useful if we could setObjectTexture/setObjectMaterial vests the same way as we can do with backpacks, since they seem so similar. Headgear, and maybe weapons too; but there aren't equivalent xyzContainer commands for those items, so I have no expectation of being able to target them to execute the setObjectTexture command like we can do with a backpack.

Share this post


Link to post
Share on other sites

Can anyone quickly remind me why boundingBox/boundingBoxReal require an object (somewhere in the world), instead of simply taking a class (string) and look that stuff up, without need to actually spawn it already?

:eek:

Share this post


Link to post
Share on other sites
Can anyone quickly remind me why boundingBox/boundingBoxReal require an object (somewhere in the world), instead of simply taking a class (string) and look that stuff up, without need to actually spawn it already?

:eek:

I'm going to go out on a limb here and assume it is because command expects the actual object as an argument?

Parameters:

obj: Object

Share this post


Link to post
Share on other sites

I think he's asking what limitations require it to be implemented that way.

I'd be curious too, I suspect it's due to the method used to find those details requiring the model to actually be present in the simulation.

Share this post


Link to post
Share on other sites

Presumably, the output for the command is worked out on the fly - it's not stored anywhere (in config, for example) so the game needs the object to actually be existing. It goes and measures the object and generates the output from that.

Share this post


Link to post
Share on other sites
Presumably, the output for the command is worked out on the fly - it's not stored anywhere (in config, for example) so the game needs the object to actually be existing. It goes and measures the object and generates the output from that.

Yeah, that's what I've figured. Still sounds stupid, given the bounding box of an object can be considered static (even with proxies; just assume they're all shown.).

...so I wondered, if proxies are at least taken into account, given this seems to be a dynamic command.

Compare (yellow = boundingBox, orange = boundingBoxReal):

Spot any difference?

Neither can I.

I.e. the commands do not care about proxies.

So where is the point in them being dynamic at all? It's all static. So make them available by a simple lookup... (I don't think the config would be the proper place for such a thing; but the model itself. Item.) :rolleyes:

And while already at it, I wondered if bounding boxes in A3 are still as shitty as they've been in A2 (again, yellow = boundingBox, orange = boundingBoxReal (LOL, real my ass)):

http://i.imgur.com/YcA9ZNL.png (194 kB)

:mad: :aa: :redmad:

...okay then, screw this. Bounding boxes aren't worth shit anyways. And I'm not going to manually measure a thousand objects all over again (as I did with stock A2 objects for rectangle packing and such stuff... lol).

:(

[EDIT] ticket time: http://feedback.arma3.com/view.php?id=24765 (0024765: Fix bounding boxes) :yay:

Edited by ruebe

Share this post


Link to post
Share on other sites
Don't know if this belongs in the Scripting Discussion thread or the more general Dev Branch one, but here goes.

Is there a particular reason why

(backpackContainer player) setObjectTexture [0, "#PATH"];

will work, and allow you to change the textures/materials of a unit's backpack on the fly, but

(vestContainer player) setObjectTexture [0, "#PATH"];

doesn't work?

i think it might be because vests are handled differently in the engine. like backpacks are more like actual vehicles. i think addbackpack works with vehicle classes too (gives you great "the thing" situations) but addvest might not.

i think vests are more like weapons or rather helmets. the lines might be blurry in terms of how they are made visible on the character using proxies but i always felt that backpacks have a special way they work. more independently from the character entity itself.

do you remember how they had to fix/workaround that to make weapons and helmets that use hiddenselectiontextures in the config show those textures also when you put them on the ground? not sure backpacks ever had that problem. could be wrong though. just going by what clues i remember.

Share this post


Link to post
Share on other sites

So where is the point in them being dynamic at all? It's all static.

Try the box on player standing and on player prone, then we can talk about static, mmk?

Share this post


Link to post
Share on other sites
Try the box on player standing and on player prone, then we can talk about static, mmk?

Ah, there's the reason (yet, I'm not buying it :p).

Fair enough. Let's have a look at it: http://imgur.com/a/qpHlx

  • boundingBox and boundingBoxReal are equivalent.
  • The bounding boxes for standing and kneeling/middle are equivalent (compare http://i.imgur.com/NbjKiVN.png to http://i.imgur.com/diGYLla.png). What the...?!
  • The bounding box for prone is misaligned (leg and weapon are outside the box, see http://i.imgur.com/HkmrspO.png). Note that boundingCenter is [0,0,0] in either case. EDIT: also note that the bounding boxes shown here are slightly wrong/skewed :o (see following posts).
  • And again: the bounding boxes are needlessly excessive.
  • ...and now I wonder about the bounding boxes of ragdolled units, bwahaha. ;)

Now given that all men have the same size (and even if not...), their bounding boxes are static too; there are simply two cases (at least three actually, not considering the gradual fine-tuning of unitPos) to consider. I.e. this could easily be implemented such that no object is required. If given the class (string) of a man, just return the bounding box for the default stance (=the stance a unit gets spawned in), which is standing/up. If given an object, then consider the different cases, given the unitPos (are maybe something better - and actually dynamic - for ragdolls and stuff). No problem.

The current implementation of bounding boxes simply sucks. And I'm rather sure I am not the only one that would be glad to see it implemented properly (easy access/querying and optimal/minimal bounding boxes; i.e. boundingBoxRealForReal).

Edited by ruebe

Share this post


Link to post
Share on other sites
The bounding box for prone is misaligned (leg and weapon are outside the box, see http://i.imgur.com/HkmrspO.png). Note that boundingCenter is [0,0,0] in either case.

Your box is wrong, too narrow. The leg never goes beyond. Weapon, yes, but no body part.

Share this post


Link to post
Share on other sites

Bounds are definitely not static, they are a box enclosing the min and max vertices of a model. Try a static hmg raised or a slammer, when turning the turret of both the box grows and shrinks to encompass the barrel.

These values do not belong in the config they are real time values likely calculated from the renderer or animation code.

However what i do agree is that certain vertex should not be included, boundingBoxReal should be only the Geometry of the model so you can use it to tell if there is room for the object to fit somewhere. Where as boundingBox would be handy leaving with memory points included so you could tell if you have enough room to place say a vehicle and still have room for people to get to the getIn points.

EDIT: If you want to be able to get the default size of an object without spawning one i think the best bet would be to allow the bounding commands to except a path to a model, which the model file is easily found in the objects config. This would return the default bounds as per the model facing north (default models grid orientation) and would be down to the user to rotate the points if they needed with something like BIS_fnc_rotateVector2D.

Edited by Larrow

Share this post


Link to post
Share on other sites
Your box is wrong, too narrow. The leg never goes beyond. Weapon, yes, but no body part.

:o

Ahh, indeed. Looks like I've fucked up the rotation/modelToWorld and skewed the box somehow.

Don't do this at home kids! Here's how to do it correctly: http://killzonekid.com/arma-3-bounding-box-utility/ :cool:

But either way, the bounding box is clearly not dynamically calculated. The engine simply switches between the two states: standing or prone. And it's rather fragile from what I can tell: you can easily get the standing bounding box while being prone(!) and spinning/rotating around a bit.

Bounds are definitely not static, they are a box enclosing the min and max vertices of a model. Try a static hmg raised or a slammer, when turning the turret of both the box grows and shrinks to encompass the barrel.

Is this just wishful thinking? Or did this break at some point? Because from what I can tell (just tried a bunch, see: http://imgur.com/a/zMVgS), the turrets do not have any impact on the bounding box, what so ever. :confused:

  • Turrets do not change the bounding box in any way: http://i.imgur.com/dRdj4BP.png (using Kid's Bbox utility, ;), modified to (re-)calculate the bounding box on each frame). Same with any other MBT I've tried.
  • I did try a static hmg, and it turns out that not even the horizontal rotation has any influence on the bounding box (compare http://i.imgur.com/idS7oAO.png to http://i.imgur.com/K8r5uui.png; same bbox, totally different rotation. Or give it a try by yourself.). No matter what you do, the bounding box remains completely static. Looks like only the main orientation/direction of a vehicle is respected; with static weapons this is a constant while deployed, so...

This would return the default bounds as per the model facing north (default models grid orientation)

Yes, that would be absolutely perfect! If we need a bounding box without having the object already spawned, then we're most likely interested in the "default" (or initial) bounding box we're faced with upon spawning the object.

i think the best bet would be to allow the bounding commands to except a path to a model

Really? Why not simply allow these commands to take the class (string) and do it's (default) job. That should be fairly easy to implement, and then for us all easy to use.

However what i do agree is that certain vertex should not be included, boundingBoxReal should be only the Geometry of the model so you can use it to tell if there is room for the object to fit somewhere.

^^

Share this post


Link to post
Share on other sites
Is this just wishful thinking? Or did this break at some point? Because from what I can tell (just tried a bunch, see: http://imgur.com/a/zMVgS), the turrets do not have any impact on the bounding box, what so ever.

Turrets do not change the bounding box in any way: http://i.imgur.com/dRdj4BP.png (using Kid's Bbox utility, , modified to (re-)calculate the bounding box on each frame). Same with any other MBT I've tried.

I did try a static hmg, and it turns out that not even the horizontal rotation has any influence on the bounding box (compare http://i.imgur.com/idS7oAO.png to http://i.imgur.com/K8r5uui.png; same bbox, totally different rotation. Or give it a try by yourself.). No matter what you do, the bounding box remains completely static. Looks like only the main orientation/direction of a vehicle is respected; with static weapons this is a constant while deployed, so...

I did test before my previous post just to make sure my memory was correct.

Sorry but there is something wrong with your code then Ruebe.

Slammer with gun facing forward.

Slammer with gun turned left

Notice a whole grid difference in the box dimensions

Static HMG facing forward

Static HMG gun turned left

Same again but only about a third of a grid difference

quick hash of KK's code to just encompass everything in the onDraw

vehicle player call {
   private ["_obj","_bb","_bbx","_bby","_bbz","_arr","_y","_z"];
   obj = _this;
   addMissionEventHandler ["Draw3D", {
    _bb = {
        _bbx = [_this select 0 select 0, _this select 1 select 0];
        _bby = [_this select 0 select 1, _this select 1 select 1];
        _bbz = [_this select 0 select 2, _this select 1 select 2];
        _arr = [];
        0 = {
            _y = _x;
            0 = {
                _z = _x;
                0 = {
                    0 = _arr pushBack (obj modelToWorld [_x,_y,_z]);
                } count _bbx;
            } count _bbz;
            reverse _bbz;
        } count _bby;
        _arr pushBack (_arr select 0);
        _arr pushBack (_arr select 1);
        _arr
    };
    bbox = boundingBox obj call _bb;
    bboxr = boundingBoxReal obj call _bb;

       for "_i" from 0 to 7 step 2 do {
           drawLine3D [
               bbox select _i,
               bbox select (_i + 2),
               [0,0,1,1]
           ];
           drawLine3D [
               bboxr select _i,
               bboxr select (_i + 2),
               [0,1,0,1]
           ];
           drawLine3D [
               bbox select (_i + 2),
               bbox select (_i + 3),
               [0,0,1,1]
           ];
           drawLine3D [
               bboxr select (_i + 2),
               bboxr select (_i + 3),
               [0,1,0,1]
           ];
           drawLine3D [
               bbox select (_i + 3),
               bbox select (_i + 1),
               [0,0,1,1]
           ];
           drawLine3D [
               bboxr select (_i + 3),
               bboxr select (_i + 1),
               [0,1,0,1]
           ];
       };


   }];
};

Really? Why not simply allow these commands to take the class (string) and do it's (default) job. That should be fairly easy to implement, and then for us all easy to use.

Sure why not, i was just thinking along the lines of the quickest possible implementation in code engine side. Its not really doing its default job, as in taking a class spawning it in the world then returning bounding area, you dont want it to spawn so all it need to know about is the model, read p3d calcualte and return bounds. Just seems pointless BI doing this look up for you, the ability to pass your own model has benifits rather than being stuck to only predefined classes. Edited by Larrow
spelng :/

Share this post


Link to post
Share on other sites
Captain Obvious here. What builds are you three running?

Latest dev. build.

But most likely I've just fucked up again :u:, (Kid and Larrow know what they're doing, :cool:).

Share this post


Link to post
Share on other sites

Am i correct to assume that when using params you don't need to private the local vars anymore?

Share this post


Link to post
Share on other sites
Am i correct to assume that when using params you don't need to private the local vars anymore?

Why would you think that?

Share this post


Link to post
Share on other sites
Am i correct to assume that when using params you don't need to private the local vars anymore?

Correct.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×