QFG4: Assertion Error segment.h:866 with Cranium's robot

[Vhati]

ScummVM 2.1.0git3770-g15306581ab (Oct 18 2018 04:27:32)
Windows 7 64bit
QFG4 Floppy 1.1a + note patch (English)

In Dr Cranium's hallway... I clicked HAND on the robot and immediately got an assertion error.

MinGW Runtime Assertion

Assertion failed!

Program: scummvm.exe
File: ../../src-master/src/engines/sci/engine/segment.h, Line 866

Expression: _type == kArrayTypeString || _type == kArrayTypeByte

File - 5kb MD5 - Full MD5
RESOURCE.000 - f64fd6aa3977939a86ff30783dd677e1 - ff42260a665995a85aeb277ad80aac8a
RESOURCE.MAP - d10a4cc177d2091d744e2ad8c049b0ae - 3695b1b0a1d15f3d324ea9f0cc325245
RESOURCE.SFX - 3cf95e09dab8b11d675e0537e18b499a - 7c858d7253f86dab4cc6066013c5ecec

[Vhati]

SavedGame (Floppy) - Cranium's Hallway

[Vhati]

Assertion is here:
​https://github.com/scummvm/scummvm/blob/master/engines/sci/engine/segment.h#L866

[Vhati]

Workaround idea

Since I can't get the key without the robot... Would it destabilize my whole run if I used the console 'room' command to teleport in/out of the Cranium's lab? (floppy rooms: lab=370, hallway=380)

I'm seeing an error in there and I'm unsure whether I should create a ticket or if I voided my warranty from then on.

Ask about flask, works. Ask about healing or cure potion...
"kAddScreenItem: Plane 0000:0000 not found for screen item 0030:03a6!"

[bluegr]

The floppy version seems to be badly broken here. It's trying to insert a string (the message that the robot shows) into an array of integers, which is where this error is coming from.

Quite strange. This will need a script patch to initialize the array it's trying to make into an array of characters.

The CD version works as expected, creating an array of characters.

[Vhati]

@Myself:

Would it destabilize my whole run if I used the console 'room' command to teleport

Voids my warranty, I guess.

​Post: ScummVM Forum - eriktorbjorn (2006)

Even such a relatively simple thing as "teleporting" to another room can cause strange things to happen.

I don't see any reason to try and make the debug commands any friendlier or more crash-proof. Most of them were probably added to help debug a specific type of problem
[...]
I was the one who added [the Loom debugger 'drafts' command], and even I don't remember off-hand what all the data it prints means any longer. And I don't have to know, because Loom has been working fine for quite some time now. :)

[bluegr]

Fixed in commit f4ae043d70d17f13922fb3e2314b46f2ce80f038. Closing