Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

room light status #38

Closed
tomaswindsor opened this issue Apr 26, 2017 · 18 comments
Closed

room light status #38

tomaswindsor opened this issue Apr 26, 2017 · 18 comments
Assignees

Comments

@tomaswindsor
Copy link

tomaswindsor commented Apr 26, 2017

Currently, mmapper allows to specify light status for every room:

  1. lit
  2. dark
  3. undefined

But in MUME there are actually at least 4 cases:

  1. direct sun (* in prompt and causes sun-death for trolls and maluses for orcs)
  2. indirect sun (* in prompt, but no sun-death/maluses)
  3. artificial light (! in prompt)
  4. dark (o in prompt)

I suggest adding the new 2 states. Also the direct sun should be rendered somewhat differently than the other light statuses. And finally when playing troll, direct sun light statuses could automatically get mapped from exits such as ^north^ or *north* (both mean that room north has direct sun).

@nschimme
Copy link
Contributor

@tomaswindsor any thoughts on how to display this information on the MAP?

I tried using various levels of darkness but couldn't think of an easy way to differentiate between indirect sunrooms that are safe for trolls.

@nschimme
Copy link
Contributor

WIP is available at: https://github.com/nschimme/MMapper/tree/troll_exit

@tomaswindsor
Copy link
Author

I suggest following way of rendering:

  • rooms with direct sun rendered as they currently are, i.e. as light terrain
  • other rooms rendered as dark terrain, but additionally:
    • rooms with indirect sun rendered with an icon of partial sun (but not an icon with clouds, as in MUME clouds can also temporarily turn direct sunlight into indirect but we are talking about marking permanently indirect-sun-lit rooms)
    • rooms with inherent artificial light (i.e. light that cannot be covered/snuffed) with an icon of light bulb

@nschimme
Copy link
Contributor

I've create the following tables to help identify what's most useful for players.

Trolls care about avoiding sundeath:

Direct Indirect Artificial
Dark :trollface: :trollface: :trollface:
Lit ☠️ :trollface: * :trollface:

* Clouds sometimes make rooms temporarily safe

As you note, pukes only care about artificial lights:

Direct Indirect Artificial
Dark 🌑 🌔 💡
Lit 🌞 🌥 💡

I do have some thoughts though:

rooms with direct sun rendered as they currently are, i.e. as light terrain

👍

rooms with indirect sun rendered with an icon of partial sun (but not an icon with clouds, as in MUME clouds can also temporarily turn direct sunlight into indirect but we are talking about marking permanently indirect-sun-lit rooms)

My worry is that this will get ugly really quick and provide too much noisy information for the user. See the below chart with your proposal. We're going to be adding icons for 4/6 states.

Direct Indirect Artificial
Dark 🌥 💡
Lit 🌥 💡

Looking at the earlier two tables it might make more sense to only utilize a gradient of lighting for direct+dark and indirect+* rooms. @tomaswindsor Thoughts?

rooms with inherent artificial light (i.e. light that cannot be covered/snuffed) with an icon of light bulb

Great idea but we unfortunately can't reliably differentiate between artificial lights and indirect lights. I can add a lightbulb icon for artificial lights but mappers will have to manually add them. This is probably a different feature.

@nschimme
Copy link
Contributor

nschimme commented Dec 18, 2017

Ah, crap. I just realized that blindness might completely mess up this process of identifying lights from the prompt. Does anyone know what happens to the prompt if you're blind? I hope it's not o.

Extension to this question: what if there is no moon? How do I reliably know that the room is dark?

@nschimme
Copy link
Contributor

Ah, crap. I just realized that blindness might completely mess up this process of identifying lights from the prompt. Does anyone know what happens to the prompt if you're blind? I hope it's not o.

It's o according to some old logs I have. Sigh, I can't inference darkness from prompts without knowing if the character is blind.

@nschimme
Copy link
Contributor

nschimme commented Dec 19, 2017

I've had to disable automatic room darkening until we are able to detect daylight. Not to worry though, I have a working prototype that can detect sun death rooms utilizing troll/orc exits (i.e. ^north^ or *north*).

System is as follows where if there is shade it has an impact on how dark the room is. This is now useful for both pukes and trolls!

Shade No Shade
Dark 🌑 🌞
Lit 🌔 🌞

Spoiler until I get this into the master branch:
Mapper

@tomaswindsor
Copy link
Author

tomaswindsor commented Dec 19, 2017

Prompt is indeed not reliable source that can be used for automatic mapping of light status in room. Not only because of blindness spell, but also darkness spell. The troll *exits* and ^exits^ are reliable source for direct sunlight though. * in prompt only means "this room is either directly or indirectly sun-lit" (same for moon in prompt I think). Both o and ! in prompt give no relevant info at all.

Other info can come from messages given to orcs trying to cast under sun (=> directly sun-lit room) and I think there are some other messages appearing to orcs when entering and leaving directly sun-lit areas, which could be used for automatic mapping, but primarily I suggest implementing troll exit markers mapping, as that is the most useful signal we currently get.

Btw, you aren't correct in your conclusion that whities don't care about what trolls do, because whities are often trying to sun-trap the trolls or take advantage of orkish maluses...

And I repeat, if you ever plan to use any partial-sun icons, do not use the cloud ones. Clouds are temporary in MUME so such icon would be misleading.

The 3-state gradient seems also viable option on the last screenshot, at least for the forest terrain. Not sure it would be good solution for other terrains tho. Thing is when there are all 3 gradients present within the area, you can easily tell them apart, but what if they are just 2? Are they the direct or indirect sun ones? How will you tell? Hence I thought the icons would suit better. Naturally I would use the icons in the rare cases, to keep the graphics as simple as possible.

Not sure what you mean by the last shade/no shade table.

nschimme added a commit to nschimme/MMapper that referenced this issue Dec 20, 2017
We will need to do this until we have:
1) Day/night cycle detection
2) Blindness detection

This reverts a feature in MUME#38
@nschimme
Copy link
Contributor

nschimme commented Dec 20, 2017

Good point about the darkness spell and how the prompt is lossy. The only solution that I can think of is the addition of more magical light states to the prompt.

  • Directly lit (sun/moon)
  • Indirectly lit (sun/moon)
  • Magically/artificially lit
  • Dark
  • Magically/artificially dark

I thought the term shade would be easier to understand than direct vs indirect lighting. Troll sundeath basically hinges on two criteria:

  • dark room (i.e. no lighting or indirect lighting)
  • being indoor (i.e. indirect lighting)

Technically indirect isn't the proper term because there is also the 'no lighting' state. Do you think I should avoid using the term shade? I figured if a troll is sitting in shade (i.e. darkness or indirect lightning) they would be happy.

@tomaswindsor
Copy link
Author

I don't understand what you mean by "addition of states to the prompt". Prompt has clearly defined states by MUME:

  • darkness: o in prompt
  • sunlight (both direct and indirect/partial): * in prompt
  • artificial light: ! in prompt
  • moon: ) in prompt

MMapper should have these states:

  • direct sunlight (affected rooms may cause sun-death to trolls and maluses to orcs if not temporarily clouded/darkened, exits to these rooms are rendered to trolls with * and ^ markers)
  • indirect/partial sunlight (no sun-death to trolls or maluses to orcs)
  • sunlight (unknown if direct or indirect; see below in Auto-detection)
  • dark (room is never sun-lit, directly or indirectly)
  • unknown/undefined

After giving it some thought I came to conclusion that the artificial light sources shouldn't be stored in room-lit status. It's the following states:

  • inherent artificial light (rooms with inherent light, i.e. the light source object is inherent part of the room and not a separate entity, thus cannot be covered/snuffed; yet the room can be darkened by magic, etc.)
  • loads artificial light source (rooms with camps, lamps, and other objects that can be covered/snuffed)

I suggest treating these by special room flags (rendered via icon) if it is desired later. But for me it is low priority thing. Note that these light sources do not determine if the room is dark, sun-lit or indirectly-sun-lit (in the meaning of state discussed earlier), etc. It's not exclusive and thus should be handled separately.

Auto-detection:
Currently the only final state MMapper can reliably auto-detect is the direct sun-lit rooms via troll exits.
MMapper could also auto-detect that one of the direct/indirect sun-lit state is the right one, when * or ) is seen in the prompt, but the concrete state would still have to be specified later. For that we could have special meta-state in MMapper:

  • direct or indirect/partial sunlight

or just:

  • sunlight

Term shade is too ambiguous IMHO. Truly dark rooms are often meant to be shaded rooms (like dense forests, etc.).

And I wouldn't add the auto-detection via special messages (like orc casting) I spoke about earlier. These can be resolved via actions in clients much like ride/noride messages can be handled to trigger sending of a _ride or _noride MMapper mapping command, etc.

nschimme added a commit to nschimme/MMapper that referenced this issue Dec 22, 2017
Trolls and orcs are now able to map sunlit rooms using exits like \*north\*. Trolls can do this at night as well because they can detect outdoor rooms exit flags like ^south^.

Other new features:
* `_trollexit` command to toggle Troll exit mapping manually
* Dark rooms are differentiated from indirectly sunlit rooms by a gradient

This PR provides some additional features as part of MUME#38 as per discussion with @tomaswindsor
@tomaswindsor
Copy link
Author

I've also forgot to point out that whenever trolls see exit that are neither *exit* nor ^exit^, it means the room where the exit leads to is not a direct sun-lit room. So this fact could also be used for auto-mapping.

Anyway, I've noticed you implemented separate state for the sunlight type. So now we have light type and sun type. What exactly does the "light type" mean? Does it mean "some kind of sunlight" or does it also include "artificial light"? If it means only "some kind of sunlight", it could be used for auto-mapping (for trolls), i.e. based on this flag when troll sees exit without ^ or * markers, the sun-type could get set to either indirect sun (when light-type is "lit") or undefined sun (when light-type is "dark") in the sense I spoke about in the beginning of this post.

@nschimme
Copy link
Contributor

I've also forgot to point out that whenever trolls see exit that are neither exit nor ^exit^, it means the room where the exit leads to is not a direct sun-lit room. So this fact could also be used for auto-mapping.

Yes, I realized this as well. The only issue I found in testing was that doors made the inference of indirectly-lit rooms problematic. So auto-mapping only works for rooms behind exits without doors.

What exactly does the "light type" mean?

The 'Lit type' flag just talks about the room being lit through some means now. The states are just UNDEFINED, LIT, DARK and we don't have a way of differentiating for ARTIFICIAL but it could be added relatively easily.

If it means only "some kind of sunlight", it could be used for auto-mapping (for trolls), i.e. based on this flag when troll sees exit without ^ or * markers, the sun-type could get set to either indirect sun (when light-type is "lit") or undefined sun (when light-type is "dark") in the sense I spoke about in the beginning of this post.

I wanted to avoid having the 'Lit type' flag mix with the 'Sun type' flag because I would have to create an additional state then for combinations of states. This means we would need a state in 'Lit type' for LIT_DIRECT, LIT_INDIRECT, DARK as well as backwards compatibility for older maps with a flag LIT that is neither direct nor indirect.

I was concerned that I might even need to create ARTIFICIAL_DIRECT and ARTIFICIAL_INDIRECT in the future. Makes sense? @tomaswindsor

@tomaswindsor
Copy link
Author

Yes, doors can be problematic, but if I am not mistaken we always see if there is a door:

  • (north) ... door is open
  • [north] ... door is closed
  • #north# ... broken door (or specially mudlled door)

Closed doors do not reveal sun-light status of next room, but open/broken doors do I think. So just ignore the closed doors when auto-mapping.

Regarding "lit type": I am afraid we need to differentiate between artificial and sun light here to make the troll mapping reasonably effective. I currently use the LIT flag merely for direct-sun in my map (and everything else is DARK, including indirect-sun) for that info is the most useful. So I suggest using (renaming) this LIT flag for SUN and optionally adding new ARTIFICIAL_LIGHT flag (for inherent room light source). Although this artificial light flag is low priority thing for me. Sun-light is much more important.

And when I say direct/indirect I just mean direct sun -> kills trolls, indirect sun -> does not kill trolls. There is no need to consider such thing as indirect artificial light and I don't even know what you mean by that.

@nschimme nschimme self-assigned this Dec 25, 2017
nschimme added a commit to nschimme/MMapper that referenced this issue Dec 26, 2017
Trolls and orcs are now able to map sunlit rooms using exits like \*north\*. Trolls can do this at night as well because they can detect outdoor rooms exit flags like ^south^.

Other new features:
* `_trollexit` command to toggle Troll exit mapping manually
* Dark rooms are differentiated from indirectly sunlit rooms by a gradient

This PR provides some additional features as part of MUME#38 as per discussion with @tomaswindsor
@nschimme
Copy link
Contributor

I managed to get closed doors working. I'll create a separate issue for artificial lights.

@waba4mume
Copy link
Contributor

(Replying to your ingame mail here, I don't know if it's still relevant though:)

I don't think you can infer room permanent darkness from the prompt or something else equally simple (even if I removed the prompt symbol when blind/asleep): the darkness spell will make it o as well.

At least you can catch the * and mark the room as naturally lit.

@tomaswindsor
Copy link
Author

@waba4mume What would help is if MUME separated direct (causing sun-death) and indirect/clouded sun (not causing sun-death) in prompt. Any chance we could have expect feature like that from MUME someday? I mean this is so vital information for game-play that players ought to be able to tell as easily as possible... If possible separating permanently indirect sun (based on room design) and temporarily indirect sun (e.g. because of weather) would also help (can imagine e.g. "*" in prompt for direct sun, "X" in prompt for permanently indirect sun, and "x" in prompt for temporarily indirect sun).

@waba4mume
Copy link
Contributor

This is a very valid suggestion, but I can't drop what I'm working on to evaluate it further right now, sorry :/

At least, Jahara's patch lets one map the dark room easily.

@tomaswindsor
Copy link
Author

Btw, using 3 levels of darkness in rendering has one problem. If there are only 2 of the 3 states currently visible, it is hard to tell which 2 of those 3 they are. E.g. it's hard to separate sun/dark from sun/safe-sun or even from safe-sun/dark in such case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants