Jump to content
The Dark Mod Forums

Things that could be improved


Berny

Recommended Posts

For autopicking: I still contend I successfully advance a lock manually the first click-cycle the large majority of the time; so making autopick do the same would not be a strong net benefit and doesn't all the sudden ruin a mapper's complexity desires.

 

For candles, I also don't like that i have to lift it up with right mouse button, then put it out with TAB or Tilde (~) key (default was an even more inconvenient 'Enter' key), and then carefully set it down. Just seems like way too mich of a cerebral interaction than it needs to be. Not intuitive/natural, thus not immersive for me. Every time I interact with a candle, I'n reminded of how if it were real life, I'd not have to lift the candle up.

 

All in all, I'm just recommending things that will cause me to play the mod more and have more fun while doing so.

Link to comment
Share on other sites

We could have you just wave at it like nuThief. :P

 

To set candles to go out when frobbed means they can't be movables, which means you can't carry them around to light your way or light other things, which would be a loss, IMO (though individual mappers can and do use that method). The 'frob to pick up' 'use to use' mechanic is also well established in TDM, for lights, bodies, etc, so making a special button for lights isn't ideal either. The current system may not be perfect but I'm pretty content with the way it is now, but if enough people find it a problem, I'm sure mappers would start using the other kind of candles.

 

I don't swipe up as I grab something, I just position my view slightly higher, so its centering lifts it silently.

 

Yep, that's how you do it. The engine automatically centers the object if it's not dead center when you frob it, which means looking slightly above will cause it to lift into the air, looking down will cause it to bang into the surface below it.

 

For autopicking: I still contend I successfully advance a lock manually the first click-cycle the large majority of the time; so making autopick do the same would not be a strong net benefit

 

The current number of cycles might be too much, but having it succeed on the first cycle every time amounts to 'auto-win'. Having the game do skill-based things for you is something we want to avoid.

 

The blackjack *thump* sound doesn't occur until it's at the bottom of the screen or beyond.

 

Never noticed this, but it should be sorted out if so.

Link to comment
Share on other sites

To set candles to go out when frobbed means they can't be movables, which means you can't carry them around to light your way or light other things, which would be a loss, IMO (though individual mappers can and do use that method). The 'frob to pick up' 'use to use' mechanic is also well established in TDM, for lights, bodies, etc, so making a special button for lights isn't ideal either. The current system may not be perfect but I'm pretty content with the way it is now, but if enough people find it a problem, I'm sure mappers would start using the other kind of candles.

I think the main problem here is not the way it is handled in TDM in general, or in other words, how moveable light sources behave. You are completely right on that. The problem is that mappers do not think much about such thinks in advance, simple placing those items as it appears nice to them or whatever and never share any thought about how it consequences gameplay.

 

If I am playing a mission where it makes sense to keep some lights on and may want to move them to other positions so I can see more there, it is completely fine if those entities are used, but if they are just serving as another kind of extinguishable lightsource, and there is no need to use them otherwise, mappers should rethink their usage.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

and there is no need to use them otherwise, mappers should rethink their usage.

 

I would think you would want them as functional as possible by default, and restrict functionality only if there was a reason to do so. If it's important for players not to be able to move a light, for example (because you don't want them throwing it somewhere AI can't find it or something) then sure, make it static. Another reason would be if you are sympathetic to the issue of having to pick up a candle to blow it out, I suppose. That's never bothered me.

Link to comment
Share on other sites

Binding frob to right mouse and use to center mouse allows for easy blackjack/catch body as well as pick up candle and extinguish flame. I found this far more useful than the default binding of enter for use.

Link to comment
Share on other sites

We could have you just wave at it like nuThief. :P

:( Please no, lol

 

To set candles to go out when frobbed means they can't be movables, which means you can't carry them around to light your way or light other things, which would be a loss, IMO (though individual mappers can and do use that method). The 'frob to pick up' 'use to use' mechanic is also well established in TDM, for lights, bodies, etc, so making a special button for lights isn't ideal either. The current system may not be perfect but I'm pretty content with the way it is now, but if enough people find it a problem, I'm sure mappers would start using the other kind of candles.

Good point. I like the flexibility of being able to move candles. In Requiem I took a candle and placed it at a grave site, for example. For no reason other than I could, and it was symbolic of paying respects. I wouldn't really want candles glued to tables everywhere.

 

There is some charm to having to pick up candles first, but I wouldn't be sad to see a new button created (it could be unassigned by default) that allows us to put out candles or shoulder bodies with one keystroke.

 

Yep, that's how you do it. The engine automatically centers the object if it's not dead center when you frob it, which means looking slightly above will cause it to lift into the air, looking down will cause it to bang into the surface below it.

Yep, I'm aware of what's going on with the mechanic and do my best to avoid the consequences of an uncentered candle (or junk object) lift off. Accidents sometimes happen, though, and it never feels like it was my fault. Aside from creating a new button, I don't know that there's any other option. Unless... has it been tested to keep the object perfectly in place where we pick it up at? Maybe it should not re-center itself.

 

I realize part of re-centering is probably a visual cue to let us know that we've grabbed the object, but maybe there's a different (still subtle) way to signify that (e.g., a tiny/very subtle frob highlight flash at the moment of grabbing; or slightly brightened frob highlight while we are actually holding it; or? there'd be some way, imo). This could help in other situations, too. For instance: The other day, I was snagging a bunch of loot off a table (a fury of mouseclicks, which I think is fun when you can do that on big piles of coins :D). However, somehow some junk object or candle well off to the left of the pile of loot that was in the middle of my screen took focus and I accidentally grabbed that instead, which caused a clanging raucous as it re-centered on my screen. Since I was clicking like crazy, I didn't have time to see that the object had been highlighted before clicking the mouse that fateful time. A guard was nearby who became alert. I blamed the game, so I QuickLoaded. If the object didn't re-center and I knew I had grabbed the object (or if it just picked it up and dropped it where it was really quick because I was mouseclicking so fast), I would've had a better chance of not causing sound.

 

But it's probably been discussed to death behind-the-scenes and there are good reasons for how/why the system works as it currently does. I don't claim to know all the variables factoring in. Just sharing two cents (from the pile of loot I grabbed, heh).

 

The current number of cycles might be too much, but having it succeed on the first cycle every time amounts to 'auto-win'. Having the game do skill-based things for you is something we want to avoid.

Where's Sparhawk when you need him :) I think he was also wanting T1/T2 style lockpicking, and thought for sure he was going to selfishly code it in. Ha! Darn.

 

I hear what you're saying. I've just never liked manual lockpicking in any game that requires too much attention, so I have my selfish reasons, I suppose. I get bored with it and it becomes a frustrating, repetitive task I don't like after about the tenth time in any game.

 

Honestly, all that is probably needed is to allow the assigning of value "0" for "seta tdm_lp_basecount" in Darkmod.cfg to truly be zero when assigned, and then I can adjust it myself. (Or maybe it's the "seta tdm_lp_autopick_attempts" setting I need to have "0" actually act like a zero; not sure.) Instead, setting to "0" seems to put autopicking into some sort of "fail forever" mode.

 

Using "1" seems to be the lowest you can go, but I think that somehow creates a "1 + 1 = 2 cycles" event rather than the "1 cycle" (0 + 1) event I'm looking for. I've already tweaked it as follows, which is better but not perfect yet. I don't think there's any way to set these to make it be a 1 cycle event...

 

seta tdm_lp_debug_hud "0"
seta tdm_lp_pawlow "0"
seta tdm_lp_randomize "1"
seta tdm_lp_autopick_attempts "1"
seta tdm_lp_pick_timeout "10"
seta tdm_lp_sample_delay "1"
seta tdm_lp_base_count "1"

 

Another way to go might be to just make the value "1" equal "1" instead of "1+1".

 

What is "seta tdm_lp_pawlow" for, by the way? I'll check the Wiki again, but I don't think it said when I looked before.

 

Never noticed this, but it should be sorted out if so.

Yeah, it's been that way as long as I can remember and makes the blackjacking action iteself seem a little sloppy (not as tight) as it could/should, imo. I don't think my computer processing speed is the culprit either, since other sound events seem to be timed okay with the on-screen action and Thief 2014 ran quite well for me. Would be interesting to see how blackjacking feels if it's possible to sync the sound up better with the action.

 

Binding frob to right mouse and use to center mouse allows for easy blackjack/catch body as well as pick up candle and extinguish flame. I found this far more useful than the default binding of enter for use.

That would be awesome and more convenient, but I have the center mouse used for object manipulation. What key do you use for object manipulation? I tried doing what you say and also moved the 'Object Manipulation' trigger to the TAB key, but holding TAB doesn't let me manipulate objects anymore.

Edited by Darkness_Falls
Link to comment
Share on other sites

Another way to go might be to just make the value "1" equal "1" instead of "1+1".

 

You could always just make the time in between really long so you always succeed. I don't know whether that is seta tdm_lp_pick_timeout or seta tdm_lp_sample_delay.

Link to comment
Share on other sites

I'm not sure I understand that? What do you mean? I always succeed at auto-picking... it's just the game requires you to hold the mouse button down and sit through multiple click cycles before it advances to the next lockpick (two, for me). I used to have the "seta tdm_lp_pick timeout" set to "100" instead of "10," but that doesn't seem to make any difference in anything.

 

PS: I also have a habit of object-manipulation turning bowls, mugs, buckets, etc. upside down to see if something falls out, but mappers hardly ever put anything in them :.( That was one of the benefits of object manipulation, so was hoping to see it used a little more than it is. And do you suspect banners and tapestries will be cuttable with a sword someday, or cloth animation movable to the side with a frob? Maybe there are maps that have this already and I just haven't noticed.

Link to comment
Share on other sites

I also have a habit of object-manipulation turning bowls, mugs, buckets, etc. upside down to see if something falls out, but mappers hardly ever put anything in them

This does not work.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

This does not work.

Yes, it does, unless the feature was removed or never fully fleshed-out. It was purported to be a feature of object manipulation, as I recall... allowing mappers to do that, if they wish. I'm pretty sure I've seen it used a couple times before; unless that was just in the 'demo' days of the feature. Like a key or coin in a boot, and similar, where you turn it upisde down and it falls out.

 

For Tears of St. Lucia...

 

I figured the key was affixed to the pot's bottom so it wouldn't go flying when knocked down. But I thought that was more the exception, used in that unique circumstance, than the rule.

 

Edited by Darkness_Falls
Link to comment
Share on other sites

That was one of my mapping disappointments, as I toss keys in my shoes at the gym IRL, but you can't do that in game.

 

Most objects have a cube physical collision model, so if you try to put something in a vase, it just sits floating on top. So the mapper work around is to put objects beneath objects to move aside, in plants, etc.

 

It technically is possible to create an object that has a hole within like in St. Lucia, but you have to create multiple exterior objects as walls and a floor as you can't create anything concave in the modeler and collision models are limited in polygons for imported models.

 

So although you can do it, as a mapper your time is better invested in something else. That being said, most of the possible random locations of a key's appearance in my "Inn Business" requires object manipulation, and my first FM even had some basic object manipulation to advance.

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

Thanks RJFerret! I must be spacing then. An idea in a bulletpoint list somewhere either in my mind or on TDM paper that I put a visual to. Weird.

 

That explains why I couldn't put a candle inside that vase on the ledge of St. Lucia earlier tonight, though, too! lol. I guess I won't try so hard to do that in the future for other seemingly hollow objects; and will stop turning mugs, shoes and bowls, etc. upside down, hehe.

 

I'll have to check out your "Inn Business" sometime. Sounds interesting :)

Edited by Darkness_Falls
Link to comment
Share on other sites

I also think the possiblities and needs for object manipulation is a bit of a letdown in the TDM gamplay.

 

Having less ackward mapper possiblities for adding physical object manipulation like mentioned by DF (putting treasure, texts, objects for be found within models like bowls, mugs, buckets, etcetera) would be really an great improvement!

collision models are limited in polygons for imported models.

Any way this limit could be increased in the engine?

"To rush is without doubt the most important enemy of joy" ~ Thieves Saying

Link to comment
Share on other sites

That explains why I couldn't put a candle inside that vase on the ledge of St. Lucia earlier tonight, though, too! lol. I guess I won't try so hard to do that in the future for other seemingly hollow objects; and will stop turning mugs, shoes and bowls, etc. upside down, hehe.

 

You can't put things inside movables in-game, because of the engine limitation of not allowing concave collision meshes. It's a shame (I tried to put a bucket over top of a lantern the other day before remembering this limitation), but there's currently nothing we can do about it.

 

However, that doesn't stop mappers from putting things inside boots, cups, etc, does it? I could swear I've played at least one mission where you had to pick something up and turn it over for it to fall out--didn't Heart of Lone Salvation do this?

Link to comment
Share on other sites

There are several possibilities to implement this fm-wise, me thinks. One thing that comes in my mind is to let a script check the orientation of an object and spawn a moveable once it's turned upside-down.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I recall 1 mission where I saw a ring down in a boot and turned it upside down to get it out... at least I thought. Now I always check boots but... maybe I shouldn't?

 

I could swear I dumped a ring out of a boot and at the time I wondered why more mappers didn't use that device. Hmm.

Link to comment
Share on other sites

That's what I thought, Springheel; though I can't remember which mission. Seems like it was at least 2 or 3 years ago when I saw it. Yeah, I could've swore there was at least one time where it happened, but all these other comments were/are making me feel like I was dreaming..

Link to comment
Share on other sites

There could well be maps out there that do this. If I read RJF right, a mapper can choose to do it, but they need to create their own collision models and use more than one bound together to make the walls of their bucket or whatever, because any single collision model can't have a cavity in it. DR apparently makes it easy to create collision models. Then I guess you'd set your visible model to nonsolid and bind it to your cluster of collision models.

 

If it works, I'm not sure this would be too much trouble. You could make one cup shape big enough to hold a key or a coin and use it for a wide variety of visible models from buckets to cups couldn't you?

 

Any way this limit could be increased in the engine?

 

I suspect not unfortunately. The collision test code gets run a lot, and algorithms for testing anything on concave hulls tend to be completely different from and slower than those for convex hulls. And the 16-vert limit for CMs would need extending a lot too, which would be another performance and memory hog. The workaround that mappers can use is just as performance hungry of course: 4-5 CMs instead of 1 for a moveable -- but they get to turn it on only for the very few moveables where they need it, while every other moveable gets its simple model.

 

That said, would a few "hollow" prefabs be a good idea, or maybe a generic key-or-loot-sized one where you can change the visible model?

Link to comment
Share on other sites

There could well be maps out there that do this. If I read RJF right, a mapper can choose to do it, but they need to create their own collision models and use more than one bound together to make the walls of their bucket or whatever, because any single collision model can't have a cavity in it. DR apparently makes it easy to create collision models. Then I guess you'd set your visible model to nonsolid and bind it to your cluster of collision models.

 

1. What happens if the mapper mapper simply puts a movable ring inside a movable boot model?

 

2. You can bind more than one CM together? Why don't we do this by default?

Link to comment
Share on other sites

2. You can bind more than one CM together? Why don't we do this by default?

 

I'm guessing here, I haven't tried it. I don't know how easy it is to do. Each CM might have to be its own entity. But assuming it's possible, it expect it wouldn't be done by default because of the performance hit of using several CMs where you only need one.

Link to comment
Share on other sites

Actually it might not be possible to prefab :-/, another reason why we might not have them already. I decided to give it a go using the instructions on the wiki and the first problem I found is that you need to generate .cm files, so you can't do this just in a .map file alone.

Link to comment
Share on other sites

1. What happens if the mapper mapper simply puts a movable ring inside a movable boot model?

 

Entertainment happens!

 

Having two virtual objects try to occupy the same space at the same time is not quite as bad as trying to make two physical objects try to exist in the same space at the same point in time, but not helpful in the least. When the outer one is affected by physics in any way (touched, nudged, hit, shot, etc.) the inner one will get propelled apparently in a random direction at high velocity, including perhaps through the floor, depending on where it was.

 

It happens so quickly there would be no indication to the player anything was there other than the apparent object, unless the "bullet" hit something noisy along it's way nearby. If the object gets propelled into the void, you may see falling error messages in the console. When I was trying this out in my first FM, I managed to successfully find a sparkly object sent flying in this manner by carefully scouring the cavern floor in a serpentine pattern once.

 

Now this lack of evidence might not sound so entertaining after all, but you have to consider that the newbie mapper testing it was expecting to be able to reveal the loot, not have it shot off into oblivion like road runner cartoon physics.

  • Like 1

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

1. What happens if the mapper mapper simply puts a movable ring inside a movable boot model?

 

2. You can bind more than one CM together? Why don't we do this by default?

  1. As already said by RJFerret, the idTech4 physics shows itself from its best sides
  2. the problem is the bind updating. The original cm gets moved, and later one the other cms (which are just fs with collision texture) gets moved in regardence to the movement of the bind master. But for those (as they are no moveables) the collision check does not apply. The moveable hidden inside the larger one ends up inside the collision spaces and you get the result described in 1.

The collision test code gets run a lot, and algorithms for testing anything on concave hulls tend to be completely different from and slower than those for convex hulls.

As a mathematician I can only second this. Convex shapes are much easier to deal with algorithm-like then nonconvex ones. That's the reason why brushes need to be convex, too.

 

The world of convex sets is a small, brave town with lots of pinkish candy flowers growing everywhere. Everything else is pure, fucking hell. :)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Definitely seems like a worthwhile mapper challenge. First one to figure out a reasonable method for hiding rings inside boots (and makes a prefab out of it) gets a virtual cookie and the adoration of dozens.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...