Jump to content
The Dark Mod Forums

Lanterns


grayman

Recommended Posts

I fixed issue #3128.

 

While fixing it, I saw that we have 3 models of lit/unlit lanterns:

 

moveable_lantern_oil_hand

moveable_lantern_oil_hand_colorme

moveable_lantern_oil_hand02

 

I would expect DR to offer me the following entities, allowing me to start a lamp as lit or unlit:

 

moveable_lantern_oil_hand

moveable_lantern_oil_hand_lit

moveable_lantern_oil_hand_colorme

moveable_lantern_oil_hand_colorme_lit

moveable_lantern_oil_hand02

moveable_lantern_oil_hand02_lit

 

But the following two unlit versions don't appear, and have their editor_displayFolder spawnargs commented out in their def file, along with a suggestion that they're deprecated:

 

moveable_lantern_oil_hand

moveable_lantern_oil_hand_colorme

 

Why aren't we offering all 6 versions, and if there's a reason for not offering the 2 unlit versions, why are we still offering the unlit colorme version? Offering the lit version of a lantern but deprecating the unlit version makes no sense to me.

Link to comment
Share on other sites

When I cleaned up the light entities i got rid of the mess of lit/unlit/not lit, etc...

 

There was some confusion when the lit and unlit entities were originally made which ended up with mix matched results:

 

ie:

 

Lamp_01

Lamp_01_unlit

 

Lamp_02_lit

Lamp_02

 

etc...

 

Not only was it confusing it is no longer needed.

 

Now all lights are a lit version ONLY. And there is a spawn arg to check when the author creates it 'starts unlit'

 

This cleaned up the lists ALOT (only half as many lights to weed through) and it makes them all the same. Lit unless checked unlit (which is the least required type of light for an author to place).

 

Anything that still exists in deprecated is only there so old maps won't break.

 

If those lamps still exist with an unlit version it was probably just overlooked (though I thought i had them all)... maybe they still needed tested or something, I dont recall.

 

---------

 

If they need an unlit skin please just create that so they are toggleable, but don't add unlit lights to the list.

 

if you want you could also move that one unlit version to a deprecated folder, that looks like the only one that is truly out of place. in fact i think it is the only one that existed unlit because someone modified my original lantern (never had lit/unlit skins-was before all that) and made a lit/unlit versions of it at the same time.

 

(A big part of the long list issue other than being confusing name wise, is that in the entity list you can't see the models so having lit/unlit of everyone makes a huge list to sort through)

-------

 

It appears that torches still exist as lit/unlit versions and i can't recall if that was on purpose or if it slipped through the cracks... I was seriously running out of steam by the end of that project.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I fixed issue #3128.

 

How did you fix the issue? By adding the spawnargs or fixing the scripting object? If the former, I'd like to fix that in the scripting object, too, so that mappers can't break it that easily.

 

Could you ping me in this case in a few day so that I don't forget?

 

The "lit/unlit" versions where done by me, and the confusion (which are lit/unlit) was my fault, sorry about that. Badcogg did clean up a lot, but he probably just missed something. And since we did the cleanup after release, we have to keep the entityDefs around to not break old maps.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

If they need an unlit skin please just create that so they are toggleable, but don't add unlit lights to the list.

 

Yes, I added the missing skins. While doing that, I noticed that there was a typo in 13 ornate skins that kept them from being seen in DR. I corrected the typo and now there are several new skin choices for the hand02 lantern.

 

if you want you could also move that one unlit version to a deprecated folder.

 

Done. It had two editor_displayFolder spawnargs: one that allowed it to be visible in DR, and a second one that was commented out that would have deprecated the lantern. Looks like the definition just wasn't completed. I removed the one that allowed it to be visible.

Link to comment
Share on other sites

How did you fix the issue? By adding the spawnargs or fixing the scripting object? If the former, I'd like to fix that in the scripting object, too, so that mappers can't break it that easily.

 

The script object needed no changes. In a nutshell, here's what I did:

 

1 - Provided missing skin* spawnargs where needed in tdm_moveable_lights.def. This provided part of the solution to the problem of the lantern not toggling back on.

2 - Added a "dequip_action_script" spawnarg to the lanterns so that the dequip code could actually find the script object. This provided the next part of the solution to the toggling problem.

3 - Provided missing lit skin definition in tdm_lights.skin. This provided the remainder of the solution to the toggling problem.

4 - Changed the dequip DLL code to not assume that all grabbed objects belong in inventory. This provided the solution to the grunting sound and the lantern moving around when trying to toggle it back on.

5 - Corrected a typo in 13 ornate skin definitions so they were visible in DR and could be used by mappers.

6 - Added a few missing skin definitions so that the ornate set was complete.

 

Mappers didn't break anything wrt this problem. The breakage came about because the design work was not finished.

 

Could you ping me in this case in a few day so that I don't forget?

 

Probably not. I'll be away for the holidays. Set your alarm clock.

Link to comment
Share on other sites

I'm now looking at Sotha's issue, #2624.

 

The light that's attached to a lantern is light_lantern_oil_omni.

 

Its definition includes this comment:

 

/* tels 2008-10-26: For the carriable oil lamp, does not have stims as the lamp is closed to the outside. */

 

Does Tels' comment still stand today? Or should closed lamps go out when submerged?

 

In order for a lantern to go out when underwater, but not when hit by a water arrow, the solution needs to start with this light reacting to a water stim. Its reaction can then be split into:

 

a - go out if submerged

b - stay lit if it's a water arrow stim

 

I think this differentiation can be done by using existing code that tests for the water level at an object's location.

Link to comment
Share on other sites

It wouldn't bother me either way. They're closed enough that I wouldn't seem too bothersome if they stayed lit when submerged.

Link to comment
Share on other sites

For issue #2624, when an AI drops the lantern, it goes out 15s later.

 

If the player picks it up before those 15s expire, I think it's okay to leave the lantern lit. It seems no different than taking a lit lantern off a table or shelf.

 

This also prevents this:

 

1 - Lantern drops.

2 - Player picks up lantern.

3 - Player turns lantern off.

4 - Player turns lantern on.

5 - 15s expires, turning the lantern off.

 

Which I think makes no sense.

Link to comment
Share on other sites

One final thought about lanterns.

 

Atm, if an AI drops one, it goes out 15s later, whether it's standing up or not.

 

If the player drops one, it stays on, whether it's standing up or not,

 

What I'd like to do:

 

If the player or an AI drops a lantern and it's vertical 15s later, leave it on.

 

If it's not vertical, douse it.

 

If the player throws it, douse it 1s after throwing. There's separate throw and drop code, so I can tell the difference.

Link to comment
Share on other sites

I don't really have strong feelings either way, but a few thoughts:

 

1. If the lantern is air-tight enough to survive submerging, wouldn't it survive throwing?

2. Or if impact is the issue, can the code distinguish between throwing it a few feet in front of you onto snow and dropping it two stories onto stone?

3. Candles currently don't go out when thrown, but they would seem more likely to do so IRL than lanterns.

Link to comment
Share on other sites

The script object needed no changes. In a nutshell, here's what I did:

 

1 - Provided missing skin* spawnargs where needed in tdm_moveable_lights.def. This provided part of the solution to the problem of the lantern not toggling back on.

2 - Added a "dequip_action_script" spawnarg to the lanterns so that the dequip code could actually find the script object. This provided the next part of the solution to the toggling problem.

3 - Provided missing lit skin definition in tdm_lights.skin. This provided the remainder of the solution to the toggling problem.

4 - Changed the dequip DLL code to not assume that all grabbed objects belong in inventory. This provided the solution to the grunting sound and the lantern moving around when trying to toggle it back on.

5 - Corrected a typo in 13 ornate skin definitions so they were visible in DR and could be used by mappers.

6 - Added a few missing skin definitions so that the ornate set was complete.

 

Mappers didn't break anything wrt this problem. The breakage came about because the design work was not finished.

 

 

 

Probably not. I'll be away for the holidays. Set your alarm clock.

 

What I meant was that the script should be more resilent to missing skins or script args and at least throw awarning.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

For issue #2624, when an AI drops the lantern, it goes out 15s later.

 

If the player picks it up before those 15s expire, I think it's okay to leave the lantern lit. It seems no different than taking a lit lantern off a table or shelf.

 

This also prevents this:

 

1 - Lantern drops.

2 - Player picks up lantern.

3 - Player turns lantern off.

4 - Player turns lantern on.

5 - 15s expires, turning the lantern off.

 

Which I think makes no sense.

 

Agree with that. Tho, 15s sounds quite a very very long time. I'd make it go out after a much shorter duration like 1 or 2 seconds, so it is apparent it goes out because it was dropped.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

About the lantern going out: Well, if the lantern is of any use to the player, it should stay lit based on the idea that if you want to do something and need light, you need to set the lantern down on a table. So if the lantern would go out, it would be annoying (you'd need to turn it on every 15 seconds) but it wouldn't help the "realistic feel" because unlike a candle, you can just turn the lamp on (with a candle them going out when not vertical has the nice addition that you need to hunt for a light source, so you need to be careful).With the lantern, it serves no purpose and is just annoying.

 

That it goes of when the AI drops might be an accident (torches go off when AI drops them), I don't think I have had an AI in mind with this lantern so this case wasn't specified by me (or so I think).

 

About drowning: it can't be airtight, or the oil would not burn. It is just sufficient tight to not be affected by a waterarrow, but should go out when submerged. That case never crossed my mind, probably.

 

About going out when set/dropped: it should be consistent. So ideally:

 

* if lantern is set down and upright => stays lit (even when done by AI via animation, we unfortunately don't have an animation for that)

* if lantern is dropped (collides with something with enough speed? or is not upright on settling down?) it should go out after 1 second or maybe even immidiately

*if submerged, goes out after X seconds (5? 10?)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

About going out when set/dropped: it should be consistent. So ideally:

 

* if lantern is set down and upright => stays lit (even when done by AI via animation, we unfortunately don't have an animation for that)

* if lantern is dropped (collides with something with enough speed? or is not upright on settling down?) it should go out after 1 second or maybe even immidiately

*if submerged, goes out after X seconds (5? 10?)

 

@Spring, are you okay with Tels' suggestions? I hadn't thought of the "it can't be airtight" argument, but that makes sense.

Link to comment
Share on other sites

are you okay with Tels' suggestions?

 

I'd modify them this way:

 

* if lantern is upright => stays lit, regardless of who dropped/threw it

* if lantern is on its side, it should go out after 5-10 seconds (candles are 3 seconds, and lanterns seem more robust)

* if submerged, goes out after 3 seconds

 

That way movable lanterns behave the same way as movable candles and torches; they just take longer to go out. That should make it easier for players to predict their behaviour, which is a plus.

  • Like 1
Link to comment
Share on other sites

I concur with what Springheel wrote, that sounds about right.

 

5..10 seconds is still quite long, maybe the lantern can start to sputter so the player has an indication it will go out soon. (I can help implementing this, should be doable with a light interaction table).

 

That leaves the "is thrown about" case, I'd leave this case for later implementing (e.g. if you just toss the lantern, it should sputter heavily and go out in 0.5 seconds upon impact). It is definitely a bit more difficult to implement. We currently don't handle for candles, either.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Thanks for the discussion.

 

I'll implement the changes/fixes and check them in for testing. I won't attempt any "sputtering" behavior, though. Tels can deal with that when he has time.

 

I'll implement a random douse time between 3 and 6 seconds. That should be okay.

Link to comment
Share on other sites

I agree that lanterns should take longer to go out.

 

A candle wick is pretty fragile and 'dry'.

 

An oil lamp has a pretty thick oil soaked wick. Realistically it would probably only go out if being upside doodle made the flames have a hard time getting air supply or something. Never the less for consistancies sake mod wide it seems alright for it to eventually go out.

Water would deffinately snuff out the flame, the players lantern being a bit more sophisticated and covered/whatnot is an exception that is mostly gameplay oriented. Player might need light to navigate dark water tunnels, and since we don't have flares.

 

Realistically even a torch soaked in oil would probably be quite hard to put out.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I'll implement the changes/fixes and check them in for testing.

 

Thanks for tackling this, grayman.

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

    • nbohr1more

      Trying to be productive on my down-time before Capcom releases Akuma and my son is constantly on my PC playing Street Fighter...
      · 0 replies
    • OrbWeaver

      Finally got round to publishing a tutorial on baking normal maps in Blender, since most of the ones we have are inaccessible or years out of date.
      · 2 replies
    • nbohr1more

      The FAQ wiki is almost a proper FAQ now. Probably need to spin-off a bunch of the "remedies" for playing older TDM versions into their own article.
      · 1 reply
    • nbohr1more

      Was checking out old translation packs and decided to fire up TDM 1.07. Rightful Property with sub-20 FPS areas yay! ( same areas run at 180FPS with cranked eye candy on 2.12 )
      · 4 replies
    • taffernicus

      i am so euphoric to see new FMs keep coming out and I am keen to try it out in my leisure time, then suddenly my PC is spouting a couple of S.M.A.R.T errors...
      tbf i cannot afford myself to miss my network emulator image file&progress, important ebooks, hyper-v checkpoint & hyper-v export and the precious thief & TDM gamesaves. Don't fall yourself into & lay your hands on crappy SSD
       
      · 7 replies
×
×
  • Create New...