[Resolved in TDM 2.04] Picking up stuff without clunking it

[Obsttorte]

Placing moveable objects a bit above the underlying surface should be a common technique in mapping imho. I didn't realize that when I started mapping, but got used to it pretty soon. We could still fix it anyways.

 

And the object should slowly glide into the central position instead of snapping, as said before.

 

Besides that very good work, Steve.

[Oldjim]

I like it - and adding 0.1 unit lift will get round the problem in some of the FMs where it can sink in

One question - how do you pull a frobbed item towards you as I can't see anything in the wiki about that

[SteveL]

Use the mouse wheel to move the item back and forth. That's all I was doing. It looks a bit different in the video because of the non-standard starting point.

[Oldjim]

Doesn't do that for me - must look at setting the control back to default

 

EDIT

Removed all other actions from the mouse wheel and it still doesn't do anything

What else do you have the mouse wheel set to do

Edited May 16, 2015 by Oldjim

[Obsttorte]

It's the default behaviour, you don't need to set anything. What action did you set your mouse wheel to?

[Oldjim]

It was set to cycle Inventory Group and now it isn't set to anything

What is the default action

 

EDIT

Remembered the default action was cycle weapons and with it set to that it works

Edited May 16, 2015 by Oldjim

[SteveL]

Smoother action.

 

http://youtu.be/nsPv19Vih30

[Destined]

Looks really good now. Good work!

[AluminumHaste]

Yup that's great, just the way I imagined it.

[Oldjim]

Absolutely fantastic - is there any way of adding it before the next release

[Springheel]

This will be great, and what's even better is that most players won't even notice the change.

[Obsttorte]

Awesome work, mista. Thumbs up

[SteveL]

Absolutely fantastic - is there any way of adding it before the next release

 

It'll have to wait for a release I'm afraid. No way that I can see to fake this one with a script.

[SteveL]

I tried it out in a real map and it feels good. You can deal with candles faster but still have to pay attention. And you can search through a wardrobe full of junk next to a sleeper without random thumping sounds. I can still occasionally get an item to sink in to a surface, but only if I'm trying to by frobbing it while sweeping downwards. That might be tweakable too.

 

Absolutely fantastic - is there any way of adding it before the next release

We can't distribute a fix with maps before 2.04 (unlike that LOD fix in Forest, for example) but people can try it out to give feedback here. I'll link a replacement game dll, which will be TDM 2.03 plus the grabber experiment. To use it, save the file in your darkmod folder next to tdm_game01.pk4, overwriting the same-named file if there is one. You can revert to standard TDM 2.03 just by deleting the file (game86.dll).

 

[link removed and replaced on post 55, page 3]

 

One thing to be aware of: save games made using this version won't be compatible with standard TDM 2.03, and vice versa.

[Oldjim]

Tested it in Sir Talbot's Collateral and it worked fine however there is a side affect - checked on that mission and Alberic's Curse

The screen where you select difficulty level

Once you select one there is a 2 or 3 second delay before the mouse will respond

[SteveL]

Thanks for testing. Hmm that delay you mention has me puzzled. I'll see if I can rep it this end.

[Scampada]

It was set to cycle Inventory Group and now it isn't set to anything

What is the default action

 

EDIT

Remembered the default action was cycle weapons and with it set to that it works

I have also set mouseWheel for cycling Inventory and object handling works fine for me.

 

I'd like to handle candles without noise as was proposed also... It's quite difficult to put out a candle comparing to Thief 3 without attracting attention.

I thought you just blow it out instead of taking it, doing smth to it, and then putting it to its place...

[Oldjim]

Difference is I was cycling Inventory Group not Inventory

[Tels]

Does everyone use the mousewheel for moving held objects back and forth?

Is there another way? if so, I never knew.

[SteveL]

Is there another way? if so, I never knew.

 

I don't know of any other way. I wondered if others did, or had rebound the action. The "12th" rule seemed to me to be designed for keyboard action, so you can move any object across its entire range using a limited number of keypresses. NB that question was before we thought of the current proposed fix... I wanted to know whether we had the option of changing the 12ths rule.

[Tels]

The snap to position is the same as it is now. It probably looks worse because I'm grabbing things that are so close in the vid. But we could have the item glide smoothly into position rather than snap if we want. And we could try shortening the min distance, but there could be some larger moveable items that then clash with the player at min distance. Those would need identifying and they'd need bespoke min distance spawnargs.

Sorry, didn't have internet for a few days, so I'm late. But I'd definitely change the "snap" to a "smooth move", even if it moves faster than normal.

Snapping just looks out of place.

[Tels]

One thing that makes me wonder is the "min. distance" and once you scroll/rotate, it will move to the minimum distance.

 

That would mean players could easily circumvent the minimum distance by just moving closer, but lose it once they rotate the object.

Wouldn't it be better to not have the min. distance at all? That somehow feels awkward, to have the ability to get objects real close in some case, and not in some other cases.

 

Otherwise, outstanding work!

 

Btw, moveables should be placed flush with the surface - this avoids physics "bumbs", and artefacts due to floating objects like light shining between the cracks

and the player being able to look through the crack. So adding 0.1 unit to avoid the "sink in" is a nice idea!

Edited May 18, 2015 by Tels

[SteveL]

One thing that makes me wonder is the "min. distance" and once you scroll/rotate, it will move to the minimum distance.

 

That would mean players could easily circumvent the minimum distance by just moving closer, but lose it once they rotate the object.

Wouldn't it be better to not have the min. distance at all? That somehow feels awkward, to have the ability to get objects real close in some case, and not in some other cases.

I'm not sure TBH. I'm not sure what side effects removing the min distance would have. It might have been just a rough method of stopping the player pulling in objects so close that the player ends up with their eyes inside the object, and to do that without needing to write more complex collision detection code. That's probably the reason for the min dist, given that the default 35 can be changed on any entity with a spawnarg. But we don't set that spawnarg in TDM. None of our standard moveables have it. Only AI ragdolls change it. So if we were to remove it or lower it, we'd have to detect all the bigger moveables out there that could cause a problem, including entities unique to certain maps, and set the spawnarg for them. I figured it was better to leave the 35 default in place and "blend" it in with the new grabbing mechanism. The fix above does that. You can't get into a solid object in normal play, so you can't pick it up in a problem position. And as soon as you start to manipulate it, the original minimum distance takes over to preserve the non-buggy arrangement.

[Tels]

Just throwing out ideas:

 

But if the player can't move into a solid object, you can never get closer than the "per-object minimum distance", anyway. So why enforce in the code a

larger "minimum" distance?

 

It makes sort of sense if the object moves immidiately to that distance, the idea was probably so the player can "hold" important objects (readable whatever? small item?) closer.

 

Not having these values set, but the code looking for the spawnarg is our "default design policy". If possible, make things configurable, even if we don't need it right away. That explains why the code is there, but the spawnarg unused.

 

Now that the behaviour is changed, maybe we should change the "minimum distance" spawnarg to:

 

* if set, use it

* if not set, don't use it (instead of assuming 35 units).

 

This might make more sense for the player observing how objects behave. And it still allows overriding and setting a minimum distance (f.i. for large or unwieldly objects like planks).

[SteveL]

But if the player can't move into a solid object, you can never get closer than the "per-object minimum distance", anyway. So why enforce in the code a

larger "minimum" distance?

Because of planks, and other awkwardly-shaped moveables. You might pick them up at a certain distance without their intersecting your head, but as soon as you start to rotate them, that distance might not be enough.