Regarding Chest models/ Prefabs

[Baddcog]

OK, I decided to dive into the chest prefabs and figure out how this all works.

 

Wiki Beginner's Guide:

Thankfully I've got Fidcal's beginner guide to work with, that got me 90% of the way there. Looking into Thief's Den I found the key set-up.

The Wiki beginner's guide could use the used_by key_name info added. I'll leave this up to Fidcal as it's his guide, I think a note about prefabs should also be added to the very top of the section as they will all be ready to go before release and the time that authors will use the guide.

However I think it's good to have the entire set-up following that incase someone wants to make a chest of their own or trouble shoot.

The prefab info should be first as an author can just create the prefab and they are pretty much done.

 

Chests Names:

This is my fault. I thought chest 1, 2, and 3 would be good enough. Now that I've created a prefab I see the error in my ways. DR wants to name things with a number prefix. Hence the prefab of chest_2, chest_2_lid, chest_2_lockbar became chest_1, chest_2_lid, chest_2_lockbar as this was the first 'chest' object created in the level.

So if no one objects to yet another name change it would be greatly improved to have names such as chest_metal, footlocker_wood, chest_wood.

They might still get a prefix added, which will need to be removed by authors when prefab is created, but it is certianly less confusing to remove a number from a name that contains no numbers.

 

Chest Lockbar issues (I need help here):

I have set up the chest the same as the Wiki guide with one exception. Now that all the chests have a lockbox as part of the chest model I put all the 'lockbox' info on the chest itself.

The chests works as it should with a key.

However, when the lid is frobbed the lockbar runs thru its range of motion and bounces back to it's start position. This is when frobbing the locked chest lid and getting a locked sound. The lid stays closed and locked, the lockbar should likewise stay in the locked position.

The lockbar works properly when unlocking the chest.

The lockbar doesn't move when closing the chest with a key, probably because it has already bounced back to the locked position.

 

Also, the chests didn't seem to relock when using the key to close it. However I'm just thinking of that now and may have been reopening with the key instead of just frobbing.

 

I could not find the solution to have lockbar behave properly and NOT move when locked.

 

Frobbing Issues:

As I am starting to set this up I guess it would be a good time to go over the frob highlight.

Currently I have used frobable 1 and 0 on the chest itself. Generally I am fond of having as little as possible highlight. But I am starting to think that it looks slightly odd to have onlt the lid highlight and not the rest of the chest. So I guess I have changed my previous opinion and now think that the entire chest should highlight.

Opinions on this?

 

The chest I am working on is now on SVN in prefabs.

chest_2_locked_key

When creating make sure the names stay chest_2... and don't have a prefix of 1 anywhere. This is temporary so don't use in a level other than for testing purposes. Once it is correct I will create prefabs of all chests.

[Baddcog]

OK, I've got one of each chest set-up in a locked_key prefab. I also have one chest set-up as an unlocked prefab.

 

I went ahead and changed names to make it easier, I'll upload later and give Beta testers a week or so to change names. I might wait to upload until after Thiefs Den release just in case it would cause any issues.

 

I am having one problem though:

The lockbar works on 2 of the chests. But in the 3rd chest set-up the lockbar won't move at all. I've been over this about 10 times now, I'm lost.

It should rotate and has the EXACT same props as the other rotating lever (2 chests have rotating levers, 1 chest has translating lever which works fine).

 

For some reason I cannot get it to rotate at all.

 

Once I get it to rotate I'll work on lockpick prefabs.

-----------------------------------------

 

I think the issue with the bounce-back on the levers when frobbed needs handled inside the atdm:mover_door_handle props. The levers should not move when locked and when unlocked they should only open, not bounce.

I guess they are using the door_handle_rotate script and need a chest_lever_lock script instead.

[Baddcog]

Added test/chest_prefabs.map to SVN

Also added the new named chests, I will wait until after Thiefs Den release to delete the old ones. This will be noted in the Beta Mappers Watchout thread.

 

It has all 3 chests set-up with a key, unlocked and with lockpicks.

 

I'm finding the lockpicking fairly hard to do. Personally it's very hard to tell where one sound ends and another begins, and exactly which sound I am trying to listen for. All sounds like a bunch of random clicks to me really. Not sure if the new sounds have been implemented yet.

 

I have the lockbars working and moving but notice some other oddities that probably need fixed in the scripts. Seeing the lockbars move does help with lockpicking, but it is still difficult. It is only easy to determine which picks to use/not use. But not exactly HOW to use them.

 

1-as mentioned in above post, frobbing moves the lockbar lever even when it is locked.

2-When you make a successful pick the lockbar bounces back to start. When you use the correct second lockpick it jumps to the resting state where it should be AFTER the first successful lockpick, then starts moving from there.

-----------

I will start on door prefabs next.

 

 

--EDIT--

--info copied from beta mapper watch out for thread

-----------------I will upload the prefabs within a few days once I have had a good chance to double check them all.

I have made prefabs of each in locked_key, unlocked, and pickable varieties.

Each has a chest, lid and lockbar attached and working properly.

 

Locked_key version has a simple key included, this key can be deleted and replaced with another key of your liking. Properties can be compied from this key to the new key entity of your choice.

 

Unlocked version is unlocked with no key.

 

Pickable has all the lockpick properties, you just need to adjust which lockpicks should work and how many pins they have. Currently they are set-up to be simple to open just so the props are there. You will need to include neccesary lockpicks in the players inventory.

 

Make note that when a prefab is created it will still need some tweaking, however it is alot easier than adding new props to every chest/lid/lockbar you create.

If you create a footlocker_wood_locked_key prefab DR will name the pieces with a number at the end.

footlocker_wood1 will be the result. I suggest giving them individual names right of the bat:

footlocker_wood_bedroom, footlocker_wood_lid_bedroom, footlocker_wood_lockbar_bedroom, footlocker_wood_key_bedroom as an example

Easy enough as you can just type _bedroom once and copy paste into all nessecary slots. In addition to changing the names you'll need to paste _bedroom into these catagories of each prefab piece (chest, chest_lid, chest_lockbar and chest_key) as they exist on a per object basis.

 

name

 

door_handle

 

frob_peer

 

frob_peer_1

 

used_by

 

This will take about 2 minutes per chest as opposed to about 10+ minutes to set-up each chest from scratch.

 

To change lockpick props you need to select the lid and adjust these props:

lock_picktype bc -uses one pin for the Bent lockpick and one pin for the round(Circular) lockpick. Snake and Triangular are the other 2 types of picks you can use.

 

lock_pins 12 - This set-up would give the above B pick 1 pin and the C pick 2 pins. You need one number of pin for each lockpick type above.

Fidcals Beginners tut on the Wiki has all the lock info on page 5.

 

lockpick_rotate - is place on the lid model. 22 0 0 would make it rotate 22 degrees per lockpick type. So if the lockbars rotate prop is 45 0 0 it will rotate that far altogether. 22 is just a rough estimate and it will probably move only 44 degrees when both pins are picked which is close enough. However if you have 3 lockpick types you'll want to change this prop on the lid to 15 0 0.

lockpick_translate is on some of the chests instead of rotate, it works the same way.

 

If you have a multiple keys with the same inv_name prop. ie: footlocker key they will all stack together, so it is important to determine which keys should stack and be used on the same locks, or should not stack for use on different locks.

However it is the actual name prop (of the key) that is used in the used_by prop of the lid to unlock the chest.

[Fidcal]

Bet you forgot the no-frob zone I mentioned before else players can just grab stuff straight out of a locked chest If in doubt I can look at that after Den is released.

 

The Beginner's Guide is on my todo for a major update when Den is out of the way but even then there are still things that are not completed yet so I cannot completely finish it until they are.

[Baddcog]

I haven't done a no-frob zone but in the first test I did place a trophy (large loot) and I couldn't frob it thru the locked container, I guess I thought that stuff was working.

 

I will do some tests though, thanks for bringing it up. No rush on the Wiki stuff, I figure it needs done before release is all.

[Fidcal]

Can't imagine how the trophy eludes grabbing but it might be deeper in the chest with a shorter frob distance. Try low down and from all sides.

 

Anyways, if you do look at no frob then there is a test map and it uses a brush entity with clip texture inside the chest linked to the lid. The entity is target_set_frobable and the door needs trigger_on_close and trigger_on_open and target the entity. The entity brush needs very careful sizing - see test map and also Den.

[Baddcog]

Well, I just did a test with a few loot pieces but mainly the trophy.

Out of 3 times in the level, trying to madly frob thru chests of locked_key, pickable and unlocked I only got a trophy thru one locked chest (wood round top chest, the smallest dimensions of all three).

 

So that's a total of 27 chests (9 per map) and I only got the trophy once. That's not perfect but not bad. We deffinately get to frob thru stuff alot more in T2. I just recently frobbed something thru a safe in 7Sisters.

 

I'd like to play with it more just to see how many times I can actually get it but I am frobbing like mad and aiming all over the chests, ect...

 

I looked at ThiefsDen just now too to see the frob zone. I suppose it works by blocking the frob to any item who's origin is in that zone? Not messing with it now I don't know exactly how it works but if that is it it seems like a frob zone that takes up the entire contents of chest should suffice.

 

Currently the chest origins are on the floor so a frob zone in their center shouldn't interfere with frobbing them. Also I have the frob_peers set-up on the chest lid and lockbar to refernce the chest so that should make it frob highlight and block the loot?

 

--EDIT--

 

OK, I went in again and was able to frob the trophy through the chest one. It was sloppy placement to begin with and fairly high up (kindof floating in there). So I lowered it down into the chest more.

 

5 times in game and I can not frob it anymore. So I think if it is low enough there doesn't seem to be any problem or need for a frob zone.

We might just need to make note on the Wiki that loot placement is critical and should be tested before Fm releases.

 

I will play with it more later, tired of it right now.

[Fidcal]

You can't rely on placement being low nor on you can only 'sometimes' frob right through the chest - it has to be reliable. The no-frob zone works well and is well tested. Read the thread for details. It was well noted that putting frobbable items in front was not reliable. I had a wall of frobbable panels lining a chest and still I could frob the loot through the walls of the chest. I had a lot of problems with Den until the no-frob zone cured it. Admittedly I have the loot high because I put an extra blanket below it. I found if I put the loot low enough and lowered the frob distance so it could not be reached through the chest walls then it could not be reached from above either when the chest was open.

 

Have you examined the test map? I could frob items through the glass until the no-frob zone was perfected. Different items and positions and frob distance all have their effect. Don't be too hasty to dismiss the no-frob zone.

 

The no-frob zone should NOT take up the whole interior of the chest. I did a lot of testing to find the optimum. I think the reason is that it relies on 'clipping' so if too big then an object dropped at the side of the chest can lose its frobbability when the lid is closed because its clip model intrudes.

 

We are right this moment having the exact same problem with an objective location brush which also uses clip detection.

[Fidcal]

Actually I might be wrong about the clipping - it's possible that the no frob code tests to see if the origin is inside the clip of the no-frob zone - I'd have to check to make sure. But I do recall the problems when the zone was too big.

[Baddcog]

I'll look into it more, I haven't checked out the test frob map yet.

 

But I gotta say with that minor adjustment in height of the trophy I have not been able to frob it again. Considering it is one of the larger loot pieces... But I will not dismiss the frob zone...

 

 

I checked out the no_frob_zone map and noticed something weird. (just played in game)

If the lid is open I can frob the items through the back of the glass chest.

 

Back in my chest_prefabs map I could not frob through my chest even if it was open, I actually have to have a line of sight on the loot.

 

I've uploaded all the current prefabs, the current vers of test/chest_prefabs.map... All chests have loot so it's a good frob test.

 

------------------

I did notice something else weird about the lockpicking.

 

IF I try to lockpick a chest that is locked with a key I get a 'wahoo, whippy' voice over like I successfully picked the locked, when in fact the chest is still locked.

---------------

[Baddcog]

Working on doors now.

 

As Fidcal is paying attention I'll note some more Wiki stuff related to doors.

 

The value:

door_handle_bind_flag

should probably be added to the door section in the Wiki.

 

The Value:

frob_peer should be added to the door handle, other wise it takes 2 frobs to open door and the handle stays down. (Only on the first door frobbed though)

---------------------------

I currently have the doors and handles set-up as entities so all required values are there, just need editting on a per door basis.

 

I'm trying prefab doors but this seems buggy and I've been getting some D3 crashes when trying to reload a map.

 

I've also added a double sided door handle to cover both sides of a door.

[Ishtvan]

I checked out the no_frob_zone map and noticed something weird. (just played in game)

If the lid is open I can frob the items through the back of the glass chest.

That´s not a bug, it´s an inherent issue with the design. The chest only knows to make the items frobable or not based on whether the lid is open or not. It can lead to the issue you´re describing, but we didn´t come up with a better design and I don´t think that issue is very important.

[Baddcog]

Yeah, most likely players won't open a chest so they can go around back to frob the loot through it.

 

But currently I'm having no issues what so ever with frobbing through the chests. I'm gonna keep testing for awhile yet but i am beginning to think that the no frob zone isn't needed for chests.

[Fidcal]

Don't know what's happening but looks like we need more testing without no-frob zone as your experience seems to conflict with mine and I did quite a bit of testing. That will be for after Den is released probably. That does not mean no-frob zone is not needed. It has applications in glass cabinets and behind windows, etc.

 

Also consider player can place any item in any position inside an open chest then close it and should not be able to frob it.

 

What Ishtvan said about frobbing through glass when lid open - I 'visualize' it as 'grabbing over the rim of the chest'. That is, when you frob something right in front of you can't see your arms so who is to say what angle your arms are at? So you might be reaching round the lid? With long gorilla arms. OK, weak, but, lid open = can frob.

[Fidcal]

Working on doors now.

 

As Fidcal is paying attention I'll note some more Wiki stuff related to doors.

 

The value:

door_handle_bind_flag

should probably be added to the door section in the Wiki.

 

The Value:

frob_peer should be added to the door handle, other wise it takes 2 frobs to open door and the handle stays down. (Only on the first door frobbed though)

---------------------------

I currently have the doors and handles set-up as entities so all required values are there, just need editting on a per door basis.

 

I'm trying prefab doors but this seems buggy and I've been getting some D3 crashes when trying to reload a map.

 

I've also added a double sided door handle to cover both sides of a door.

 

That frob_peer might be the missing link I've been wanting for some time and might cure the open issue on door handles. I'll add this to my todo to check it out after Den is out of the way.

[Ishtvan]

Unfortunately the frob peer system is broken right now. It might work sometimes by chance, but I think the code needs a total rewriting.

[Fidcal]

Oops! That might break Den. I'll check through to see if it affects anything.

[Fidcal]

@Ishtvan: Yes, frob_peer is crucial to finishing Thief's Den. Can you confirm this does not affect the code on the Den branch of SVN.

[Ishtvan]

It's been broken for a long time, not a recent thing. How is it crucial to finishing Den exactly? What two things are frob-peered?

[Fidcal]

Oh well, if it's been a long time then it's probably OK. It's been in Den since at least October and I've never known it to fail. I've used it in quite a few places but without going through the map ones that come to mind are the mission-critical ones that link from objectives (including 8 items of loot and two other objectives) to a counter which then triggers the release of the front door key so the player can continue to exit the mission. Seems any frobbable item can be given a target by frob_peering it with a button. There may be other ways to do it but I didn't know of any and it's too late now.

[Ishtvan]

Oh well, if it's been a long time then it's probably OK. It's been in Den since at least October and I've never known it to fail. I've used it in quite a few places but without going through the map ones that come to mind are the mission-critical ones that link from objectives (including 8 items of loot and two other objectives) to a counter which then triggers the release of the front door key so the player can continue to exit the mission. Seems any frobbable item can be given a target by frob_peering it with a button. There may be other ways to do it but I didn't know of any and it's too late now.

Ah, okay. If the button is invisible to the player, i.e., the player can never frob the button, then it might work. Most of the problems with frob peers had to do with the player sweeping their frob focus from one frob peer to the other, but if these are hidden buttons just being used to trigger things behind the scenes, you shouldn't ever get those problems you get from sweeping your view from one frob-peer to another, so it could still work okay.

 

For future reference, you can set a completion script on an objective, so you could have a script to pop the key out when some objective is completed. We could probably do something more userfriendly than a script, like in addition to a script, set up a list of target entities to trigger once the objective is complete.

 

I'm not sure if that would do exactly what you want though, since you want it done only when a group of objectives is completed, not just a single objective. You might have to do a trick, like create a hidden objective that's enabled by all the objectives you want done, then set the completion script on that one to pop out the key. You'd also have to make sure that hidden objective checks something that is always true, so that as soon as it's enabled it succeeds. You could do a trick like have it be a distance objective between two hidden, static entities that are always within that distance of eachother. That way it's updating fairly frequently (like once a second), and as soon as it's enabled it finds the objects are within the distance, succeeds and calls its completion script. Maybe to avoid such a trick, we could make a new dummy component type that is always true and updates as soon as its objective is enabled.

[Fidcal]

Yes, that sounds similar to what greebo mentioned I think to target an entity when an objective is completed. That would complement his set objective entity.

 

I'll search through the map using a text editor but I'm fairly sure all my frob peers were hidden. I think they were used with lockboxes with lockpicking but that's removed. Might be still there but not too important.

[Fidcal]

Yes, the only other frob_peers are the two chest locks - as I recall, they highlight but frobbing them doesn't open the lid - not crucial. I also found one harmless obsolete frob_peer for my old teleport method of stopping players frobbing inside a locked chest.

[sparhawk]

It's been broken for a long time, not a recent thing. How is it crucial to finishing Den exactly? What two things are frob-peered?

 

If you can tell me what the problem is, I can use this to make my way back into the code. I'm kind of out of the loop at the moment, and this would be a good task to wrap my head around it again.

[Ishtvan]

If you can tell me what the problem is, I can use this to make my way back into the code. I'm kind of out of the loop at the moment, and this would be a good task to wrap my head around it again.

Well, the code just got really ugly and spaghettified, because I was trying to handle some asynchronous events, like when the player shifts their frob focus from one frob peer to another in one frame, one peer will say it's been unfrobbed and broadcast that, the other will say it's been frobbed and broadcast that, and they could evaluate their ::Think loops in any order. I tried to account for this, but it ended up becoming really convoluted with variables set NULL that are then required by other things and running into problems where one peer ends up in the wrong state and sticks there.

 

The fade in/fade out of the frobhilight also contributed to some problems, because as long as it's doing that, it needs to be actively updating its visuals, but when it's done it should stop updatiting visuals since that's bad for performance. However, it started erroneously thinking it was done and stopped updating visuals when it should have been fading out, due to the problems above.

 

I was just going to strip out the frob peer stuff, make sure frobbing works and then add in the frob peers again in a more organized way.