Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
TASBot showcases at various live events has been a major, if not the biggest (YouTube itself may be bigger), contributing factor of exposure for both 1) the hobby of TASing and 2) our site to the general public as well as to other speedrunning communities.
I find it absurd that one of our greatest exposures has been effectively prevented from having some aspect of inclusion on the site directly.
I, myself, would likely have never gotten into TASing without having seen dwangoAC and TASBot promoting both the hobby and the site.
Can such showcases exist within our current publication model? Obviously, no. The reasons have already been well explained. And I agree in that they shouldn't be housed simply mixed in amongst the normal movies/publications on the site.
But this doesn't mean we can't create a special space for these showcases (gruefood delight is not adequate). If we do create a special part of the site to house such runs/events, it could/should be CLEARLY noted on that page that these runs don't follow normal site rules and aren't judged as normal submissions are. That note should further include that these runs inclusion on the site is due to the awareness that such runs bring to the TASing community as a whole and to the extents of what TASing is capable of accomplishing.
These showcases are TASes. They are Tool Assisted Superplays. Even when human interaction is also required, the results still require TAS inputs.
Are they speedruns? Not always. Are they superplays? Typically. Do they promote TASing as a hobby? ABSOLUTELY! And they often promote our site directly.
At bare minimum, i feel we should have a highlighted wiki page that at least links to the videos of the original runs/events.
As a response to the idea that our site is solely for hosting entertaining TASes and world record TASes: if this is truly the case, then we should eliminate things like player profiles, player points, or anything else that's not strictly necessary to host entertaining TASes and world records. These live TASing showcases are no less valuable than player profiles. On the contrary, they are arguably more valuable to the site as a whole than player profiles or player points.
Adding these showcases (with the appropriate notes mentioned above) doesn't take away from the site's goals of hosting input files for world records and entertaining TASes, nor does it lessen the value of those goals and the accomplishments of the movies that we publish through our normal publication methods.
Having these showcases wouldn't suddenly make our site NOT the site that houses TASing records and entertaining TASes, nor would they suddenly become the major purpose for visiting our site.
Adding these showcases does, however, allow our site to officially recognize the promotion these TASes provide for our hobby.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Just posting to voice my support of accepting board games to Standard.
I've never liked the claim that a board game on a console/pc isn't considered a "real" video game effectively because it began its existence (or is also available) in a non-video format. It's a game being played on a video screen that uses inputs in the same ways as nearly all other video games. That alone makes it a video game in my opinion. They can also be TASed like any other game, and they often have potential for optimization (i.e. through RNG manipulation as mentioned in posts above).
Another consideration: many puzzle games (like Boxxle), that are already accepted, could easily be converted to physical materials and played on a board on a tabletop as a board game. Would those have been unacceptable if the board game version had existed first?
The one caveat i would add regarding potentially accepting board games, is that competitive board games should require at least one computer/ai opponent to be acceptable in Standard.
TASes of competitive board games that only use "human" players should need to meet community consensus for acceptance to Moons/Alternatives. Otherwise Playground could be considered as a possible landing spot before outright rejection.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
To avoid two-word names we could just pluralize and use
Standards
Alternates (or Alternatives)
Then in judgements the language "Accepted to Standards" or "Accepted to Alternates/Alternatives" could be used.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
As NYMX mentioned, I had been discussing with him that I was under the impression that exhausing all difficulty increases was no longer strictly required for looping games, so long as new content was not being introduced as the method of increasing the difficulty (i.e. speed increase as the only difficulty increase). I would have sworn that I remember seeing a disucssion about this somewhere, but for the life of me, I can't find it now. I had also mentioned that I was under the impression (again from that discussion that I can't find at the moment), that longer runs which showcased more of the harder dififculty loops would be preferred over shorter runs of fewer loops when such runs came under consideration for obsoletion. But I was still under the impression that a singular loop of a game would be sufficient if no new content were introduced thereafter. I had also shared with Spikestuff that this was my understanding of site policy for loopign games.
Here is the rule as it's currently are written:
If there's no clear ending, end after all unique content (enemies, level layouts, game mechanics, etc.) is exhausted.
-Alternately, after completing all unique content, you may end when the in-game difficulty (enemy speed, AI, etc.) stops increasing.
The way I read this; the first line states that exhausting unique content is the minimial end point for looping games. The second line allows for (but does not require) continuing farther onward through all difficulty increases.
These are the basis for my understanding of the policy on looping games, and also the reasons I believe that one loop may be sufficient for a game like this one.
FWIW, I will be performing a formal review of this run as-is. I'll update this post with that review once I complete that review.REVIEW:
I was able to sync the run.
Optimization looks solid; I wasn't easily able to find any improvements.
Completely theoretical improvements:
1) Forest Stage - IF the vine swings could be better manipulated, this stage may be improvable.
2) River Stage - There are two types of crocodiles (standard and rogue). Multiple standard crocs can be on-screen at one time with their spawns being separated by 64 frames on a count-down timer stored at RAM address 0x64. Only one rogue croc will be on-screen at any one time. Having a rogue croc on-screen prevents standard ones from spawning even if the timer hits zero. So IF it were possible prevent rogue crocs from spawing and yield only groups of standard crocs, it would be possible to clear the necessary 14 crocodiles faster. I was not able to readily deduce how the game determines when to spawn a rogue instead of standard. (I tried using trace-logger to no avail).
3) Boulder Field - There are a couple large boulders that Winslinator ducks underneath instead of jumping over. Ducking stops horizontal leftward movement slightly delaying progress. While it is possible to jump over the first of these two large boulders (pressing UP while jumping in this stage increases Dashly's jump height slightly) and maintain forward momentum, I was not able to jump the second without manually delaying movement anyway. So waiting to duck for this second large boulder effectively eliminated the savings made by high-jumping the first. I didn't dig in to see if the boulder sequence is predetermined or if it's RNG, but IIRC it is RNG based in other ports of the game. So IF it's also RNG based in this version, it may be possible to manipulate boulders in such a way that could yield a sequence where no ducking was necessary; this would save a few frames.
Thoughts on difficulty:
1) The game's manual allows for staring on two different difficulties; this run uses the harder. The manual also mentions that the difficulty increases in subsequent loops after rescuing Lady P, but does not specifically describe HOW the difficulty increases.
2) In other ports, a monkey is added to the Forest stage. The monkey climbs on vines and can knock Dashly off a vine, thus making that stage more difficult. This port does not contain the monkey.
3) The gators do increase speed on the loop immediately following this run, but their speed doesn't seem to increase further with subsequent loops. (The loop number is stored in RAM address 0x0B, and selecting the harder difficulty at the start simply increases this from 0 to 1, effectively making this run's starting loop what would normally be the second loop if starting on easiest difficulty).
4) In the Boulder stage, the boulders do seem to bounce slightly different heights when poking different values into the adress that holds the Loop #, but this is mitigated by holding UP on the jumps. The sequence of boulders was otherwise unchanged, and thus is either pre-programmed or based on RNG values from earlier in the game.
5) I did not note any differences in the Cannibal stage regardless of what values I was poking into the Loop # address.
SO....thoughts on difficulty while also considering my comments above this review: I believe 1 loop of this game is sufficient to satisfy the rule requirement of exhausting new content. That being said, it would require only one more loop of play to also exhaust difficulty increases of this otherwise never-ending game (the loop counter resets to 0 after 255). Therefore, while I feel this submission is acceptable as-is, I'd strongly encourage Winslinator to revisit this run and complete the 2nd loop so as to also exhaust difficulty increases.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
For now, I only have a comment on number 3:
I don't think we should accept SRAM that isn't obtainable through normal/TAS play (i.e. via hex editing in max stats that wouldn't be obtainable otherwise).
While I understand the argument (and potential time benefit to the author) of being able to manually create an SRAM file that would be possible to achieve through normal play, I personally feel that we should still restrict SRAM anchored movies to provide verification movies.
I realize this may require more work from the author's position, but it would simplify judging. If a judge has the verification movie inputs, it's more readily determinable that the utilized SRAM is legitimate. If, however, verification inputs are not provided/unknown, the judge would then be tasked with first verifying the legitimacy of the SRAM before consideration of the submission in question could even begin.
Much like Samsara, I tend to lean toward a wider acceptance of runs for publication, but there does have to be a line somewhere.
Hypothetical example; if i hex edit a savegame file for a DOS game to provide an longer than legitimately achievable invulnerability time, I could breeze through a game much faster than without that ability.
So if i provide a run that has that savegame situation without any verification inputs, the judge would first have to determine if that ability is achievable normally before they can even start judging the run submitted.
Even if someone provides a manually created SRAM while claiming it's indeed possible to yield that save information via real play, it still falls to the judge to verify that claim if there is no verification movie.
TL:DR In my opinion, SRAM should only be accepted with verification movies provided that create said SRAM state. The impetus for proving legit SRAM should be on the author, not on the judges.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
As noted in the submission text, I've already had a chance to review this run and could not find any improvements in routing or optimization. Movment controls are rather limited and many platforming actions that are common in modern games are not an option here: i.e. jumping to/from ladders, jumping across screen borders, changing direction/speed mid-jump.
In the run, there are a few frame perfect movements/jumps that would be rather difficult for a human, but I won't say impossible for a human. The run uses death to save time; and when death warping, NYMX does a good job of utilizing death by falling off the screen as opposed to falling onto a platform. Falling from the screen results in less time required to regain control with the next life compared to dying by a fall onto a platform.
Frankly, this is an impressive game from the standpoint of it being a game that was published in a magazine and meant to be typed into the C64 by the reader themselves. It's a solid run, and appears acceptable to me.
The ROM/disk image used in this run is a disk image containing the programs from Compute! Gazette magazine Issue 79 (January 1990). Interesting side note on that particular issue: there is an article on Neural Networks, Artificial Intelligence, and the future of computing.
EDIT: For anyone interested, here's the pages of the magazine with the game's code. (Sorry about the big images, but I figured it'd be harder to read if I shurnk them any.)
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
feos wrote:
Being restricted to replay files would result in hacking around this restriction by providing dummy files, but we'd also have to do something about movie length to make it present some actual info about the duration of the event in question. That sounds even more hacky.
(emphasis mine)
Regarding length of run: If a dummy movie file is going to be present anyway, we could make it from all blank inputs that was as many frames long as needed to show the appropriate time frame.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
I support finding a way to do this. I find the idea of a separate publication type/area of site (as described in the "future" section of Samsara's post) to be an ideal goal.
We need to find a way to officially recognize/publish these showcase runs that otherwise can't be processed through our standard judging process due to the need for extra hardware or external data only possible at such a live event.
In my opinion, TASing, at its core, is effectively answering the question, "What can be done in/to this game with a sequence of perfectly timed button presses?" While we typically answer this question along the lines of "beating games really fast, often in entertaining ways," these showcases are simply offering different answers to that same question.
Unfortunately, some of these showcases use unscripted data from an outside source (live chat, or even human input like Savestate's in the SGDQ 2022 example), which isn't information we can "verify" in an input file. HOWEVER, the results that are seen on the screen at the event are still the result of button presses processed through the controller ports.
These runs stand therefore as valid answers (albeit very complex ones) to the question of "What can be done in/to this game with a sequence of perfectly timed button presses?". We need to officially celebrate them by some means of inclusion on the site (beyond gruefood).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
To put my opinion as concisely as possible:
I like the idea of allowing in-game codes into standard if they ADD to gameplay, but not if they take away from gameplay.
I think external codes should always be limited to Moons, with one hypothetical exception:
In the event that there is a game out there (or will be in the future) that has a programming bug present which prevents a normal win condition from being achieved; I'm fine with an external code being used to bypass the bug and allow succesful completion the game. I think that only this one situation should be eligible for standard. Ideally, the external code here would only allow bypassing the bug and not enable other features that allow for skipping other gameplay.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
feos wrote:
I feel if we call the branch label "minimum jumps" it would be neater and more informative at the same time, while still being accurate. Sorry it took me so long to raise this question, but what does everyone think?
Objectively, "Minimum A Presses" and "Minimum Jumps" are not guaranteed to always be equivalent (though they may be in this case, I haven't looked that closely at the input to confirm).
Further, a "Minimum A Frames" run could be another potential variant between two runs with otherwise equal number of A button presses. Or, in theory, it may be possible to have a run with a greater total number of A button presses yet presenting a lower total number of frames with A being pressed.
My opinion on this submission/publicaiton: I agree that "Minimum Jumps" is more readily understandable as what to expect when watching this run.
As this run currently is BOTH the known "Minimum A Presses" and "Minimum Jumps", either branch name would be valid. I'm going to make an assumption (because I'm too lazy to go count A frames) that this submission also likely qualifies as "Minimum A Frames."
If someone someday manages to make an acceptable TAS where at least one of the 3 minimums is present, but not all 3; we may need to consider rebranching as appropriate.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
MESHUGGAH wrote:
Also I had no idea that an A2600 TAS can sync on both NTSC and PAL ROM.
This may not be the case for all games, but it does work with this one. The frames are just longer in PAL mode. I've run into something similar before; I think it was with a C64 game (EDIT: If I remember correctly, it was Monty on the Run for C64. Movement synced, but RNG didn't.). It would be interesting to try this on other games as well.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
In reviewing this run, I was able to implement some movement improvements scattered through the run.
Stage 1 (16 Frames Saved): Started moving earlier and managed to get the 10th hit on the skeleton a bit earlier to move to stage two.
Stage 2 (0 Frames Saved): Different attack pattern to avoid the axe. Otherwise no frames difference.
Stage 3 (14 Frames Saved): Better movement (more diagonals) to exit the maze faster.
Stage 4 (45 Frames Saved): Better movement (more diagonals) to exit the maze faster.
Stage 5 (2 Frames Lost): Unfortunately I lost two frames here and can't figure out why. Even just copying the original requires adding two frames. The player character must move up to y-position=15 while touching the freed boy to end the game.
Total improvement = 73 Frames
Here is an updated .bk2.And a temp encode.
https://youtu.be/kZIQXhatvHo
Once I have coauthorship/editing rights on the submission, I'll change the main encode to this one.
Here's a side-by-side GIF comparison of the run before and after improvements.
I also discovered a minor ROM issue. Checking the ROM used for this run using goodtools yields "Ghost Manor (1983) (Xonox) [o1].a26" The [o1] indicates that the ROM is an overdump ROM. For those who may not know, overdump ROMs have extra unused data beyond the actual game data in the ROM file itself. This extra data is meaningless and doesn't impact the game in any way.
Unfortunately, goodtools does not have a [!] marked ROM for this game indicating a known proper dump of the game. There is a ROM in the goodtools database that's not labeled with any notations "Ghost Manor (1983) (Xonox).a26" but this ROM only seems to contain the first stage of the game (it resets to the beginning once the spears are collected).
There is a PAL version that has the [!] known good dump indicator; interestingly the inputs from this run sync perfectly on the PAL version but the overall play is slower due to the framerate differences.
Due to these issues with the ROM, I think the overdump version is likely the best to use for this game, as it allows a full game NTSC run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
I think it's great you took the idea to the next level by showing off as many animations as possible while doing it in actual gameplay from standard starting positions.
Too bad there's no way to show all animations in a single standard game.
While this may not be publishable in Standard; if it doesn't qualify for Moon class, I think it falls solidly in line with the Playground.
For the judge: On the note of playground... would my original run linked in this submission now also qualify for Playground?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
A few ideas:
"Unacceptable"
"Currently unacceptable"
"Unpublishable"
"Unpublished"
"Currently Unpublished"
"Withheld"
"Currently denied"
"Denied" (though without "Currently" it's not much different than rejected.)
"Vetoed"
"Suppressed" (i kinda like this one. It may be suppressed now, but could come back in the future)
"Inadmissable"
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Well done!
Throwing out a personal opinion here:
IfWhen this is accepted, I feel it should be accepted alongside the current run as a different branch (as opposed to obsoleting the current run), because the bat presence/manipulation introduces significantly different gameplay possibilities which yield a completely new approach the run that is simply unavailable at the easiest difficulty. The differences result in completely different routes and item use. If this is done, the current publication would likely need its publication ammended to include "easy difficulty" or something similar as its branch.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
While it would still be my personal preference, if doing so would create a greater problem, then the alphabetizing doesn't need changed.
I only suggested it in the first place due to that method being the standardized way for alpabetizing titles in English (which, while others languages are present, is our site's primary language).
The exact order of the lists isn't critical either way; because, as was already mentioned, we also have search functions to find things.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
When it comes to the listing of games in our system, all games that start with the word "The" are currently placed in the "T" section of alphabetical lists. For example, in the NES tab of the Games page, there are currently 48 entries that start with the word "The." These are all in the "T" section.
I think we should we consider renaming these game entries by having "The" moved to the end of the game entry (i.e. changing The Goonies into Goonies, The) so that these games show up in the alphabetical list based on the first main word in the title instead of the word "The"? This is a standard way of alphabetizing titles in various other areas of life--one example being bibliographic notation.
Using The Goonies as an example, instead of being listed after The Flintstones: The Surprise at Dinosaur Peak!, making this change would instead move it to being after Golgo 13: Top Secret Episode.
Here is an example of such alphabatizing using NES games from Wikipedia.
EDIT: If there's a way to have the games alphabatized the way I'm describing, but still displayed with "The" at the beginning of the name, that would also be fine. I just feel the alphabitizing needs to happen on the next word instead of "The."
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
I noticed that the recent run of Anarchy was published as (Europe) C64 instead of just C64 like all the other current publications. I'm assuming it was given this label because it's a PAL run. However, some other C64 publications also use PAL mode but aren't labeled this way.
So, it made me wonder which of the following methods should be the appropriate way of labeling C64 runs?
1) Labeled as (Europe), (USA), etc.
2) Labeled as (NTSC), (PAL)
3) Not Labeled with anything other than just the system C64 (like all other current runs besides Anarchy).
The reason I ask is due to how the site handles games that run equally well in both NTSC and PAL modes:
We currently (and appropriately so, in my opinion) accept a run to be made in either mode--regardless of where the game was made/released--as long as it works, without introducing glitches. Runs are accepted this way because the real software/cartridges of such games will work on the real hardware of either region--unlike consoles (NES, Genesis, etc.) where it's typically not possible to play cartridge releases from one region on the opposite region system without physically modifying the system.
Because of this policy, I contend that (if a label is even necessary in the frist place) option 2 above (PAL/NTSC) would be better than using location notation (USA/Europe).
I am curious to hear other's thougts on such labeling.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Masterjun wrote:
I count 948 moves in this submission. Heh, my TAS attempt finished the game in 881 moves.
But I want to see someone manage to manipulate RNG enough to get the minimum, 519 moves.
I've been messing around with the game a bit (mostly out of curiosity). While RNG can easily be manipulated to get a new tile spawn WHERE you want it, I have yet to determine exactly how the game decides WHAT value to give to the newly spawned tile. Thus far, when a 4 spawns appears to be based more on the number of moves than it does which moves are taken or when they are performed. For example, waiting a frame or two will change where a new tile spawns, but it will not change what value that newly spawned tile has. Even delaying moves earlier than the one prior to the new spawn doesn't seem to change the value of the tile; at least in my testing. Unfortunately, I've yet to find a simple move counter of any type in RAM that determines 4 spawns.
I tried to look into the source code to see how new tiles were determined, but I'm not a programmer and couldn't figure it out. Perhaps someone with more coding experience can.
Having a tracelogger would likely help in determining how the game decides on 4's or 2's.
For what it's worth, freezing the 4-byte value at RAM address 0x109 with a value of 0x56E509FE will always produce a 4 on the next spawned tile. If any one of the 4 bytes isn't frozen, new spawns may have a 2. Having this value frozen at the beginning of the game does not yield two 4s. One of the original spawned tiles will still be a 2.
Regarding other RAM addresses (in case anyone decides to investigate things further), the value of the individual squares on the board are stored in 2-byte RAM addresses from 0x0A54 through 0x0A72. The sequence of addresses goes from 0x0A54 in the upper left corner, then downward in the column, then top down in the next column, and so forth with 0x0A72 in the bottom right corner.
TL:DR Unfortunately, I don't forsee a way to manipulate enough newly spawned tiles to be a value of 4 in order to make that 519-minimum-move run even possible.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Here is an updated .bk2 for this run. Would someone with the power, please update the submission file.
Overall 1235 frames were saved over the original run. These resulted from a combination of more efficient movement, different routes, and variations in RNG manipulation. I'll update the preview video and submission notes with slightly more detailed info as soon as I'm able. Updated.
This submission is now ready for judging again.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
feos wrote:
Thoughts about optimality.
If submissions that fail to beat a published movie are just sent to playground, there's zero incentive to make better movies, and it can be flooded with low effort stuff that's basically the same. Even tho I don't see the need for obsoletion in playground, I think we should only send there movies that are better than whatever already exists in playground. If it's slower than that or a published movie of the same goal, it doesn't allow us to showcase any niche goals better, and it's better to just reject.
I mostly agree with this. There's no reason to have 10 different people with Playground runs of the same category doing roughly the same thing. I'd rather see the Playground be more a variety of unique content for a given game than soething that ammounts to little more than a congested leaderboard of similar runs having slightly different times.
However, if two runs that would otherwise be in the same niche category for a game manage to achieve that goal using significantly differing methods (or the slower of the two contains an interesting techinique that isn't seen in other runs in the Playground), it may be wise to keep both runs in order to archive the differing/interesting techniques.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Unfortunately this probably depends on the specific game and its community more than a generality.
I would expect that death skips would probably more favorably looked upon here than in general game commnuities or their associated speedrun commnuities. But that doesn't mean that those communities would be against death skips. It's just going to be a subjective situation for each individual game.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Yes. I had read the OP.
I guess i just misunderstood how things would be curated in the Playground. If anyone can set a submission status to be a Playground run, how is the list curated?
Without some means of "rejecting" or removing runs that shouldn't be present, the list has no effective limits.
I'm just trying to understand how this will be handled.
And if I've missed something in the various pages of posts or discord discussions that answered this already, please forgive my lack of memory for everything that has occurred in these discussions and just point me to the answer instead of questioning whether or not I've been paying attention simply because i misunderstood one aspect of the entire concept.
I also discovered a minor ROM issue. Checking the ROM used for this run using goodtools yields "Ghost Manor (1983) (Xonox) [o1].a26" The [o1] indicates that the ROM is an overdump ROM. For those who may not know, overdump ROMs have extra unused data beyond the actual game data in the ROM file itself. This extra data is meaningless and doesn't impact the game in any way.
Unfortunately, goodtools does not have a [!] marked ROM for this game indicating a known proper dump of the game. There is a ROM in the goodtools database that's not labeled with any notations "Ghost Manor (1983) (Xonox).a26" but this ROM only seems to contain the first stage of the game (it resets to the beginning once the spears are collected).
There is a PAL version that has the [!] known good dump indicator; interestingly the inputs from this run sync perfectly on the PAL version but the overall play is slower due to the framerate differences.
Due to these issues with the ROM, I think the overdump version is likely the best to use for this game, as it allows a full game NTSC run.