Weird Hugo bug

[Ice Cream Jonsey]

I've got a weird thing - it looks like data for some of my monsters is being overwritten. I don't get it. Let me post the compile stats first:

===============================================================================
HUGO COMPILER v3.1.03 STATISTICS FOR: cyberganked.hug
02/09/19 16:38:58
===============================================================================
Compiled 80597 lines in 68 file(s)

Objects: 846 (maximum 2048) Routines: 722 (maximum 1024)
Attributes: 70 (maximum 128) Events: 32 (maximum 256)
Properties: 179 (maximum 254) Labels: 18 (maximum 256)
Aliases: 71 (maximum 256) Globals: 140 (maximum 240)
Constants: 183 (maximum 256) Arrays: 216 (maximum 512)

Words in dictionary: 3143 Special words: 30 Verbs: 143

Object file: cyberganked.hex (809353 bytes)
(debuggable format)

Elapsed compile time: 3 seconds
===============================================================================

f:\games\cyberganked>

[Ice Cream Jonsey]

I put all the monsters in an array. If I try to print out monster.name for each monster, it stops printing out anything for the monster at number 69. If I try to just print out that monster name, nothing is written. And this is the case for monsters 70-73 as well.

[Ice Cream Jonsey]

So, the first monster that doesn't seem to work is the halloweener - if I take that object and move it to the beginning of the monsters.hug file, then I can print his name. But then I can't print the name of a monster that worked before. It's like I can only have so many objects in a file?

[Flack]

Just to be clear, the monster in the 69 position appears to be eating other monsters?

[Ice Cream Jonsey]

I would describe it like this:

monsters.hug is the last file that gets compiled. I am not sure why it has to be last. But if I move it up, the UI for the game doesn't display correctly. I may choose to debug that.

When the 69th monster is accessed, information about the monster seems to be overwritten by something.

If I insert a non-monster object at, say, between the 50th and 51st monster... then the 68th monster is munged. (If I insert a new monster between 50 and 51 the same thing also happens.) It SEEMS like I have hit some sort of limit on objects. But you can state the max number of objects and I am not there.

I nuked a bunch of arrays I had defined but wasn't using, but that had no effect.

[pinback]

Nice.

[Ice Cream Jonsey]

I am at a point now where the game immediately dies on start. I got there by adding another object.

If I unset USE_PLURAL_OBJECTS the game doesn't die immediately.

EDIT: doesn't die, but I still get blank data when printing out names of the last monster objects.

I suspect that the fact that I bring the monsters in late has something to do with it. I am going to add a room to a file I load well before monsters (and rooms are objects) to see if that has an effect.

[Ice Cream Jonsey]

It can't just be number of objects - Cryptozookeeper has 917 and Cyberganked has 864.

When I moved files around I saw different behavior - I put all the mazes after monsters.hug. And sure enough, at a certain point the objects (they are rooms) in the mazes stop working. What on earth is going on here?

[Ice Cream Jonsey]

I might have figured it out. I had a giant "character" class for the six characters in the game.

I used that same class for the monsters. The only thing was, that was a ton of information about monsters that didn't apply. They aren't player characters.

Here is the compile stats when the monsters were part of the character class:

Code: Select all

===============================================================================
HUGO COMPILER v3.1.03 STATISTICS FOR:  cyberganked.hug
02/10/19 14:49:30
===============================================================================
Compiled 80418 lines in 68 file(s)

Objects:      831 (maximum  1024)      Routines:   714 (maximum  1024)
Attributes:    70 (maximum   128)      Events:      32 (maximum   256)
Properties:   172 (maximum   254)      Labels:      17 (maximum   256)
Aliases:       61 (maximum   256)      Globals:    137 (maximum   240)
Constants:    181 (maximum   256)      Arrays:     215 (maximum   256)

Words in dictionary:  3125    Special words:    30    Verbs:   143

Object file:  cyberganked.hex (766571 bytes)
(debuggable format)

Elapsed compile time:  5 seconds
===============================================================================

Here is the compile stats afterwards, when the monsters had their own class ("monster") that had nothing in it but the code type monster:

Code: Select all

===============================================================================
HUGO COMPILER v3.1.03 STATISTICS FOR:  cyberganked.hug
02/10/19 14:54:03
===============================================================================
Compiled 80416 lines in 68 file(s)

Objects:      831 (maximum  1024)      Routines:   714 (maximum  1024)
Attributes:    70 (maximum   128)      Events:      32 (maximum   256)
Properties:   172 (maximum   254)      Labels:      17 (maximum   256)
Aliases:       61 (maximum   256)      Globals:    137 (maximum   240)
Constants:    181 (maximum   256)      Arrays:     215 (maximum   256)

Words in dictionary:  3126    Special words:    30    Verbs:   143

Object file:  cyberganked.hex (751979 bytes)
(debuggable format)

Elapsed compile time:  3 seconds
===============================================================================

So that's like 14 thousand bytes that were freed up. I don't really understand the why, but when I made that change to use its own virtually empty class, all the of the objects seem to print themselves out OK now.

[Ice Cream Jonsey]

I think the other thing that worried me was that I have the six player characters in_scope at all times. There are 73 enemies at the moment - I don't know if having an additional 73 monsters in scope was fucking things up. I don't know that it could have possibly helped?

[Ice Cream Jonsey]

I am getting this trying to compile the game on a Mac - anyone familiar with this error?

➜ cyberganked git:(master) ✗ _mac/hc cyberganked.hug
hc(57258,0x7fff8f119380) malloc: *** error for object 0x103148970: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1] 57258 abort _mac/hc cyberganked.hug

[Ice Cream Jonsey]

It doesn't happen with the Windows or Unix version of hc.

The bad news is that if I go to an earlier commit, the Mac version of hc works - so it's something in the refactor I did for the first oddness up top.

[Jizaboz]

Wish I could help. This sounds like a nightmare to troubleshoot.

[RealNC]

Why is there a different version for macOS?

[Ice Cream Jonsey]

Why is there a different version for macOS?

Different version of hc? The unix version can't run on a Mac ...... can it?

[RealNC]

Different version of hc? The unix version can't run on a Mac ...... can it?

Didn't try it, but it should build and run fine. macOS is a Unix system, after all. If it doesn't work, maybe it just needs some changes? I'll try and take a look at it.

[Jizaboz]

Why is there a different version for macOS?

Different version of hc? The unix version can't run on a Mac ...... can it?

I want to say the last time I tried this I had issues. What I ended up doing on OSX (Not ideal, and I prefer just using my Windows gaming machine for this) was running Roody's version of Notepad++ that's got the compiler, Hugor, etc all built in Wine. It can be a little quirky UI-wise but it worked.

[Ice Cream Jonsey]

Different version of hc? The unix version can't run on a Mac ...... can it?

Didn't try it, but it should build and run fine. macOS is a Unix system, after all. If it doesn't work, maybe it just needs some changes? I'll try and take a look at it.

A few years ago when we tried to get hc working on a Mac, I ended up putting the Mac-specific changes that I THINK Adam Thornton did in this repository:

https://bitbucket.org/rsherwin/hugo-mac/src

[RealNC]

I'll compare the two and try and merge the changes into hugo-unix so that there's only one code base.

[RealNC]

OK, now that I looked at it, I remembered that I most probably fixed that bug in the commits I made back in 2015:

https://bitbucket.org/0branch/hugo-unix/commits/all

So the mac sources are outdated and don't have any of these bugfixes. I'll sync the Unix repo with the Mac repo (there's only one fix in the Mac repo that isn't in the Unix one.) After that, you should probably delete the Mac repo and build hc using the Unix sources. There really is no point in having a mac-specific source repo as it's 100% identical to the Unix one after syncing both repos.