New Content - Implemented Pyramid Revamp

B

bigevildan

Member
The pyramid has changed a little bit.

The Upper Chamber, snarfblat=406, indoor
The monsters I saw here were the tomb servant, Iiti Kitty, and tomb bat, though there could be more.

The Middle Chamber, snarfblat=407, indoor
The monsters I saw here were the tomb asp, tomb rat, and tomb servant, though again, there could be more.

Florist Friar fans will notice that, despite being buried in sand, the new zones are indoor instead of underground.

A new item that drops from a noncombat in the Upper Chamber:
--------------------
7511 crumbling wooden wheel 503616859 woodenwheel.gif none q 0
# crumbling wooden wheel
--------------------

Also, tomb ratchets are no longer usable. Instead they are consumed by a choice adventure in the control room.

Control room
place.php?whichplace=pyramid&action=pyramid_control

Lower Chamber
place.php?whichplace=pyramid&action=pyramid_state[1-5]
place.php?whichplace=pyramid&action=pyramid_state1a (when Ed is unlocked)
 
D

Darzil

Developer
r14066 - Basic support I hope, with Ed dead it was hard to test. Should remove wheel and ratchet when used up. Link on tomb ratchet (and wheel) when you get them link to control room.

What it desperately needs to do is to recognise unlocks (and not show link on tomb ratchet til control room unlocked).

From those more experienced than I, which function do I add detects for the non-combats which do unlocks to ? I can then add preferences to monitor them and control area access.
 
D

Darzil

Developer
r14067 adds the unlock recognition (untested for recognising the non-combats).
Also moves quite a bit of on win quest related info from FightRequest to QuestManager.updateQuestData.
 
Theraze

Theraze

Active member
Do we have control room turn/wheel/controller/path tracking yet? That's the main bit that would seem to make planning the total number of ratchets/wheels more possible.
 
D

Darzil

Developer
Theraze said:
Do we have control room turn/wheel/controller/path tracking yet? That's the main bit that would seem to make planning the total number of ratchets/wheels more possible.
Click to expand...

No, you can't turn them when you have killed Ed, so I couldn't look at that.
 
A

Aeroplane

New member
I've got a bug. Running r14084, and I can't automate anything in the Middle Chamber. I have unlocked the lower chamber, control room, et al by manual adventuring. I can manually adventure in the Middle Chamber. Any automating gives "That area is not available."
 
D

Darzil

Developer
That's very strange. I can't replicate that. If I manually visit the pyramid, it automatically sets middleChamberUnlock to true and allows me to autoadventure there.

Edit - r14088 should mean that if you adventure in middle chamber in relay browser without visiting pyramid, middleChamberUnlock gets set to true.
 
Last edited:
Bale

Bale

Minion
Cannot automate fight with Ed

Since the pyramid revamp, when I tell it to fight 7 times in the lower chamber,

Code: 
Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

Request 1 of 7 (Pyramid: The Lower Chambers) in progress...

I suspect the URL has changed. Now, clicking on the lower chamber is place.php?whichplace=pyramid&action=pyramid_state1a
 
zarqon

zarqon

Well-known member
In case it helps, it's probably possible to set the pyramidPosition property by checking the control room image, which is always "pyramid_readoutX.gif", where X is a number from 1-5. Those images correspond to:

1 - empty/stairs
2 - rat/coin
3 - stairs/bomb
4 - coin/empty
5 - bomb/rat
 
Bale

Bale

Minion
Huh. This thread is still open. That's actually a good thing since I found a loose end.

At the moment I cannot automate the lower chamber to kill Ed. When trying to kill Ed, the Lower Chamber of the Pyramid needs to be: /place.php?whichplace=pyramid&action=pyramid_state1a
 
D

Darzil

Developer
Ugh, that's all messy.

The pyramid position image doesn't change filename when you click on a link, only when you leave and come back. I guess we can set it and then manually step it through when clicking on the wheel and ratchet options.

The url of the lower chamber constantly changes. I tried altering AdventureDatabase to allow it to handle locations with more than one "=" in the URL, but when I tried using it, it replaced the = and & with %3D and %26.

I don't think I'll have time to look at it further this weekend, any other dev can feel free.
 
D

Darzil

Developer
Pyramid state tracking added in r14319.

It needs more refinement. In particular a lot of the old PyramidRequest can be culled, maybe all of it, and the rest moved into QuestManager.

It now assumes default position of 1, which is where it starts, I couldn't see a reason to default to 0.
It moves on 1 step each time you use a wheel or ratchet (or from 5 to 1).
If you visit the container document, it parses the value from the image.
QuestManager checks for the successful bomb text, and removes the bomb, sets used, and sets position to 1. (untested)
There are no other text checks yet, as my alts have done it, and as the wiki was wrong for successful bomb text, I'm not trusting it for the rest.
When you get the bomb, you lose the coin.
 
Theraze

Theraze

Active member
Darzil said:
It now assumes default position of 1, which is where it starts, I couldn't see a reason to default to 0.
Click to expand...

0 would make sense if you wanted to detect that the wheel was still inaccessible or hadn't been parsed yet. If there's another preference being set, then we don't need that "we have no clue what it's set to when you were in vanilla KoL" value.
 
D

Darzil

Developer
Theraze said:
0 would make sense if you wanted to detect that the wheel was still inaccessible or hadn't been parsed yet. If there's another preference being set, then we don't need that "we have no clue what it's set to when you were in vanilla KoL" value.
Click to expand...
It'd also mean that automation that didn't hit the container document in a run would always fail. If not automating, you'll always hit the container document first, so it should always be right.
 
Theraze

Theraze

Active member
Doesn't using the initial wheel generate the container page? I thought I saw it starting there, but maybe that was just part of my wild clicks when manually running it. :D
 
You must log in or register to reply here.
Top