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

Fix: correct roomtype of oracle-1 #52

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

Conversation

RojjaCebolla
Copy link
Contributor

This is to display delphi in blue, not white, and may have other small side effects (for the better).

This is to display delphi in blue, not white, and may have other small side effects (for the better).
@copperwater
Copy link
Owner

Thanks for catching this, but what side effects do you mean?

@entrez
Copy link
Contributor

entrez commented Oct 1, 2021

But the subroom with the oracle is already "delphi"/DELPHI, not sure if the larger enclosing room should also have that roomtype. The current setup is the way it is in vanilla I think.

des.room({ type = "delphi", lit = 1, x=4,y=3, w=3,h=3, contents = function()

fixuporacle(bones.c) puts the oracle into the DELPHI room when saving bones (if she has been repositioned somehow) so it seems like having two rooms with DELPHI type could mess that up... I guess if the subroom is exactly centered in the large room it may not make a difference, but it seems a little dangerous to me.

The "welcome to Delphi" message would also be given as soon as the hero entered the larger room, rather than upon entering the subroom that actually contains the oracle.

@RojjaCebolla
Copy link
Contributor Author

Thanks for catching this, but what side effects do you mean?

Ah, was just handwaving at the possibility of other effects in your codebase, effects that would work differently depending on whether it was oracle1 or oracle2/3

@RojjaCebolla
Copy link
Contributor Author

The "welcome to Delphi" message would also be given as soon as the hero entered the larger room, rather than upon entering the subroom that actually contains the oracle.

seems like that's not true? maybe you have to be in sight of the oracle? here's results on this branch:
image
yay it's blue 😁

@entrez
Copy link
Contributor

entrez commented Oct 1, 2021

Oh yeah, you're right, the Oracle must be inside the current room for the message to be given, and I guess being inside a subroom of the current room doesn't count.

It feels like the subroom should be blue already, since its type is already DELPHI. This seems to be not working because the the coloration depends on the walls having a distinct roomno, but the walls of the subroom are SHARED, so getroomtype doesn't work. Did the colored walls patch ever work for the vanilla oracle subroom?

@copperwater
Copy link
Owner

Not sure the colored walls patch ever colored Delphi (it's not in my original commit for it). Yeah, if the oracle is in a subroom, that'd be wrong to have the outer room be delphi type, you don't want any odd behavior even if her saying "welcome" is suppressed.

Proper behavior is, I guess, making the subroom in oracle-1 render as blue, not the outer room.

@RojjaCebolla
Copy link
Contributor Author

RojjaCebolla commented Oct 2, 2021

Another alternative: The inner room's walls could just be lua'd into place as part of the main room instead of being a subroom. Then oracle 1, 2, and 3 would all be the same size.

But at this point it sounds like you want to implement your own solution? Just let me know if there's an edit you're waiting on me to do, so that I can do that edit.

@copperwater
Copy link
Owner

I can't think of a solution to make the inner wall blue without the outer one, so if this accomplishes making the outer wall blue but not the inner and it doesn't mess with the oracle greeting the hero, then it's fine as is. I'll probably merge it after tnnt work.

@RojjaCebolla
Copy link
Contributor Author

update: ring of walls approach not so great.
image

               -- Make a square of walls around the Oracle, 2 spaces out (same shape as old subroom)
               local ring = selection.new()
               ring = selection.rect(3,2,7,6)
               -- Remove one wall near the Oracle so she is reachable
               notwall = {  {4,2},{5,2},{6,2},
                            {3,3},{3,4},{3,5},
                            {7,3},{7,4},{7,5},
                            {4,6},{5,6},{6,6} }
               shuffle(notwall)
               ring:set(notwall[1][1], notwall[1][2], 0)
               des.terrain({ selection=ring, typ="-" })

                -- The 4 fountains are adjacent to the Oracle
               des.feature("fountain", 5, 3);
               des.feature("fountain", 4, 4);
               des.feature("fountain", 6, 4);
               des.feature("fountain", 5, 5);
                -- and in the center:
                des.monster("Oracle", 5, 4)

@copperwater
Copy link
Owner

Further findings:

  1. The approach in this PR of changing the larger room to type DELPHI as well misplaces a dislocated Oracle when saving and loading bones, as entrez pointed out. She winds up off-center.
  2. The "ring of walls" approach, while I think it could fix the corner issue by placing an empty doorway instead of leaving it a floor space, makes the Oracle greet you when stepping into the large room - this is fine in oracle-2 and oracle-3, where she's not behind interior walls, but it doesn't make sense in a room where you probably don't have a direct line of sight to her first thing.

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.

3 participants