I solved it by taking one of the mazes and instead of having it be the class "room," I call it something like "prisonMazeRoom."

I have fixed this twice and failed to write up the solution.

This is making me very angry because it's happening a third time.

That's because I'm storing the signatures.

[quote="Ice Cream Jonsey" post_id=130236 time=1659593817 user_id=3]
I appreciate Paul's advice. ... I have never really talked about source control... of all the topics lately this is the one he is the most right about.
[/quote]
I speak from experience. Hard won, expensive experience. I say "expensive" because it has required me to redo work or validate work in order to determine what is correct, or least incorrect, and I had to expend the one thing I have, that is my post precious, most limited and irreplaceable -possession I own: my time.

I don't want to say the wrong thing! I appreciate Paul's advice. He is not aware that I averaged about 2,000 commits a year for work from 2014 to 2021. And that's ok. I like the posts and the content and I have never really talked about source control on this forum. In fact, of all the topics lately this is the one he is the most right about.

[quote=Flack post_id=130209 time=1659446109 user_id=840]
That one lawyer guy on Seinfeld.
[/quote]

Johnnie Cochran lol

"If you don't commit, you must acquit." -That one lawyer guy on Seinfeld.

Yeah, make sure to check in your code, ICJ.

I just realized I've made a mixed metaphor. You can use git commit with any work directory that has been git initialized, even if you don't have a repository. You only use a repository - which can be Github, Gitlab, or your own private system, to push all comnits.

[quote="Ice Cream Jonsey" post_id=130140 time=1659245695 user_id=3]
His heart is in the right place!

Commander, I am using GitHub.com to host, so a lot of the merge and diff items you mentioned can be done through that.
[/quote]
I use GitHub myself, the thing I discovered is, commits are [i]cheap[/i] and should be done frequently. I have come to the conclusion that a commit should be done every time an application is rebuilt, provided it compiles cleanly. So for a Hugo app, if the compilation produces no errors, a quick commit is warranted. The advantage here is that at any time you can always rollback to any previous known-good compile.

Or, you can do the commit if the program starts. But it has to be regularly; I'd suggest for testing the program by creating a batch script that does a commit, then invokes the run-time system for the app. All it takes is to be complacent. To make exceptions, e.g. "I'm too tired", "It's only one line", "It was only a punctuation change," will mean it gets forgotten, or eventually dropped, losing a valuable debugging aid and source management tool. It's like wearing seat belts; unless it's done every time, it will get forgotten. But do it consistently, every time, and it becomes automatic. Or make it automatic by including a commit command in the action of running the app, and it is forgotten about, you never have to think about it, you've completely eliminated the possibility of failing to commit when you've made a large change. You also are able to make the commit comment a short explanation of why you made this commit, preserving the thought while it's fresh in your mind.

His heart is in the right place!

Commander, I am using GitHub.com to host, so a lot of the merge and diff items you mentioned can be done through that.

ICJ, have you considered paying Tdarcos for his Hugo consulting services?

[quote="Ice Cream Jonsey" post_id=130124 time=1659204878 user_id=3]
I did not hit a limit. I have an issue with my monsters again. I solved this problem in the past and it is back. ARGH.
[/quote]
I felt there was more to this story than you were letting on. Now, the description of program statistics indicated you were only using about 900 total objects (I am not sure if Hugo counts a class as an object.) Since literally everything in the game is an object, whether it's a room, a prop, an NPC, or (I believe) a door between two rooms.
Now, about your "issue" (which I will refer to as "misbehavior") with the monsters: there is the possibility of any of the following:
* Per-turn code used to run the monsters, affect rooms, and/or process props has bugs and/or side effects.
* You have errors in the specification section that describes vocabulary
* The run-time system has a bug in NPC handling. (These can be brutal to find.)

I'll offer some suggestions.[list=1]
[*] Dike out everything but the absolute minimum necessary to operate the monster, and see if the misbehavior keeps occurring. If not, add features until it does. Inconsistent errors like this can be a son-of-a-bitch to find.
[*] If you started with Roody's game template, move everything necessary to operate the monster to a fresh copy, and see if the unpredictable bug keeps occurring.
[*] Since you're having trouble (if you were doing this) clone the repository you store the application code to a prior release where the undesired behavior does not occur into a separate directory.
[*]If you're not already doing so, remember to do a commit [i]every single time[/i] you do a change in how it works and compiles and at least starts up without error, and do frequent pushes. I discovered, painfully, what happens if you don't, even with the ability to roll back to a prior edition, then have to use Winmerge to see where the changes were.
[*] Get Winmerge; it is a fantastic open source visual diff utility. It can compare two directories (such as a repo clone) against the working directory, and tell you which files are missing, new, or changed. Select a file, and it will show you how the different versions in each directory differ from each other. I can't even count how many times Winmerge has saved my bacon when I screwed up (which would have been less severe if I had done regular commits. And it still would have been useful.)
[*] Use Winmerge to look at the two directories to show differences.
[/list]

I hope this helps, and if I've mentioned things you knew were obvious, well, I don't know what you know, so I make no presumptions about your experience.
Good luck.

I did not hit a limit. I have an issue with my monsters again. I solved this problem in the past and it is back. ARGH.

class room
{
	type room
	is static, light, open
}

===============================================================================
HUGO COMPILER v3.1.03 STATISTICS FOR:  cyberganked.hug
07/30/22 00:13:10
===============================================================================
Compiled 91833 lines in 70 file(s)

Objects:      901 (maximum  2048)      Routines:   819 (maximum  2048)
Attributes:    77 (maximum   128)      Events:      35 (maximum   256)
Properties:   190 (maximum   254)      Labels:      15 (maximum   256)
Aliases:       61 (maximum   256)      Globals:    140 (maximum   240)
Constants:    180 (maximum   256)      Arrays:     212 (maximum   512)

Words in dictionary:  3449    Special words:    30    Verbs:   126

Object file:  cyberganked.hex (833769 bytes)

Elapsed compile time:  2 seconds
===============================================================================

I am in a situation where I have a bunch of .hug files that I include, and these files have somewhere like 30-100 "rooms" in them. The definition of a room is simply:

[code]
class room
{
type room
is static, light, open
}
[/code]

Well, if I try to move the player to District_13_1, it works.
If I try to move them to District_13_2, I have no idea what object we are in. Nothing "beyond" that works, either.

Crap crap crap. I don't know what limit I am up against. This is what I get with a verbose compile:

[code]
===============================================================================
HUGO COMPILER v3.1.03 STATISTICS FOR: cyberganked.hug
07/30/22 00:13:10
===============================================================================
Compiled 91833 lines in 70 file(s)

Objects: 901 (maximum 2048) Routines: 819 (maximum 2048)
Attributes: 77 (maximum 128) Events: 35 (maximum 256)
Properties: 190 (maximum 254) Labels: 15 (maximum 256)
Aliases: 61 (maximum 256) Globals: 140 (maximum 240)
Constants: 180 (maximum 256) Arrays: 212 (maximum 512)

Words in dictionary: 3449 Special words: 30 Verbs: 126

Object file: cyberganked.hex (833769 bytes)

Elapsed compile time: 2 seconds
===============================================================================
[/code]

My list of includes at the end of the main .hug file looks like this:

#include "nations.hug"
#include "characters.hug"
#include "monsters.hug"
#include "maze_riot01.hug"
#include "maze_riot02.hug"
#include "maze_alleyway01.hug"
#include "maze_backalley01.hug"
#include "maze_warehouse01.hug"
#include "maze_prison01.hug"
#include "maze_prison02.hug"
#include "maze_cotd01.hug"
#include "maze_cotd02.hug"
#include "maze_district01.hug"
#include "maze_cotd03.hug"
#include "maze_office01.hug"

And somewhere in "maze_ district01.hug" is where I go from being able to move the player to a room, to not being able to do it.
Also! If I move "maze_district01.hug" up in the list, like after monsters, then it DOES let me move to the bad room.
So it's like it's creating some sort of code stack and I am exceeding it, somehow. I am at about 385 total rooms right now, I think.

What could be happening?