#9184 closed patch (fixed)
BRA: correctly parse animations of type none
| Reported by: | fuzzie | Owned by: | peres |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Parallaction |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
r35783 removes a check for kZoneNone, this patch puts it back so that animations of type 'none' are parsed correctly (for example, so that COMMANDS blocks are picked up).
This is necessary for BRA. For example, take a look at scende2 inside PASSA.LOC, which turns the mouse cursor back on. Patch against trunk.
An alternative would be to fix parseZoneTypeBlock and all the parsing functions so that they handled the parser tables themselves if they didn't recognise a line, which would work in all circumstances. I'd be happy to try writing a patch to do that, if you'd prefer!
(The _parser->popTables() call is moved inside the if statement here, too, because otherwise the remaining contents of the animation aren't parsed correctly - shouldn't this also be the case for the other if statements with a parseZoneTypeBlock call inside them?)
Ticket imported from: #3005384. Ticket imported from: patches/1289.
Attachments (1)
Change History (6)
by , 14 years ago
| Attachment: | 0009-correctly-parse-animations-of-type-none.txt added |
|---|
comment:1 by , 14 years ago
| Owner: | set to |
|---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:4 by , 14 years ago
I implemented a parser for kZoneNone in r49628, instead of committing your patch, which was of inspiration, anyway. :)
On a sidenote, Animation "scende2" is the only one I could find in BRA which doesn't follow the standard definition.
comment:5 by , 5 years ago
| Component: | → Engine: Parallaction |
|---|
The standard definition for a zone (or animation) follows the order: ZONE - PROPERTIES - COMMAND BLOCK - TYPE DEFINITION - TYPE PROPERTIES - END ZONE. It is clear that the command block belongs to the zone, and is not part of the type definition. This is how zones are defined in NS and (most of) BRA, so the parser I implemented expects this order. This is also why popTables() was there: type properties were ALWAYS the last thing to be parsed out of a zone.
The zones you found do not follow the standard order, having the command block after the type definition (instead of the type properties). I had never encountered them in my development, and that's why I commented that code out in r35783. My first code (from reversing) was right and commenting it was only a slight oversight. The actual bad thing is that I then deleted that code without checking.
Your proposal of fixing all the zone type parsers to handle misplaced command blocks sounds like a good idea, but it is probably overkill since we only have this case at hand. Another way to do it would be to implement a parser for kZoneNone to handle the misplaced command blocks. This would allow us to get rid of the special handling you added in your patch.