398 replies to this topic

[Timelord]

It's nothing to do with Tango, just ZC's built-in screen freezing combos. Drawing won't work; the combo has to be used by an actual FFC.
 
You could have the global script go into a minimal inner loop while the menu is open.
 
The Screen Freeze (Except FFCs) combo is as close as you'll get. It won't suspend the global script, but that can be worked around.
 
If you draw with Y<0, it will draw over the active subscreen. If the "Subscreen Appears Above Sprites" rule is enabled, that will only work if you draw on layer 7.
The top-left of the screen is 0, 0, and the bottom-right is 255, 167. The passive subscreen extends to -56. There's no maximum or minimum; you can draw anywhere, even far offscreen.
There's no Z coordinate in drawing.

 
 
I have this working, but only partially. It may be a bug with the cascading menus...
 
This is what happens:
 
You open the main menu, the game freezes.
You pass though other menus, the game remains frozen.
 
When you return to the first menu (not fully exiting the menus, just dropping back to the lowest tier), the game unfreezes, while the first menu is still on-screen.
 
Closing and re-opening the menu, doesn't fix it. The game no longer freezes, when opening the main menu.
 
I set the freeze flag in every style choice, I set it it in menus directly; and I set it in the while(true) loop of the menu FFC.
 
None of this cleared the problem.
 
Here's a ZIP archive with a .qst file to illustrate the problem; including my style.zh, styles.zh, tango.zh, and menus.z files. If you need to look at any of my other files, let me know.

I can't find a reason for this; and just relying on the styles, without setting the freeze action everywhere, causes cascading windows that display moving text to unfreeze the game.

Would it be better to set a global bool to handle this? (That would certainly be easier, as this kind of action is desirable whenever a dialogue box of any kind is open...) If so, where should I put the instruction to activate it inside the Tango scripts, so that it becomes true whenever any menu is open, and becomes false when all menus are closed?
 
Edit:
 
I did this, which bypassed the problem (although I still think that's a bug with the freeze flag, for a primary cascading menu).
 
This fixes the problem:
 
gc_menus.z
 
What function clears all active Tango windows?
 
...and...
 
Is there a function that can make them invisible?
 
I'm going to need to do that, when using spells, so that the player selects a spell, the windows close, and the spell function runs.
 
I'm also going to need to allow a player to click on the screen with a mouse, to centre an area-effect, so the player will need to be able to see the entire screen.
 

Other Questions
Is there a Tango function ( @ ) to return the value of a counter; or a simple way to store a value as an int, and then to place that int into a tango string?
 
For example, if I do this:
 

int number = Game->Counter[CR_STAT];

 
or..
 

int number = StatsArray[2];

 
.How do I insert the value of number, into a tango string such as:
 

int string1[] = "MUSC STAT@tab(56)@ ???"
 
///??? = where I want to put the code to display the value of the int 'number'.

Edited by ZoriaRPG, 29 May 2014 - 08:11 PM.

[MoscowModder]

I do this:

//Show buy confirmation
Tango_D[0] = price; //Give price to string
Waitframe(); //Apparently need to wait so confirmation can read it
stringID = ShowMessageByLink(S_CONFIRMBUY, STYLE_GAME, true); //Has No/Yes menu

Where message S_CONFIRMBUY has @number(@d0) in it.

The same should work with ZScript strings as well.

[Saffith]

I have this working, but only partially. It may be a bug with the cascading menus...

It keeps count of how many active slots freeze the screen, but it's probably counting incorrectly somewhere. Try tracing __Tango_Data[__TDIDX_SCREEN_FREEZE], and let me know if you see where it's going wrong.
 

I set the freeze flag in every style choice, I set it it in menus directly; and I set it in the while(true) loop of the menu FFC.

You only need to do it once, and since it's common to all of them, doing it in the one-time setup function should be fine. I don't think setting it repeatedly will cause problems, but setting it when the string's already visible might.
 

Would it be better to set a global bool to handle this? (That would certainly be easier, as this kind of action is desirable whenever a dialogue box of any kind is open...) If so, where should I put the instruction to activate it inside the Tango scripts, so that it becomes true whenever any menu is open, and becomes false when all menus are closed?

You could just call the screen freeze function before opening the main menu and the unfreeze function after it closes. You could also have the freeze flag only on the top-level menu, assuming it's open as long as any other is.
 

What function clears all active Tango windows?

There isn't a single function for that. Just call Tango_ClearSlot() in a loop.
 

Is there a function that can make them invisible?

No, but you could move them offscreen. You could also skip calling Tango_Update2(), which is the function that does the drawing.

[Timelord]

I do this:

//Show buy confirmation
Tango_D[0] = price; //Give price to string
Waitframe(); //Apparently need to wait so confirmation can read it
stringID = ShowMessageByLink(S_CONFIRMBUY, STYLE_GAME, true); //Has No/Yes menu

Where message S_CONFIRMBUY has @number(@d0) in it.

The same should work with ZScript strings as well.

 

That works for me, however, the game action resumes while it places the text into the box; then pauses again after it fills the whole box.

 

 

It keeps count of how many active slots freeze the screen, but it's probably counting incorrectly somewhere. Try tracing __Tango_Data[__TDIDX_SCREEN_FREEZE], and let me know if you see where it's going wrong.
 
You only need to do it once, and since it's common to all of them, doing it in the one-time setup function should be fine. I don't think setting it repeatedly will cause problems, but setting it when the string's already visible might.
 
You could just call the screen freeze function before opening the main menu and the unfreeze function after it closes. You could also have the freeze flag only on the top-level menu, assuming it's open as long as any other is.
 
There isn't a single function for that. Just call Tango_ClearSlot() in a loop.
 
No, but you could move them offscreen. You could also skip calling Tango_Update2(), which is the function that does the drawing.

 

 

I'll try the trace in a while.

 

As noted above, the only time that the screen unfreezes now, is when it is drawing text, one character at a time.

 

I still don't have game freezing working as I intend.

 

Note: This affects Tango_LoadString and Tango_AppendString, but not ShowString(text).

 

Result of Trace:

 

Invalid index (60) to local array of size 60

 

This occurs whenever selecting any menu function.

 

Entire output below.

 

I'm assuming that the vale 1.0000 is from the Trace, as the array values occur when loading any menu, but the value 1.0000 appears only when I open the stats menu.

 

Screen (1, 00)
Screen (1, 01)
Invalid index (60) to local array of size 60
1.0000
Invalid index (60) to local array of size 60

Edited by ZoriaRPG, 29 May 2014 - 09:54 PM.

[Saffith]

I overlooked it, but you still have __Tango_SlotDefs[] incorrect. Here:

int __Tango_SlotDefs[] = {
// 0
TANGO_SLOT_WINDOW,
0, // Starting index in __Tango_StringBuffer
256, // Maximum length after processing
0, 0, // X, Y on offscreen bitmap
256, 168, // Width, height on offscreen bitmap

// 1
TANGO_SLOT_WINDOW,
256,
256,
256, 0,
256, 168,

//2
TANGO_SLOT_WINDOW,
512,
256,
0, 168,
256, 168,

//3
TANGO_SLOT_WINDOW,
768,
256,
256, 168,
256, 168,

//4
TANGO_SLOT_WINDOW,
1024,
256,
0, 336,
256, 168
};

There are still only three styles. Part of the idea was that there's a separate style for each slot - slot 0 always uses style 0, slot 1 always uses style 1, and so on. That way, you can resize them without worrying about messing up other menus. If you'll only ever have three different window sizes, that's a different matter; you can do the setup for all three at once and never touch them again.

I think I might see the problem. Try editing Tango_RestoreSlotState(). tango/user.zh, line 215.

New code

void Tango_RestoreSlotState(int slot, int oldState)
{
    bool frozenBefore=false;
    if(Tango_SlotIsActive(slot))
    {
        if((__Tango_GetSlotFlags(slot)&TANGO_FLAG_FREEZE_SCREEN)!=0)
            frozenBefore=true;
    }
    
    int bufStart=__Tango_GetSlotDefData(slot, __TSDEF_START);
    int bufSize=__Tango_GetSlotDefData(slot, __TSDEF_LENGTH);
    
    for(int i=0; i<bufSize; i++)
        __Tango_Buffer[i+bufStart]=oldState[i];
    
    int dataOffset=slot*__TANGO_SIZEOF_DATA;
    
    for(int i=0; i<__TANGO_SIZEOF_DATA; i++)
        __Tango_SlotData[i+dataOffset]=oldState[i+bufSize];
    
    bool frozenAfter=false;
    if(Tango_SlotIsActive(slot))
    {
        if((__Tango_GetSlotFlags(slot)&TANGO_FLAG_FREEZE_SCREEN)!=0)
            frozenAfter=true;
    }
    
    if(frozenBefore && !frozenAfter)
        __Tango_DecScreenFreeze();
    else if(!frozenBefore && frozenAfter)
        __Tango_IncScreenFreeze();
}

[Timelord]

I overlooked it, but you still have __Tango_SlotDefs[] incorrect. Here:

int __Tango_SlotDefs[] = {
// 0
TANGO_SLOT_WINDOW,
0, // Starting index in __Tango_StringBuffer
256, // Maximum length after processing
0, 0, // X, Y on offscreen bitmap
256, 168, // Width, height on offscreen bitmap

// 1
TANGO_SLOT_WINDOW,
256,
256,
256, 0,
256, 168,

//2
TANGO_SLOT_WINDOW,
512,
256,
0, 168,
256, 168,

//3
TANGO_SLOT_WINDOW,
768,
256,
256, 168,
256, 168,

//4
TANGO_SLOT_WINDOW,
1024,
256,
0, 336,
256, 168
};

 

That was a bug on the original header then, ad I didn't change the slot defs for slot 0, 1, or 2 (1,2,3); I only added the extra two. I thought that two slots starting at 512, was odd; but I assumed yon for it.

 

There are still only three styles. Part of the idea was that there's a separate style for each slot - slot 0 always uses style 0, slot 1 always uses style 1, and so on. That way, you can resize them without worrying about messing up other menus. If you'll only ever have three different window sizes, that's a different matter; you can do the setup for all three at once and never touch them again.

I think I might see the problem. Try editing Tango_RestoreSlotState(). tango/user.zh, line 215.

New code

void Tango_RestoreSlotState(int slot, int oldState)
{
    bool frozenBefore=false;
    if(Tango_SlotIsActive(slot))
    {
        if((__Tango_GetSlotFlags(slot)&TANGO_FLAG_FREEZE_SCREEN)!=0)
            frozenBefore=true;
    }
    
    int bufStart=__Tango_GetSlotDefData(slot, __TSDEF_START);
    int bufSize=__Tango_GetSlotDefData(slot, __TSDEF_LENGTH);
    
    for(int i=0; i<bufSize; i++)
        __Tango_Buffer[i+bufStart]=oldState[i];
    
    int dataOffset=slot*__TANGO_SIZEOF_DATA;
    
    for(int i=0; i<__TANGO_SIZEOF_DATA; i++)
        __Tango_SlotData[i+dataOffset]=oldState[i+bufSize];
    
    bool frozenAfter=false;
    if(Tango_SlotIsActive(slot))
    {
        if((__Tango_GetSlotFlags(slot)&TANGO_FLAG_FREEZE_SCREEN)!=0)
            frozenAfter=true;
    }
    
    if(frozenBefore && !frozenAfter)
        __Tango_DecScreenFreeze();
    else if(!frozenBefore && frozenAfter)
        __Tango_IncScreenFreeze();
}

 

That unfortunately didn't change the problem. I did try matching the window slot, and window style; and I also trued to add the flag 'Instantaneous'. For whatever reason, reading in multiple lines, that are not menu choices, causes the game to un-freeze when it's displaying them.

I packaged only the Tango scripts here.

My customised freeze function, by which I was able to get most windows to obey frozen states, is in stdZoria.zh
The menu file is /gc_menus.z
The user-defines style settings are still in styles.zh (not style.zh), as you established them, edited to add the freeze operation.

Here's an updated .qst file, using all the new code: r5A3sC

 

P.S. I don;t know if this is helpful in any way, but if I put an @choice first, rather than last, the strings all display at one time, and the menu don;t allow action while displaying text.

 

That is, this:

 

  //freezeAction();
    Tango_D[0] = getMuscStat();
    Tango_D[1] = getBodyStat();
    Tango_D[2] = getMindStat();
    Tango_D[3] = getMystStat();
    Tango_D[4] = getLuckStat();
    Tango_D[5] = getInflStat();
    Tango_D[6] = Game->Counter[CR_LEVEL];
    
    int line0[]="@choice(1)Done@26@26";
    int line1[]="MUSCLE@tab(56)@number(@d0)@26";
    int line2[]="BODY@tab(56)@number(@d1)@26";
    int line3[]="MIND@tab(56)@number(@d2)@26";
    int line4[]="MYSTIC@tab(56)@number(@d3)@26";
    int line5[]="LUCK@tab(56)@number(@d4)@26";
    int line6[]="INFL@tab(56)@number(@d5)@domenu(1)@suspend()";
 

    int lineBreak[]="@26";
    int menuEnd[]="@domenu(1)@suspend()";


    
     SetUpWindow(WINDOW_SLOT_2, WINDOW_STYLE_2, 32, 32, SIZE_LARGE);
     Tango_SetStyleAttribute(WINDOW_STYLE_2, TANGO_STYLE_FLAGS, TANGO_FLAG_INSTANTANEOUS);
     Tango_SetStyleAttribute(WINDOW_STYLE_2, TANGO_STYLE_FLAGS, TANGO_FLAG_FREEZE_SCREEN);
     Trace(__Tango_Data[__TDIDX_SCREEN_FREEZE]);
               
        Tango_LoadString(WINDOW_SLOT_2, line0);
        Tango_AppendString(WINDOW_SLOT_2, line1);
        Tango_AppendString(WINDOW_SLOT_2, line2);
        Tango_AppendString(WINDOW_SLOT_2, line3);
        Tango_AppendString(WINDOW_SLOT_2, line4);
        Tango_AppendString(WINDOW_SLOT_2, line5);
        Tango_AppendString(WINDOW_SLOT_2, line6);
        Tango_AppendString(WINDOW_SLOT_2, menuEnd);
        Tango_ActivateSlot(WINDOW_SLOT_2);

 

The above works. What follows, does not:

 

Tango_D[0] = getMuscStat();
    Tango_D[1] = getBodyStat();
    Tango_D[2] = getMindStat();
    Tango_D[3] = getMystStat();
    Tango_D[4] = getLuckStat();
    Tango_D[5] = getInflStat();
    Tango_D[6] = Game->Counter[CR_LEVEL];
    
    int line1[]="MUSCLE@tab(56)@number(@d0)@26";
    int line2[]="BODY@tab(56)@number(@d1)@26";
    int line3[]="MIND@tab(56)@number(@d2)@26";
    int line4[]="MYSTIC@tab(56)@number(@d3)@26";
    int line5[]="LUCK@tab(56)@number(@d4)@26";
    int line6[]="INFL@tab(56)@number(@d5)@26";
    int line7[]="@26";
    int line8[]="@choice(1)Done@domenu(1)@suspend()";

    int lineBreak[]="@26";
    int menuEnd[]="@domenu(1)@suspend()";


    
     SetUpWindow(WINDOW_SLOT_2, WINDOW_STYLE_1, 32, 32, SIZE_LARGE);
     Tango_SetStyleAttribute(WINDOW_STYLE_1, TANGO_STYLE_FLAGS, TANGO_FLAG_INSTANTANEOUS);
     Tango_SetStyleAttribute(WINDOW_STYLE_1, TANGO_STYLE_FLAGS, TANGO_FLAG_FREEZE_SCREEN);
     Trace(__Tango_Data[__TDIDX_SCREEN_FREEZE]);
               
        Tango_LoadString(WINDOW_SLOT_2, line1);
        Tango_AppendString(WINDOW_SLOT_2, line2);
        Tango_AppendString(WINDOW_SLOT_2, line3);
        Tango_AppendString(WINDOW_SLOT_2, line4);
        Tango_AppendString(WINDOW_SLOT_2, line5);
        Tango_AppendString(WINDOW_SLOT_2, line6);
        Tango_AppendString(WINDOW_SLOT_2, line7);
        Tango_AppendString(WINDOW_SLOT_2, line8);
        Tango_AppendString(WINDOW_SLOT_2, menuEnd);
        Tango_ActivateSlot(WINDOW_SLOT_2);

 

For whatever reason, placing an @choice at the front of a menu, forces it to display all of its text at one time. Placing text of another kind before the @choice, causes that text to slowly draw on the screen. I don't know if that's intended, for Yes/No type dialogue boxes, or of it's a bug

Edited by ZoriaRPG, 30 May 2014 - 03:23 AM.

[Saffith]

There are a lot of array errors...

Invalid index (29) to local array of size 28
Invalid index (-1) to local array of size 1280
Invalid index (31) to local array of size 28
Invalid index (32) to local array of size 28
Invalid index (29) to local array of size 28
Invalid index (-1) to local array of size 1280
Invalid index (31) to local array of size 28
Invalid index (32) to local array of size 28
Invalid index (29) to local array of size 28
Invalid index (29) to local array of size 28
Invalid index (30) to local array of size 28
Invalid index (29) to local array of size 28
Invalid index (29) to local array of size 28
Invalid index (30) to local array of size 28

The 1280 is presumably __Tango_Buffer, but I haven't found where it's coming from. I don't know what the size 28 array is, but that happens constantly.
There are also some invalid style errors showing up; those show up when the spells menu is opened, but I haven't found where exactly. Possibly my fault, not sure yet.

You need to remove all these random calls to Tango_SetStyleAttribute and freezeAction and unfreezeAction. They're just making it harder to tell what works correctly and what doesn't. Either call freezeAction when the menu opens and unfreezeAction when it closes, or use the screen freeze style flag and help me figure out what's wrong if it doesn't work.

[Timelord]

There are a lot of array errors...
The 1280 is presumably __Tango_Buffer, but I haven't found where it's coming from. I don't know what the size 28 array is, but that happens constantly.
There are also some invalid style errors showing up; those show up when the spells menu is opened, but I haven't found where exactly. Possibly my fault, not sure yet.

You need to remove all these random calls to Tango_SetStyleAttribute and freezeAction and unfreezeAction. They're just making it harder to tell what works correctly and what doesn't. Either call freezeAction when the menu opens and unfreezeAction when it closes, or use the screen freeze style flag and help me figure out what's wrong if it doesn't work.

 

I'll type out a version that only calls to your flag, sometime this evening.

 

For the sake of clarity where should I put the flag, and how, precisely, so that I don;t try running tests with a call to that flag in the wrong location; so that it is always used in every style, and every formatting type?

 

Should I have it in the function void SetCommonStyleData(int style) or in the void SetStyleSize(int style, int size) functions, or somewhere else?

 

I know that something is using SetCommonStyleData, but I'm not yet sure what calls to that.

 

The only reason I went with my own function, is that the freeze flag didn't seem to do anything, at all, when I had it in SetCommonStyleData. I started placing it elsewhere, and after unpleasant results, I tried to write my own function that was always running, while Tango was doing anything. That was for my needs, although it didn't work out as intended, because of this one fault; but I have no problem helping you debug this, so that it works as intended.

 

(I don't quite understand why my freezeAction() function isn't working for this one menu, especially given that it works everywhere else...)

 

Either way, using the in-built method would be better, as (1) it's less likely to break something else later; and (2) it will work for everyone else.

 

If you played the game, beyond just testing the menu on the opening screens, those array errors could be from some other things that I'm working on at present, such as the NWS, and the RPG system. Both use arrays, and may have for loops with improper pointers, or something along those lines. (I didn't write all of them, and didn't 100% proof all the code.)

 

(When I was testing the menus, I stayed on screen 0,00; as that has no enemies, and the player needn't use any weapons, and to test of the menu caused the game to stay frozen, I went down one screen (to screen 0,10), and immediately opened the menu.)

 

On another note...

 

For future versions, i would suggest starting each Tagno entry with an Initialise instruction that includes user-defined styles, and allows the user to make templates, that they can call vis a discrete function, SetStyle, with a call to their user-defined style choice, for that tango slot, and only for that instance.

 

It doesn't seem that you had this in mind, with the limits on slots, and on styles, but it would be a rather tidy way to handle it.

 

R3garding Drawing outside the Screen

 

You say that youc an draw 'very far' outside the screen. Do you (or does anyone) know the maximum offsets? I also don;t know if I can use negative values, and what the starting values represent.

 

If you draw with Y<0, it will draw over the active subscreen. If the "Subscreen Appears Above Sprites" rule is enabled, that will only work if you draw on layer 7.
The top-left of the screen is 0, 0, and the bottom-right is 255, 167. The passive subscreen extends to -56. There's no maximum or minimum; you can draw anywhere, even far offscreen.
There's no Z coordinate in drawing.

 

What are the boundary points of the passive subscreen? -56Y to -1Y? That's an odd dimension, as it;s only 55 pixels, not 56. is it -57Y to -1Y for 56 (divisible by pixels, or is there a one pixel overlay somewhere? (I assume that the X coodinates are 0-255, as with the screen.)

 

Tango, in theory, could replace the passive subscreen entirely, which would be a neat way to use it, especially to select 'active counters'.

 

Al of this, IMHO, should be clearly spent out to the user: Draw offsets of 256/176 are drawing outside the screen, but I doubt that most people would know, or realise this, and the maximum overscan area/offsets would be good to have in the documentation. (I still don't have a definitive answer, as clearly the overscan area isn;t infinite.

 

Another good question: Are bitmaps stored at the same X/Y coordinates, on different layers, readable independently, and/or readable as a combined bitmap, preserving transparency?

 

With a the normal screen area is 0-255 x 0-175, 256 is one pixel outside the horizontal boundary, and 127 is one pixel outside the vertical boundary. Is -1 on the X axis also outside the boundary, in the opposite direction of an axis, or even a valid coordinate for this? I presume that it is, and as such, we'd have plenty fo space for concurrent bitmaps, and thus, plenty of space for additional slots.

 

Obviously setting a style for each instance of a Tango dialogue;menu would be the best way to treat it, as, there may be things that you wouldn't want to freeze a screen. Take a Tango-based passive sunscreen as an example: That's something you may want to be on-screen at all times, but not freezing the game action.

 

I'm not sure if user-defined styles, and a setUserStyle(int styleNumber) that allows a user to make a full style list, anf use them as needed, rather than typematching slots/styles would be difficult, but from what I;ve read, it seems like it would be possible, and might make it a bit easier to use.

 

In any event, that doesn't solve the present bug-hunt; it's merely some thoughts, and considerations for improving/refining this before v1.0. As I said, I'll start re-coding some of what I have when I wake. I'd have been asleep by now, if I didn't have to attend to something important that disturbed my attempt at repose.

 

Is there any space that ZC reserves internally for the active subscreen, so that I avoid drawing over that; or so that I may draw over that, if I desire

 

I'd like to map out my drawing area with some degree of precision, to allow for more expansion later.

Edited by ZoriaRPG, 30 May 2014 - 05:26 AM.

[Saffith]

Should I have it in the function void SetCommonStyleData(int style) or in the void SetStyleSize(int style, int size) functions, or somewhere else?

SetCommonStyleData.
 

I know that something is using SetCommonStyleData, but I'm not yet sure what calls to that.

It's in the Init script.
 

The only reason I went with my own function, is that the freeze flag didn't seem to do anything, at all, when I had it in SetCommonStyleData.

I get that, but it'll get working sooner if we focus on fixing it rather than working around it.
 

If you played the game, beyond just testing the menu on the opening screens, those array errors could be from some other things that I'm working on at present, such as the NWS, and the RPG system. Both use arrays, and may have for loops with improper pointers, or something along those lines. (I didn't write all of them, and didn't 100% proof all the code.)

That much was just from the title screen. The size 28 array stuff seems to repeat every frame as long as the quest is running.
 

For future versions, i would suggest starting each Tagno entry with an Initialise instruction that includes user-defined styles, and allows the user to make templates, that they can call vis a discrete function, SetStyle, with a call to their user-defined style choice, for that tango slot, and only for that instance.

More user-defined arrays means more things that could break with future updates. And, in practice, it wouldn't be significantly different than having a dedicated style for each text slot and setting them up on demand.
 

You say that youc an draw 'very far' outside the screen. Do you (or does anyone) know the maximum offsets? I also don;t know if I can use negative values, and what the starting values represent.

The only limits are the limits on the numbers ZScript can handle. You can draw anywhere from -214748 to 214748 on both axes. 0, 0 is the top-left corner of the screen, and 0, -56 is the top-left corner of the passive subscreen.
 

What are the boundary points of the passive subscreen? -56Y to -1Y? That's an odd dimension, as it;s only 55 pixels, not 56. is it -57Y to -1Y for 56 (divisible by 8) pixels, or is there a one pixel overlay somewhere? (I assume that the X coodinates are 0-255, as with the screen.)

It's 56 pixels, from -56 to -1. I don't know why you're seeing 55.
 

Another good question: Are bitmaps stored at the same X/Y coordinates, on different layers, readable independently, and/or readable as a combined bitmap, preserving transparency?

Bitmaps have their own coordinate systems independent of the screen and each other. They can't be combined.
 

With a the normal screen area is 0-255 x 0-175, 256 is one pixel outside the horizontal boundary, and 127 is one pixel outside the vertical boundary. Is -1 on the X axis also outside the boundary, in the opposite direction of an axis, or even a valid coordinate for this? I presume that it is, and as such, we'd have plenty fo space for concurrent bitmaps, and thus, plenty of space for additional slots.

Drawing outside a bitmap is not useful. It will either do nothing or crash the game, depending on the version you're using.
 

Is there any space that ZC reserves internally for the active subscreen, so that I avoid drawing over that; or so that I may draw over that, if I desire

There's no way to draw on the active subscreen. Scripts don't have access to it at all.

[C-Dawg]

Well you can just replace the active subscreen entirely with Tango by intercepting a push of the "start" button and having a script handle it rather than letting the button press go through to ZClassic, right?

[Saffith]

You could do, that, yes.

[Timelord]

You could do, that, yes.

 

Sorry about the delays: I felt rather awful today, so I'll try to get this to you by Sunday evening. I may do it today, if my head stops throbbing.

[Saffith]

No need to rush for my sake. It's your project; take as long as you like.

[Timelord]

No need to rush for my sake. It's your project; take as long as you like.

 

I found the problem, and it was my fault: I was importing files from two different Tango repositories, and one of them didn't have the right values set, which naturally, was the one that I was accidentally using.

 

One thing that I don't yet know: Is this behaviour (below) intentional?

 

A dialogue, that does not start with an @choice, draws one character at a time.

A dialogue, with an @choice as the first line, displays all its text at one time?

 

I need to figure out what files I'm using for what, and clean my directory. I have two Tango directories, and I'm losing track on what files are being read by ZQ. When I moved the files into a clean directory, using only what I thought I was using, I discovered the problem, when the compiler halted with a 'file not found' error. On fixing that, my SFX went away, so i knew I was reading settings from two different areas.

 

Once I better figure this out, I may make an attempt at making a users manual, for establishing basic settings, and menu generation: necessity required me to learn a lot on how it works, and document it for myself, so that I don't forget.

 

I'm not sure if I'm using that modified function at present; only that it's working. I will need to re-clean my directories, and make a new main path, re-building my structure, so that I know with absolute certainty what I'm using. After a few weeks, things tend to become a spaghetti maze.

[Saffith]

One thing that I don't yet know: Is this behaviour (below) intentional?
 
A dialogue, that does not start with an @choice, draws one character at a time.
A dialogue, with an @choice as the first line, displays all its text at one time?

Yes. Currently, menus are drawn instantly, starting from the first @choice(). That may be made optional in the future, but for now, that's just how it works.