While working on Encounter, I realized that the length of the program was more or less caused by many situations needed to do tests involving three possible combinations:
- If A and B then do something
- If A and C then do something else
- Do something else

A concrete example:
11370 IF (S$="TWI" )AND (TW=0) THEN PRINT"CROAK":GOTO11407
11371 IF (S$="TWI") AND (TW<>0) THEN PRINT"You don't have any":GOTO10000

Basically this should be like that:
IF (S$="TWI") THEN IF(TW=0)THEN PRINT"CROAK":GOTO11407 ELSE PRINT"You don't have any":GOTO10000

The question is: Without scoping operator, how do we know with certainty how the ELSE are handled?
Is it doing the ELSE regarding the S$="TWI" check, or the TW=0 check?

Basically the source code is littered with small one liner functions jumps just to handle this.

If someone has a definitive guide on how to handle multi-level IF THEN ELSE; please share

Considering that complexity is one of the parameters that makes things difficult to understand, I would say that the two lines of IF are not much simpler to decode, and despite being almost idiomatic leave the room for errors where the second variable does not match the one in the other line

When I started C, I thought the idiomatic string copy implementation was hard to read, but now when I see while (*dest++=*src++); I don't even have to think about what it does because it has entered into my "idiomatic elements for this language" category (not be confused with the "idiotic elements" of course, which is a totally different ball of nonsensical madness )

But yes, it's probably something a real "BASIC optimizer" could do for you.

For what it's worth, here's a small test I wrote (for a completely different matter that is however slightly related to your "Encounter" series...) to see whether (and how many) imbricated IF THEN ELSE statements worked in Oric BASIC:

I do however vaguely remember there is a bug with the "ELSE" statement in the Oric, but I don't quite remember what is is, and I didn't encounter it in my test... I THOUGHT it was if you put 2 instructions after the ELSE, then only the first one got executed, but I wrote another small program to test that and it isn't the case, so the "ELSE" bug must be something different...

IF condition1 THEN statement1 ELSE IF condition2 THEN statement2 ELSE IF condition3 THEN statement3

PS - I still hate this "basic" BASIC language though, because you still have to use GOTO's all over the place to achieve some (not so complex) execution flows... I do remember though how thrilled I was when I got GFA BASIC on the Atari ST (and then later, Visual Basic on WIndows...)

Okay, I might be completely misunderstanding the issue here, but is it related to the dangling else problem? If so, I am pretty sure the Oric BASIC interpreter acts either way, most probably by matching each ELSE to the latest IF that was 'seen'. In any case in a predictable way...