RUBE draggables/droppables demo (object drag'n'drop)

[rübe 127]

Hi guys,

I'd like to get some feedback on my draggables/droppables/buildables (included in the latest version of my RUBE library), for which I've put some quick demo-missions together:

• RUBE drag'n'drop demo mission 3, incl. buildables (Combined Operations required, RUBE included as script version)
  
• RUBE hideout demo mission (Combined Operations required, RUBE included as script version)
  Mission description: Wait for 2 more guys, wait for another two guys with a truck and a pickup full with supplies (needed for modified COIN), flee from your hometown and start to build a camp.
  

Objects can be made draggable and of course you may simply release them wherever you want. But, you can also make objects (such as vehicles or tents) droppable, which means that you can put objects you're currently dragging into/onto them. To make this work, I use a rectangle packer and a big dictionary of manual object measurments (since boundingBox sucks monkey balls and can't be used for s***, :rolleyes:).

So we gain a "dynamic" packer which also the AI can use (so the problem of where to put things/where is some empty space is solved by this). And every "droppable" vehicle or tent has it's natural cargo limit set by its (cargo-)area.

All this also works with AI, which have some additional actions, which the player himself can't use. This is intended for the situation to let the player command his AI to load/unload a given droppable. This is important for droppables like closed trucks, which are quite impossible to unload otherwise (you get no mouse-focus on the objects to drag them away)... thus you order your AI to.

And you may also order AI to tranship cargo, which means they'll take cargo from droppable A and put it into another droppable (think of vehicle-to-vehicle or vehicle-to-tent situations). For this you need to first define a transhipment source (per radio 0-6-X) and then you may radio 0-6-X again and select a transshipment target, and your AI will tranship the goods... (of course, there are some problems here to solve, like what happens when the target droppable is full and so on, but it already works quite nice)

Some quick explanations:

• Note that you're supposed to drag objects "backwards". Going forwards or simply too fast will lead to a random interruption of your movement (forced stop-kneel and the objects gets reattached in a slightly other position to mark your failure (stumble/dropping the object by accident or something), hehe). Unfortunately it isn't that easy to make AI drag that stuff backwards...
  
• if you drop onto a droppable, but your object can't be dropped onto it because there is no space left, your character (or the AI) will simply release the object wherever you currently are.
  
• if the AI is transshipping and cant pack an object (drops it as described) then transshipping is completed/aborted and if the source droppable is a tent, the dropped object will be put pack there, otherwise not and the dropped objects is left wherever... whatever... (this behaviour can be set per droppable)
  
• Dragging heavy stuff around is a dangerous job. Really: you or your AI could die in the process. (attachedTo objects are easily smashed into your face, so beware, hehe)
  
• Taking/Dragging an object from a droppable will make your character (or the AIs) jump a bit backwards to prevent damage your droppable might take otherwise from the object your holding in your hands now.. (esp. civilian cars are easily damage with attachedTo objects)
  
• I think I've got most suitable objects from A2/OA working now (ammocrates, static weapons and supplies/small objects as draggables; trucks, pickups and tents/camo-tents as droppables). In case you're missing something, drop me a note.
  
• This is all designed for singleplayer only and will not work for mp. But you're free to change this. Good luck. ;)
  

In case you're interested, you'll find more information and lots of comments in the code. Have a look at (in decending order):

• /RUBE/fn/fn_makeDraggable.sqf
  
• /RUBE/fn/fn_makeDroppable.sqf
  
• /RUBE/fn/fn_makeDraggableLib.sqf
  
• /RUBE/fn/fn_packVehicle.sqf
  
• /RUBE/fn/fn_rectanglePacker.sqf
  
• /RUBE/fn/fn_getObjectDimensions.sqf
  

Well... I'm eager to hear what you guys think. Is this useable? What could be improved? Can someone come up with better/nicer particles? ;) Where do you see problems with this approach? Whats annoying the hell out of you? Would you use this (you can of course, hehe)?

Thanks and tweak on!

rübe

Edited July 12, 2014 by ruebe
RUBE_dragNDropDemo3.Chernarus.pbo + RUBE_hideout.Chernarus.pbo

[kremator 1065]

This looks good Ruebe.

Will check it out now :)

[rübe 127]

[genesis92x 810]

Man, I was checking this out and I really love it! I just wish it was MP compatible! This is quite the script you've got going on. I will definitely use this in my SP missions.

[rübe 127]

Will check it out now :)

And? :)

Man, I was checking this out and I really love it! ... This is quite the script you've got going on. I will definitely use this in my SP missions.

Thanks for your reply. I'm glad you like it so far. Though, there has to be still some room left for improvements... :D

Did really nothing piss you off? Everything went fine and as (intuitively) expected? Nothing/no functionality missing?

I just wish it was MP compatible!

If this concept of drag'n'drops proofs to be useful, I'm sure someone could make this mp-compatible as well - which shouldn't be too much of a hassle, granted that someone is knowing what he's doing...

Unfortunately I don't know sh** about mp-scripting, it's quirks and pitfalls.

Neither am I interessted in changing this. :cool:

But again: anyone may take what he needs and incoorperate this into his own mission or something.

[.kju 3244]

nice system ruebe - thanks for sharing!

some observations and thoughts:

• To me the dust effect when dropping objects looks weird.
  
• Why did you not limit the user action to be close to the object (user action distance)?
  
• When you grab an object, it often changes its orientation - is this intentional?
  
• When you grab an object, its often not center to the player view, but is somewhat to the side - is that intentional?
  
• Dropping objects often changes the orientation and position compared to while dragging - is that intentional?
  
• What do you think about the ghost preview concept BI is using?
  
• What about lowering the weapon when dragging an object.
  
• IMO you should not show the user action, if you cannot drop an item onto a vehicle
  
• Did you consider to auto drop, when the player moves forward - too annoying?
  
• You still get the drag user action, even when your inside the static weapon or it has other crew in it (you will drag the crew along :))
  

My overall impression:

# The vehicle interaction works well (except UA even when not loadable)

# The interaction with the item while dragging is annoying

# The positioning of the item when dropping does not work well

# The interaction via interaction menu works well

Personally I'd probably go for the ghost preview approach.

Again thanks!

Edited September 6, 2011 by .kju [PvPscene]

[rübe 127]

nice system ruebe - thanks for sharing!

No, no; Thank you for your detailed reply and the time it took you to check this out. :)

To me the dust effect when dropping objects looks weird.

Yeah, my particle effects are totally weak. This one comes from an early drag-script prototype and I didn't bother to work on it yet; though my particle skills haven't really improved since.

But yes, I plan to do something about it. As far as I see I need to reduce that "smoke" (by a lot) and maybe just end up with throwing a stone and a stick as particle-object every once in a while...

Why did you not limit the user action to be close to the object (user action distance)?

For now, because it makes testing a lot faster/easier.

But good point, though I can't make this too strict, for unloading from trucks could be quite impossible otherwise. On the other hand, maybe I need to bake some quick interface, offering a list of all cargo-objects to pick/drag from anyway.

When you grab an object, it often changes its orientation - is this intentional?

So far yes; granted the implementation is lazy.

Your character stops (forced kneel) and the object gets slightly randomly re-attached, in case you walk too fast (though the threshold is again slightly randomised, so you may take a risk). This should simulate a misstep/accident and thus your character is forced to grap the object again...

I'm not that happy with this either. Another idea would be to simply force-stop the dragging, like NEO_tireFix does it (if you're not in a walking backwards animation I believe), though then you'd need to re-grab/drag the object again, which sounds rather annoying too. Also I need to think of AI, which is supposed to drag things too.

Maybe it helps already, if I'd tone the randomized re-attachment down a bit (or get rid of it alltogether). But for sure, I need to do something here. Yeah.

When you grab an object, its often not center to the player view, but is somewhat to the side - is that intentional?

Intentional, lazy; what's the difference? :p

I think it's not so important, where the object is - centered or not - while dragging (though there is mabye too much random here. Again. :p Have to check).

But what would be needed is a way to (re-)center/position the object you're currently dragging, so you may more precisely drop it. But I wasn't sure how to implement this, so I didn't do that yet. :rolleyes:

Dropping objects often changes the orientation and position compared to while dragging - is that intentional?

No this isn't intentional and one really should be able to place/drop objects quite precise. Guess I didn't care (yet), since I still have no clear concept on how to actually do this, hehe.

What do you think about the ghost preview concept BI is using?

Hm. You mean like COIN does it while placing down objects? I like this for COIN, but I don't see, how this is going to work for dropping objects. While COIN instantiates/creates new objects, our objects are already there, physical and ingame. So I rather not abstract the drop-action with a ghost-object, but drop/place the object itself, as straight/direct as possible.

Or my imagination is simply too degenerated (darn TV!! hehe), so you might wanna elaborate a bit more on how this should work.

1) activate drop action

-> actual object vanishes, ghost object appears

2) move ghost object COIN style? Rotate and stuff..

3) click

-> ghost objects vanishes, actual objects gets placed

Something along these lines? Hmmm. What if you could rotate the attached/dragged object, while holding ALT or something? Reposition with CTRL? All without any ghost object? Wouldn't that be cool? (though I'm not sure, that's feasable; I've never done something with keys/userinput yet)

What about lowering the weapon when dragging an object.

Good point. My plan was to put main weapons on the back. But I guess we can't do that. So lowering the weapon seems the next best option. "acinpknlmstpsraswrfldnon" is what I need, right?

IMO you should not show the user action, if you cannot drop an item onto a vehicle

The problem here is, that I need to run the rectangle packer to know, if something could be packed or not. This function can be quite costly, so I rather not do that on all droppable-actions activation-conditions, but only on command of the user. (when exactly do these conditions get evaluated anyway? Every frame?)

Also I think it's actually quite natural, that you don't know (for sure) if something will fit, unless you actually give it a try. Plus you have a visual feedback to estimate/judge if something will fit. So this probably wont change.

Did you consider to auto drop, when the player moves forward - too annoying?

I worry more about the AI. I can't force them to walk backwards (in the open, ok, I can. But you can't do pathfinding with forced animations), so the AI would drop their objects all the time - unless I'd treat them different than a player (which I'd rather not, but heck...).

But I'll give it a try (and some more thought), since the current (auto-)re-attachTo party isn't working that well anyway.

You still get the drag user action, even when your inside the static weapon or it has other crew in it (you will drag the crew along :))

Hahaha. Good one!

(temp. lock such vehicles and remove drag-action if in use; checked.)

Thanks again for your feedback. This helps alot.

tweak on!,

rübe

[neokika 62]

Hey,

I played around with this a week or so ago and completely forgot to drop feedback, so here it goes.

The idea itself is brilliant, the implementation is impressive, resulting in a very useful and realistic tool.

The way you put stuff onto the vehicles is very well done, the bounding box calculation of objects seems pretty well done, although, may have some space for improvement, at least from my testing I got the idea that you only calculate the space in trunk horizontally and not vertically? Meaning, no chance to put objects on top of objects.

PvpScene already mentioned the actions appearing when they should not, although I have to disagree with two of his ideas.

The ghost mode in my opinion would kind of ruin the whole experience, yes it would be better for certain situations when you have a fast paced game mode or something but I think the whole beauty of this tool is the realistic approach it gives to player.

The other one would be the particle effect when dropping/carrying the objects, I thought it was brilliant when I first saw it, maybe improve it a little bit like reducing and maybe the size/weight of the object would be taken into account and maybe add a sound to it (when the object hits the ground).

Impressive work,

_neo_

[rübe 127]

although, may have some space for improvement, at least from my testing I got the idea that you only calculate the space in trunk horizontally and not vertically? Meaning, no chance to put objects on top of objects.

Yes, what I use is a 2d rectangle packer; respecting only the area, but not the volume. And I'm afraid, but this isn't going to change. First I would need to measure all objects height by hand (which I didn't and that would suck) ... oh wait, not all objects are rectangular, so I'd need to measure not only the height, but also an area with a position-offset (sucks even more). For every fu**ing object that shall be draggable (major pain in the ass).

Second a 3d packer is a bit more complicated than a lousy 2d packer. Ok, that should still be doable, though I'd worry about the increased runtime of the algorithm. Maybe.

And finally - and most important - the handling would be much more complicated. Let's say, our lousy 3d-packer would simply do, as the 2d-packer, while additionally taking said top-areas into account (plus some height-limit; again more to measure by hand: droppables height/volume; this would suck once again, hehe), and following the simple rule that we may only put smaller objects (area) on top of bigger ones (it simply has to fit in the area; same as the 2d packer works).. Fine. And then some stupid fag comes around and drags the object at the bottom away: leaving behind a floating objects in cargo-space. :rolleyes:

Do you see, where I'm going with this? I'd need to keep track of such a parent-child relationship; probably forbidding to drag a parent-object (bottom) aslong as it still has a child-object on top of it... meeehhh.

I'm sorry, but I rather wait until BIS implements a superior, native solution or something. :D

actions appearing when they should not

...because of the distance, right? Again, that will stay for a moment, since it's a lot quicker to test like this. And then, I indeed might include such a condition for the action - though, as already mentioned, I need to double-check, that things are still working (AI, unloading from trucks, ...) and most important: that things are still fun! Getting those darn actions to appear is already quite a hassle, time and again. So I don't want to make things worse. We will see... :)

The ghost mode in my opinion would kind of ruin the whole experience, [...] but I think the whole beauty of this tool is the realistic approach it gives to player.

Yeah, that's what I think and am aming for. Check out the latest improvements (below).

The other one would be the particle effect when dropping/carrying the objects, I thought it was brilliant when I first saw it, maybe improve it a little bit like reducing and maybe the size/weight of the object would be taken into account and maybe add a sound to it (when the object hits the ground).

Don't worry, I don't wanna get rid of them alltoghether. Taking the size/weight (the volume of an object) into account sounds about right; will give it a try.

As for a sound; if there is a suitable native A2/OA sound I can use... why not. But I don't wanna define a new sound and thus writing a description.ext.

On the other hand, I might need to implement some custom "events" (+ handlers; onDrag, onRelease, onDrop ...) anyway (for a coin system with ingame objects representing supplies and some building action)... so you could implement your own sound later on, on a per mission basis. Same approach as with the localization of strings (some RUBE_globals you can overwrite to gain localization).

Thanks for the feedback neo. ;)

...so, I've been working on this a bit more, and here's a

quick update/changelog (2nd release)

Download is still the same: RUBE drag'n'drop demo mission (Combined Operations required) (file has been updated; the old one isn't available anymore)

• Mounted objects (such as static weapons) can't be dragged anymore. I've thought about locking such objects, while beeing dropped onto something (like the back of a vehicle). But I didn't for ... why the hell not. If you drop a static grenade-launcher onto a pickup and have some fun, I'm not going to spoil the party
  Also you can't mount an object that is currently beeing dragged. But that was like this in the first place. (or I need to double check, if this behaviour shows for all static weapons)
  
• Precision dragging/releasing for players. Capturing user input is actually quite easy, so I've done the following - inputListeners only active while dragging an object:
  
  • hold shift + mouseMovement x-axis: rotation of the object
    
  • hold ctrl + mouseMovement x/y-axis: attachTo position/offset, limited to simulate the margin/space given by your arms.
    

  I hope that placing down objects is now a pleasure again and that the choosen implementation/key/mouse-combo are "natural". You tell me.

  ^^ I've tried to block the mouseMovement while dragging and pressing shift or ctrl, but the character still moves/turns around... In the case of rotation, I've implemented a bit of counter-character-rotation (neg. setDir), though it isn't the same amount, and could be a bit tricky nevertheless... :/

  There are no pitch/bank amusements currently going on anymore; pitch could be assigned to shift+mouse y-axis, though that'd be only for fun; as soon as you release the object, the pitch will be 0 again.

  Maybe I can do some pitch/bank-sway while dragging, which goes back to 0 while some precision-object-movement is going on or something... just for the lulz... we'll see :)

  [*] Your character should now lower the weapon prior to dragging. _unit action ["WEAPONONBACK", _unit]; is what I've used for this. Don't know, if there is a better way; for example one that would stop you from putting your weapon back up... I've tried to block the CTRL-Key with displayEventHandlers, but that didn't work: double-tapping CTRL still comes through somehow :(

  On the other hand, shooting while having a box-shield infront of you isn't that unfunny either, so...

  [*] Next I've worked on the "speed-limit". No more crazy object re-attachments. Instead: more bananas! I suggest you just give it a try, grab some object and then you try to sprint with it.

  If you're way too fast, there is a good chance, that you're character will stumple and force release the object - which is quite a punishment for trying to drag the silly way. The AI will never be too fast, so that can only happen to the player. And I find it absolutely hilarious. HAHAHA :D

  On the bright side: if you're not going to stumble, you will not force release the object, it won't jump around; you're character simply is force-stopped by a force kneel.

  Oh and if you happen to trigger that step-on-attached-ammo-crate-and-fly-away-HAHA-bug (CTRL + mouseMovement, remember?), chances are you're flying waaay too fast and then you stumble, force-release the object and voila, no more flying. Nice.

  [*]And then I've tweaked the particles a bit. Which is I've reduced them in number for now: most akward were the particles while AI-dragging stuff around (way too much). This should be alot better now. And then I've randomised (and slightly reduced) the particle amount on releasing the object. Might weight them by the objects volume as suggested by neo.

edit, 11. Sept. 2011:

quick update/changelog (3rd release)

• Objects/vehicles are locked while beeing dragged (for real this time, hehe).
  
• Dust of objects is now weighted by the objects dimensions. Also precision movement (SHIFT/CTRL + mouseMovement for position/rotation) now occasionally drops some particles.
  
• Adjusted limit's of the precision movement range to reposition the attached object (CTRL + mouseMovement). Btw. it's really fun now to drag a box as a shield in front of you (while moving backwards of course), since you may now really position and rotated said object, so you're still able to return fire (instead of shooting in your shield, hehe).
  
  Pretty cool, hu? :D
  Though, since this is only possible if you imagine your character drags that object with one arm, while using his main weapon with the other arm... I wonder if I could (and should) force fatigue/a shaky aim while dragging something? Is this even possible?
  

I hope that's already a bit better. You tell me what's the next worst thing that should be improved.

Thanks you guys and tweak on!,

rübe

Edited September 11, 2011 by ruebe
update: 3rd release

[J-Guid 10]

Where is files with 3d Update?!

[rübe 127]

Where is files with 3d Update?!

The latest version is always linked in the first post. Older versions aren't available anymore.

update/changelog (4th release)

Draggables, dropables and now new in this version; an alternative to the Construction Interface (CoIN) - or a tweaked version of it: buildables!

The idea is as follows:

• Open CoIn to build as usual. The difference is that the buildings/structures won't get spawned directly. Instead, a building-site get's spawned, which doesn't cost anything (so you could deploy as many building sites as you like...).
  
• A building site can be deleted again (as long as no unit is working on it) and as a unit (player or AI) you can work on it. If you're a player then you lose control over your character, a cam script starts (maybe I simply will take the internal/external camera...) and then "you" work like the AI would. You can interrupt that process with hitting W, A, S, D or SPACE. Also AI can be ordered to stop working.
  
• To build on such a building site, supplies are needed, represented with real ingame objects (crates, boxes, barrels and stuff). Either you start building already with supplies in your hands (dragged). Or the fsm looks for supply-objects in a defined radius (100m) and use these supplies.
  Also the idea is, that you shall be able to take some truck, fill it with supplies, take some AI with you and then you can go somewhere else and build stuff anywhere.
  
• A building site is partially fenced (if big enough; otherwise only corner-flags) and ruins will be spawned, which currently are unfortunately very problematic for AI pathfinding (you can disable them in /fn/fn_makeBuildable.sqf if you care). And there will be one arrow-object for each building site. All building site information and actions are attached to this arrow, so this is where the action to build comes up.
  
• This is still a very early prototype and some stuff/functionality is still missing (such as an option to "look" into supply-objects, to find out, how many supplies are in there. I think a generic open-crate dialog might be nice.). Also the building-particles need to be reworked and other stuff... :)
  

Some images:

Then there were some other changes:

• Dropping on upper surfaces is now possible (e.g. you may now drop some static weapon on a roof or watchtower). So stuff put into the air should fall down/onto surface beneath now, though unfortunately not all objects in game are affected by gravity. :(
  
• Fixed some bug in RUBE_spawnObjectGrid (used for fence)
  
• On request I've also measured the present ingame boats to make them drag and dropable. But unfortunately most boats are simply too large to fit on any of the ingame vehicles (aka dropables). Well, if at all, I suggest you try the PCX which should at least fit on the open rusky truck.
  

Please give it a try and let me know what you think. Any suggestions are welcome.

Thanks and have fun!

rübe

EDIT: oh, and please vote for these two CIT-tickets, ;):

• AI pathfinding over ruins/terrain-like objects
  
• make actions on objects show up in the quick-command menu to command AI
  

Edited November 13, 2011 by ruebe

[kremator 1065]

Like the idea of this .... nice one !