Create new Pickupable behavior - collect, carry, throw, place

[LeeBamberTGC]

Create a new simplified behavior and assign by default to all objects that should reasonably be carryable, up to the size of large crates. Allow for collision, smooth positioning of the carried item. No need for the stack system for this simpler version, and ability to set the weights and frictions of the objects through common properties (and assigned correctly by default based on material type). Size should start the initial mass volume of the object so good defaults.

[AmenMoses]

Is there a Lua command to set the entity weight?

If so does it cause the physics mass to be recalculated on the fly?

Ditto for friction.

Why not stacking?

Anyhow if you have commands now to set mass/weight/friction on the fly I can tweak the proper pickuppable script to have them as dynamic Lua settings very easily.

Although could you fix #2279 so it will work properly with all entities.

[LeeBamberTGC]

@AmenMoses I certainly would prefer to resurrect your full pickupable script, but as I did not write it I got lost along the way and could not bend it to my will with the current system, the object did all manner of interesting things. Ergo my solution to start from the known with something simple, and build it out again as MAX requires. Happy for you to see if your original can be reborn, and if 2279 helps, let's start there :)

[AmenMoses]

Well if you tell me how you want it to behave, i.e. which keys/mouse buttons trigger push/pull/throw/rotate then I can tweak it to your will. :)

[LeeBamberTGC]

@AmenMoses Thanks for the help :) Do let me know if the engine gets in the way!

I was going to have the following controls:

• When get close enough to an object marked as pickupable, it prompts the user "Left Click to pick up object"
• Any object too large to be picked up will instead read: "Object is too heavy to pick up"
• Once collected, the object will hover in front of the camera view at a distance scaled to the size of the object
• No rotation control is given, the object will retain the rotation it had before it was collected (i.e. a bottle will remain upright if collected from a shelf). The only rotation happens if the camera rotates on the Y axis (so the player always faces the side of the object they originally saw on picking it up)
• The player can move about, the object uses physics to not intersect physics, and will draw closer to camera of collision stress too great, and back out to normal distance when collision event over
• Clicking again will throw the object a reasonable distance, the object physics mass will control how far it goes naturally
• Right-click will drop the object with no throw velocity, so allowing placement back down carefully
• Player movement and jump modulation changes based on weight of the object, a light object has almost no effect, carrying a heavy concrete block will reduce the player to a crawl.

The above would allow players to pick up a crate and stack it on another crate, and create a crate staircase if they wanted to with a fine level of control.

Down the road we might look into the possibility of extending the new weapon hand system to grasp the object to give an extra level of realism to the carrying of objects, and to handle edge cases like carrying long planks and ladders which would present some issues with the above solution.

[AmenMoses]

Ok so the pickuppables script does pretty much all that already except 'throw' is left click + a modifier key (currently 'R' but could equally be shift or 'E'. For WASD use 'E' or 'R' is more intuitive but some users suggested 'E' should be for using the carried object in some way or as an alternative drop mechanism, i.e. 'E' to pick up and drop.

The rotation is something that most people I have conversed with actually want, i.e. so you can examine the object you have picked up or orientate it to fit a puzzle or similar mechanic. RMB is currently used for rotation.

I can make all the current behaviours switchable via dynamic Lua parameters, i.e. rotation, throwing, stacking can all be made selectable.

Your fifth bullet point is something to think on though, how do you suggest "the object uses physics to not intersect physics" be implemented? How do I detect in Lua when the collision occurs when the only way of moving a dynamic object smoothly is to first turn collision off and then turn it back on afterwards?

[synchromesh62]

I can make all the current behaviours switchable via dynamic Lua parameters, i.e. rotation, throwing, stacking can all be made selectable. I was about to suggest that when reading Lees bullet points. In fact that would be awesome to have full control of what you can and cannot do. For a Shooter you want to pick up and run .. For RPG you would probably want to pick up rotate and examine and the same for puzzle ... @LeeBamberTGC I would grab all the features Amen is offering so its future proof for RPG and Puzzle elements :) Just my thoughts ..

[LeeBamberTGC]

@AmenMoses The tick boxes in the behavior script is a good idea, that way users can tailor it to how they want pick up of objects to work for their specific game :)

For the last one "the object uses physics to not intersect physics", it can be done by working out the distance between where you want the object to be "destination XYZ" and where it actually is under physics "current object XYZ". After some time to move, if the distance of these two vectors is greater than a threshold, it means the physics cannot get the object to the destination and is using greater force to get it there and failing. If this force/distance gets greater, you can pull back the destination XYZ to be closer to the camera, and out again when there is no force (i.e. no collision due to physics interaction). It is a general solution that should always attempt to keep the object carried free from physics collisions of any kind.

[DaveTGC2]

I'm strongly against scripting to pick up an object as that ties the object to having to have a script assigned to pick it up, and prevents other scripts being added to the object. If we have a controllable via sliders and tick boxes system we can then allow another script to be attached to the object. I'm not sure what scripts you might want to attach at the moment, but for an easy game maker I wouldn't want to attached a carry script to possibly 1000's of objects.

[LeeBamberTGC]

@DaveTGC2 Do you want to post this issue link on DISCORD to get some more views, I need a pressing reason why an object can be both carried, and also operating some other behavior.

[DaveTGC2]

I will do, but from my point of view I wouldn't want to assign a carry script to EVERY object I wanted carried, Take games like Half-Life and even the Fallout series, you can carry most things. There could be so many, people wouldn't use the feature, or if only a few behaved like that it would be confusing and wouldn't have linear flow.

Thinking now, I would suggest you might need to throw a volatile barrel away before it explodes, or maybe be a light source, or even if you have to take Object X, Y distance within/away from Object Z.

I feel scripting the carry script restricts the engine.

I would prefer the settings were under Player options. e.g.

Can Pickup? Can Throw? Maximum Weight? Can Rotate? Can Stack?

[Granada1]

I will do, but from my point of view I wouldn't want to assign a carry script to EVERY object I

I have to agree with Dave on this one

[DaveTGC2]

@LeeBamberTGC - It's a mixed bag, and @AmenMoses has some strong opinions :), But the general feeling on Discord seems to be in favour of a hard-coded system under player options, that allows for tweaks there, but with the ability to override it so you could use the carry script. I think this goes back to what's the easiest, friendliest option for users and a mix of both seems to be the way.

It's also been requested, that if the system is hard-coded that the hard-coded options are exposed in Lua, allowing for more flexibility.

[LeeBamberTGC]

@DaveTGC2 These days I shudder at hardcoded. I can see the pitchforks from here :) How about an object can have TWO scripts running side by side, that way the pickup script can still be modified and tweaked outside of some hard-coded C++ box. I am sure there are other uses for having two scripts that can independently operate on the same object (for future-proofing).

[AmenMoses]

Hmm, having multiple scripts running in a single entity is I think overcomplicating the issue and asking for trouble.

But, scripts could generate events which other scripts could act upon, for example currently the pickuppables script has a function CheckThrowCollision() which checks if a thrown object collides with the terrain or another entity, this function could generate an event which other scripts could then react to, for example to trigger a switch script.

But I am with Lee here, hard coded behaviour should be avoided where possible.

[davetgc]

I can see why you'd want to avoid hard-coding. And I'm with AmenMoses that 2 scripts would be over complicating things.

How about the carry script becomes part of standard player behavior? ,

With the mentioned options under player settings?

Can Pickup? Can Throw? Maximum Weight? Can Rotate? Can Stack?

So, there's no need to cherry pick every object that can be carried, and then allow single objects to be excluded from being carried with a can't be carried tickbox added to object settings. All physics objects below Weight X, and not excluded could be carried, thrown, etc.

My chief concern here is to make the carry system simple for everyone to use, from young kids, to the less able. One thing that keeps coming up is how many users with have 50+ who aren't comfortable with even adding scripts, yet alone coding. And, while we need to cater for the advanced user, this is the Easy Game Maker.

Is that a compromise?

[AmenMoses]

"So, there's no need to cherry pick every object that can be carried" But this will still be necessary anyhow, most objects will be static by default and will most likely have the wrong physics shape and weight modifier so the user will still have to change settings on them.

Also what happens to dynamic objects which already have a script attached when this player behaviour/script /whatever attempts to interact with it?

I still don't get how it would work as a player behaviour script anyhow not without some way within Lua to figure out if an object is carryable, or are we to have yet another g_Entity flag?

[davetgc]

I'll leave this to @LeeBamberTGC to decide. I'm still 100% against the script method. I think it goes against the whole easy game-maker principal and is a step in the wrong direction for the average user.

[LeeBamberTGC]

@davetgc I would still have a LUA script so it can be coded externally and tweaked. If we did have a flag, I would simply add some code that auto attaches the pickup script to the object and it would run its own script and an optional pickup script during the game.

I can see scenarios where you want to say pick up the "candle smart object" (that contains a light and a particle) and walk about with it. Any other scenarios you can think of?

[davetgc]

Light would be one. I can also see things like needing to get object A away from object B or visa versa.

On Thu, Apr 21, 2022 at 4:21 PM Lee Bamber @.***> wrote:

@davetgc https://github.com/davetgc I would still have a LUA script so it can be coded externally and tweaked. If we did have a flag, I would simply add some code that auto attaches the pickup script to the object and it would run its own script and an optional pickup script during the game.

I can see scenarios where you want to say pick up the "candle smart object" (that contains a light and a particle) and walk about with it. Any other scenarios you can think of?

— Reply to this email directly, view it on GitHub https://github.com/TheGameCreators/GameGuruRepo/issues/2848#issuecomment-1105281888, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXZOFYPTZUYKQURXJIXPBEDVGFP6PANCNFSM5TOH5MHA . You are receiving this because you were mentioned.Message ID: @.***>

[MonkeyFrogStudio]

AmenMoses responded to me about why he's against this being hard-coded. His reasoning seemed sound, actually. Here's what he said:

GG/MAX need to be a generic game creation tools, any hard coded behaviour is going to get in the way of at least some genres/styles of game so unless something is generic across all genres/styles it should not be hard coded. Instead all game engine functions should be exposed via Lua functions and the game behaviour aspects should all be scripted.

When read that way, I have to agree with him. And that means I've changed my opinion from hard-coded with a script override.

What I was thinking, though, is that perhaps the "pickupables" should not be a script that's attached to objects, but more of a "script" that's somehow attached to the player, almost like a "weapon" is. Make it more like an "ability" the player can have. That way, if the end-user "attaches" the "pickupable" to the player, then they can adjust that player behavior to be able to pick up items of a certain weight/size. Without this player behavior, then picking up objects would not be possible.

[davetgc]

Hi Lee,

That was more or less the compromise I suggested, that it could be part of player behavior. Being a tick box to say the player can carry things. Have I understood you correctly? In which case, I agree and support that.

My real main concern was having to attach the script to every object that needed carrying. It felt cumbersome.

But would it be possible to carry stuff, and have a weapon (ideally, you would want the weapon to hide, or for it to be impossible to pick up with a weapon in hand.).

On Thu, Apr 21, 2022 at 6:18 PM ArgentArts @.***> wrote:

AmenMoses responded to me about why he's against this being hard-coded. His reasoning seemed sound, actually. Here's what he said:

GG/MAX need to be a generic game creation tools, any hard coded behaviour is going to get in the way of at least some genres/styles of game so unless something is generic across all genres/styles it should not be hard coded. Instead all game engine functions should be exposed via Lua functions and the game behaviour aspects should all be scripted.

When read that way, I have to agree with him. And that means I've changed my opinion from hard-coded with a script override.

What I was thinking, though, is that perhaps the "pickupables" should not be a script that's attached to objects, but more of a "script" that's somehow attached to the player, almost like a "weapon" is. Make it more like an "ability" the player can have. That way, if the end-user "attaches" the "pickupable" to the player, then they can adjust that player behavior to be able to pick up items of a certain weight/size. Without this player behavior, then picking up objects would not be possible.

— Reply to this email directly, view it on GitHub https://github.com/TheGameCreators/GameGuruRepo/issues/2848#issuecomment-1105433927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXZOFYJECV3EG3MKBWAZ4XDVGF5VLANCNFSM5TOH5MHA . You are receiving this because you were mentioned.Message ID: @.***>

[MonkeyFrogStudio]

@davetgc We have a script for climbing a ladder that auto-hides the weapon when we start to climb the ladder. In like manner, when the player picks up something, the weapon can be put away, too, I would think.

[MonkeyFrogStudio]

I've added a suggestion here:

https://github.com/TheGameCreators/GameGuruRepo/issues/2916

I don't know if it's doable, but it would be cool as heck, I think and could be used for this issue, too.

[DaveTGC2]

@ArgentArts - A good point about the ladder script. Thanks for the reminder.

[LeeBamberTGC]

@ArgentArts Nice link to the other feature request, I am liking the sound of stackable player behaviors. Right now it is all buried in the "gameplayercontrol.lua" script, but splitting it out and allowing parameter changes on each "skill" sounds very MAX :)

[MonkeyFrogStudio]

@LeeBamberTGC Thanks! The idea is simple - if I want to create a game like Thief, then I include the Player Behaviors that make that happen and exclude the ones that would detract from that. If I want a game like DOOM, then I exclude the ones that would make it more like Thief, etc. So, yeah, a totally customizable character that is also expandable by the community, via the store, etc.

[Necrym59]

Having a Basic player container plus adttional skill/capability container of scripts seems a plausible way to go, some skills/capabilities are also supplied to the player via object scripts as well though. You just cant realistically start a player with all the games features worth earning so to speak. It would have to be tempered within realistic game style scenarios as Amen suggested and be flexible for crossover genres this should be a adjunct to the myserious Game Genre buttons up top. As for the simplified pickuppables idea just give the player a capability and use the physics of the engine to dicate what he can pick up or not based on its weight/size, would be a simple solution.