DREAMWEB: Assert failure in showAllEx

[sluicebox]

This was reported by @huntekye after the fix in #15420, and I've created a new ticket.

To reproduce, as described by @huntekye with the attached save:

Load the saved game "game1.5_passcard", open the inventory (click on the dude's face), click on the passcard (10th position on page 3 of the inventory), drop it by moving it to the trash can, and then (try to) exit the inventory.

This bug looks similar to #15420, but I don't think they are directly related. In the previous ticket, a frame parameter was declared as 8 bits causing the 16 bit values passed to it to silently truncate and cause failures. In this ticket, an assertion was written 13 years ago that a frame number would never be 256 or greater, even though the function calculates many 16 bit frame numbers, and the function that receives the value takes a 16 bit parameter. Also, the underlying frame arrays have more than 255 elements.

This assertion is uncommented, and was added 13 years ago in a commit whose description is unrelated: e40f1af3dcc282585cd8f9d173d81657ec4dc0cc . I guess what I'm saying is, "Good luck, Team Dreamweb!" =)

I am unfamiliar with this engine/game, but I was comfortable fixing the first bug in 77151b611059a187cc76e798a749bf900172d8d7 because it was an easily explainable programming mistake. In this case though, @wjp wrote an assertion that frame numbers should never be this large, even though the surrounding loop contradicts this. This same assertion also occurs in showAllFree with similar code. I leave this one to someone who knows this engine.

I suspect these asserts should just be deleted. When I do, the game seems to work fine. Document your assertions if you want to keep 'em =)

[sluicebox <22204938+sluicebox@…>]

In 23ada878:

DREAMWEB: Change assert to warning in showAllEx

Trac #15436

[sluicebox]

I've changed the assert to a warning and commented it as FIXME: 23ada878875a66730435607d159c4dbabbe615e8

It would be nice if someone who knows this engine takes a look at it someday, but I don't see why it should prevent playing the game if it's not really a problem, which I suspect it isn't. It looks like a copy/paste mistake to me from showAllFree where the check always passes due to fewer loop iterations.

If this issue ends up being more complicated, this ticket can always be reopened.