With the latest version of Gender Speedup, the regression test is fixed. Good work!
I can’t think of any way parsing would use the mentioned attribute, so I don’t think it matters whether everything is reset to unmentioned before or after. Not sure the performance gain is big enough to make it worthwhile having the author do extra work to make things unmentioned, though.
Right, so the advantage of it is if you want to run two separate unmentioning loops in one turn, basically… so I guess we start by using the Inform 7 default. Which I recently discovered is documented but only in the changelog section, because Writing With Inform is a very badly disorganized “manual”. The Inform 7 documented-by-changelog default is unmentioning on each new turn and at the beginning of “look” actions (which is normally redundant).
Then we let the game writer delete that second unmentioning if they want to, which will mean that in a multi-action turn where look is the last action, mentioning things in an earlier action will cause them to be omitted from look – this is sometimes desirable and sometimes not. Likewise if the game writer wishes to write other actions which “reset” mentionedness even if they come second or third in a multiaction turn, they will have to unmention everything at the start of said actions. The issues basically only come up with multiaction turns where several actions happen between one command prompt and the next; documenting how to intervene should be sufficient.
I’m still puzzling over whether the difference makes a difference in any actual game. I haven’t gotten the regtests for Counterfeit Monkey going yet (I was actually very sick). It does enough parse-command interference that it should be a very good test. If you could possibly run the regtests, this patch to vanilla CM should be sufficient to test whether anything changes if we move the unmentioning from before parsing to after parsing where it is in SR.
diff --git a/Counterfeit Monkey.materials/Extensions/Counterfeit Monkey/Room Description Speedups.i7x b/Counterfeit Monkey.materials/Extensions/Counterfeit Monkey/Room Description Speedups.i7x
index 355d27d..24ca81c 100644
--- a/Counterfeit Monkey.materials/Extensions/Counterfeit Monkey/Room Description Speedups.i7x
+++ b/Counterfeit Monkey.materials/Extensions/Counterfeit Monkey/Room Description Speedups.i7x
@@ -12,10 +12,11 @@ The new mark every thing as unmentioned when play begins rule is listed instead
The mark every thing as unmentioned when play begins rule is not listed in any rulebook.
-Before reading a command (this is the new mark everything unmentioned rule):
- rapidly set all things not mentioned.
+[Before reading a command (this is the new mark everything unmentioned rule):
+ rapidly set all things not mentioned.]
-The new mark everything unmentioned rule is listed instead of the mark everything unmentioned rule in the before reading a command rules.
+[The new mark everything unmentioned rule is listed instead of the mark everything unmentioned rule in the before reading a command rules.]
+The mark everything unmentioned rule is not listed in the before reading a command rules.
A description-priority rule (this is the new marking rule):
@@ -83,7 +84,13 @@ The new standard surroundings rule is listed instead of the standard surrounding
[ And these from the Standard Rules ]
-The declare everything initially unmentioned rule is not listed in any rulebook.
+This is the optimized declare everything initially unmentioned rule:
+ rapidly set all things not mentioned;
+
+The declare everything initially unmentioned rule is not listed in the startup rulebook.
+
+The optimized declare everything initially unmentioned rule is listed instead of the declare everything initially unmentioned rule in the turn sequence rulebook.
+
The new declare everything unmentioned rule is listed instead of the declare everything unmentioned rule in the carry out looking rules.
On another point, I am realizing that vanilla Room Description Control uses such a horrifically inefficient method – it loops over every object three times during one description-concealing rule alone – that I’m itching to rewrite great hunks of it completely. I believe that filling the Table of Seen Things before running the concealing rules and having the concealing rules loop over that, deleting concealed things from it, makes a heck of a lot more sense. Thoughts?
Patch seems to work fine without any difference in output. It saves 51 803 cycles.
Rewriting Room Description Control sounds like fun. I’d say go for it. It will probably help if you get the tools up and running, so you don’t need me to run them for you.
Thank you so much. I think that verifies that nobody is doing anything with “mentioned” during parsing; if anyone was, Counterfeit Monkey would be.
I’m surprised that it saves cycles, actually; I would have expected it to be identical.
Getting the regression and profiling tools up and running will be my next project when I get a chance to work on this again. The more detailed instructions should do the trick – I’ll ask you if I have problems. Running them for me went above and beyond, so thank you very much for that.
The time I am able to work on these things is extremely irregular for both health and work reasons, so I tend to have short, intense bursts of programming activity when I actually get a block of free time when I’m not too sick to work on it. It’s looking like that’s ending again now, but we’ll see.
Would you mind giving me access to the Extensions repository? My GitHub name is AlexProudfoot.
I’d like access to the extensions repository so I can upload my Guide Mode extension.
-Wade
Is your GitHub id also severedhand?
I’m embarrassed to admit this, but I don’t understand the file upload dialog. Do I need my own folder before I can upload? The dialog suggests I want to change 10.1, which I don’t think I want.
Sorry if this is a silly question
Yes, it’s slightly trickier if you don’t already have an author folder. Instead of uploading, you’ll have to do “Create new file” (in the dropdown next between the “Go to file” and “Code” buttons on the front page).
Then in the “Name your file” box first time the folder name (which must match the author name in the extension itself), followed by a slash, and then finally the name of the file. This will create the folder for you.
Then you can copy the code into the main box.
Then when you click “Commit changes” on the top right, you’ll need to write a commit message. This can just be “Added X by Y”.
The 9.3 and 10.1 branches are locked so you can’t commit directly to them, so instead make a new branch. This can be named anything really.
Then click “Propose changes”. Now you’ll be in the Pull Request form. Hopefully you’ll be able to tick off all the things in the checklist (by adding an x in between the [ ] brackets.)
If you need to edit the file again before the pull request is merged, you can go to the branch you created, find the file, and click the pencil icon in the top right.
If you need to update the file after the pull request is merged, you can still click the pencil icon, but it will need to be committed to a new branch and a new pull request will have to be created.
We had locked the 9.3 and 10.1 branches because we were thinking that it might be the basis of a new extension library for 10.1, but Graham has his own. So we could consider unlocking the branches now, which would make it easier to submit things. On the other hand, that would then reduce the safety of i7/extensions…
It would be possible to make a website by which you could submit extensions, creating a pull request automatically (with the Github API). That might be something to aim for once Graham has worked out how the new public library will work in detail.
I’m working with @climbingstars to document his extensions. As I do so, I’d like to release them on the Friends of I7 Github. My git handle is notquitethere. Could I be added?