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

⚙️ Add spooky map configs #5020

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

⚙️ Add spooky map configs #5020

wants to merge 1 commit into from

Conversation

sprunk
Copy link
Member

@sprunk sprunk commented Oct 7, 2023

See #5015

@sprunk
Copy link
Member Author

sprunk commented Oct 7, 2023

I somewhat dislike these. Thornford example: top is normal, bottom is spooky. Green water is misleading (= acid) and the ground lighting looks bad (sand shouldn't be shiny, it looks like plastic). But I guess we can live with them for a day.
screen_2023-10-07_17-40-02-550
screen_2023-10-07_17-40-29-187

@GoogleFrog
Copy link
Contributor

I am not sure that this is the best spot for these.

  • It is a big shift in tone, which might not be appropriate for every way of playing (eg campaign). Making an old map work well with new lighting tech is one thing, shifting the tone so much is another.
  • The trigger is for a single day. Is this day synchronised across time zones? If this is meant for a tournament or some event, it will run into this problem.

I wouldn't be worried about these things if the mapper put it in the map themselves, as that is their choice. The old system of taking apart a map and reuploading it at least makes it clear that the new lighting is a derivative rather than the original.

Commander hats don't have these considerations because they are active for a whole month, and are pretty easy to miss.

On a technical side, shouldn't the config structure just be unchanged? The files themselves can look up the date and decide what to return.

@sprunk
Copy link
Member Author

sprunk commented Oct 11, 2023

It is a big shift in tone, which might not be appropriate for every way of playing (eg campaign). Making an old map work well with new lighting tech is one thing, shifting the tone so much is another.

Good point, it shouldn't run for singleplayer.

The trigger is for a single day. Is this day synchronised across time zones? If this is meant for a tournament or some event, it will run into this problem.

There was originally meant to be a tournament but apparently that isn't happening. So it's just for the local-timezone halloween. Perhaps it could span over the closest weekend (I made it single-day mostly because I just dislike this sort of depressing mood specifically).

I wouldn't be worried about these things if the mapper put it in the map themselves, as that is their choice. (...) The files themselves can look up the date and decide what to return.

There was the idea to also have multiple moods (default, Halloween/spooky, Christmas/winter perhaps with snow, night-time, rainy, possibly others) and I wouldn't want to cram all that logic into config files, plus there's the extra logic such as "don't apply to campaign". Or maybe a mission wants to specifically request a specific mood.

In that vein I think there should at least be some sort of gameside framework that does most of processing (similar to how there's e.g. isFFA() for startboxes, there would be isSpooky()). But that still leaves mappers (or in general, people contributing the moods) with the burden of doing some sort of work gluing up configs and dealing with these interfaces (which doesn't just require Lua basics but also demands some documentation). With folders the only skills you need for contributing is to copy-paste the generated file into the correct folder, and all known folders are just listed in the file browser. Nowadays there isn't much room for people to contribute so it would be nice to open up this kind of venue.

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

Successfully merging this pull request may close these issues.

2 participants