SBARINFO

[Nash]

This only works when status bar is on, correct? And that would mean the fullscreen HUD (when screenblocks > 10) isn't customizable?

[Graf Zahl]

You closed the topic before even taking a look at the code, and before Randy even said anything...

The topic didn't say anything about existing code and I have been unable to access skulltag.com today, thanks to my shitty ISP screwing up again (ZDoom.org is also slow as hell. ) Next time please write a little more instead of just posting a link followed by 'I want...'. That might give a wrong impression.

Would it make you happier if I moved the thread back?

[Nash]

Okay, sorry for the demanding tone of the original post. Yes, please re-open the suggestion.

Another question to Blzut: will it be possible to recreate the Heretic, Hexen and Strife status bars as well?

[Blzut3]

This only works when status bar is on, correct? And that would mean the fullscreen HUD (when screenblocks > 10) isn't customizable?

You can customize the full screen hud. In fact you have to. The only problem is the commands are a tad limited for creating a full reimplementation of the current Doom full screen HUD, but I hope for this to change in the future. This shouldn't stop you from creating something for the full screen HUD.

Another question to Blzut: will it be possible to recreate the Heretic, Hexen and Strife status bars as well?

Not yet. I do plan to continue updating SBARINFO to provide enough functionality to recreate all of the original status bars, but right now I need to work on some of my other projects. For now if you want to use the Heretic, Hexen, or Strife status bar as-is you can use the base command. As of right now the base command just sets the statusbar, but in the future it will load a recreation of the statusbar so you can add more to it.

Of course when that does happen I still won't be touching the *_sbar.cpp files since SBARINFO can't create a 100% accurate reimplementation I think (but it is pretty darn close).

[Graf Zahl]

Ok, skulltag.com works again after rebooting but I still can't get anything usable. The file in blzut's post is binary only hence useless and I can't access jimmy's link.

And Inventory overlay doesn't seem to exist at all judging from a quick test.

[Blzut3]

It is not binary only? I should have attached the source code with a diff later in the topic (with inventory stuff). Anyways I'll attach it here for you.

[Graf Zahl]

Thanks. Here's a list of problems I spotted:

- to select text colors you should check the actually present colors defined in TEXTCOLO, not some predefined names that might not necessary match.
- The return value of PClass::FindClass must always be checked against NULL. You can never assume that it returns a valid pointer.
- SC_ScriptError("Graphic names can not be greater then 8 characters long."); : Come on! You won't allow full path names inside a Zip/PK3???
- 'statusbar 1'? Wouldn't descriptive names like 'fullscreen_hud' better?
- You should make the inventory bar scriptable as well. Although normally it's just an overlay mappers might want to have the option to use customized graphics for that.

That said, my biggest issue is the syntax. You are using the simple Hexen parsing mode of SC_Man. I'd much prefer a more structured approach using at least C-mode but preferably the token-based parsing mode which is considerably more robust. All definition files parsed in Hexen mode exhibit some sort of structural problems because spaces are the only separator between tokens so I consider this important, especially since the SB definitions are not that trivial.

[Blzut3]

Thanks. Here's a list of problems I spotted:

- to select text colors you should check the actually present colors defined in TEXTCOLO, not some predefined names that might not necessary match.

Sure, but I assume the code could be accepted as is and updated later? Edit: I think I have this done.

- The return value of PClass::FindClass must always be checked against NULL. You can never assume that it returns a valid pointer.

I'm pretty sure every time I assume a valid pointer it has been checked before in the initial parsing so I don't see what the problem is? I suppose I can check it if I have to. EDIT: Ahh, I see where I made bad assumptions, those should be fixed.

- SC_ScriptError("Graphic names can not be greater then 8 characters long."); : Come on! You won't allow full path names inside a Zip/PK3???

I can point FImageCollection to full path names?! So should I just get rid of the limit and just send the whole string provided by the user?

- 'statusbar 1'? Wouldn't descriptive names like 'fullscreen_hud' better?

Yeah this is one of the things I was debating on, my original intentions were to allow statusbars that changed when the screen size was put smaller but then I found out doing so would make things harder. I'll get to changing this. Edit: Done

- You should make the inventory bar scriptable as well. Although normally it's just an overlay mappers might want to have the option to use customized graphics for that.

You mean to rename the graphics for things like ARTIBOX?

That said, my biggest issue is the syntax. You are using the simple Hexen parsing mode of SC_Man. I'd much prefer a more structured approach using at least C-mode but preferably the token-based parsing mode which is considerably more robust. All definition files parsed in Hexen mode exhibit some sort of structural problems because spaces are the only separator between tokens so I consider this important, especially since the SB definitions are not that trivial.

So you want me to change my use of stricmp into more SC_MustMatchString()s? Or am I completely missing the point? Edit: If I was correct then I converted the stricmp()s to SC_Compare()s where applicable.

[Graf Zahl]

- SC_ScriptError("Graphic names can not be greater then 8 characters long."); : Come on! You won't allow full path names inside a Zip/PK3???

I can point FImageCollection to full path names?! So should I just get rid of the limit and just send the whole string provided by the user?

No, but such a change to FImageCollection would be very simple to implement. So far it wasn't needed because it was only used internally.

- You should make the inventory bar scriptable as well. Although normally it's just an overlay mappers might want to have the option to use customized graphics for that.

You mean to rename the graphics for things like ARTIBOX?

I mean that the user can use a different (better matching) background for example. You'll need some additional functionality here to emulate Heretic's and Hexen's status bars which better integrate the inventory into the graphics. Only in Doom, due to lack of suitable graphics, the inventory is drawn as a simple overlay. For a customizable status bar this is not ok if it's the only option.

That said, my biggest issue is the syntax. You are using the simple Hexen parsing mode of SC_Man. I'd much prefer a more structured approach using at least C-mode but preferably the token-based parsing mode which is considerably more robust. All definition files parsed in Hexen mode exhibit some sort of structural problems because spaces are the only separator between tokens so I consider this important, especially since the SB definitions are not that trivial.

So you want me to change my use of stricmp into more SC_MustMatchString()s? Or am I completely missing the point? Edit: If I was correct then I converted the stricmp()s to SC_Compare()s where applicable.

No, that's not the point. The Hexen-style parser doesn't know anything about special characters, tokens etc. It treats any consecutive sequence of non-spaces as a string and as a result only spaces work as separators. But this severely limits the options. It'd be better to use a token based parser and use commas as separator between arguments. That way you could implement optional parameters or other enhancements later.
DECORATE suffers from this problem as well because it was initially written for the same parsing mode. I'd like to get rid of these limitations but it's too late for that due to backwards compatibility.

[Blzut3]

No, but such a change to FImageCollection would be very simple to implement. So far it wasn't needed because it was only used internally.

I guess I'll see about changing that then.

I mean that the user can use a different (better matching) background for example. You'll need some additional functionality here to emulate Heretic's and Hexen's status bars which better integrate the inventory into the graphics. Only in Doom, due to lack of suitable graphics, the inventory is drawn as a simple overlay. For a customizable status bar this is not ok if it's the only option.

I was planning on implementing features in the order of Doom > Heretic > Hexen > Strife, so more styles are to come. This is why Doom has to be specified after inventorybar right now even though it is the only option. Additionally statusbars 4 & 5 (now called inventory and inventoryfullscreen) act as an overlay to the other statusbars when the user is using the inventory bar. For example:

Code: Select all

statusbar inventory
{
  drawimage INVBAR 0 168
  drawinventorybar Doom 7 INDEXFONT 50 170
}

Would allow something similar to what Heretic and Hexen do right now.

No, that's not the point. The Hexen-style parser doesn't know anything about special characters, tokens etc. It treats any consecutive sequence of non-spaces as a string and as a result only spaces work as separators. But this severely limits the options. It'd be better to use a token based parser and use commas as separator between arguments. That way you could implement optional parameters or other enhancements later.
DECORATE suffers from this problem as well because it was initially written for the same parsing mode. I'd like to get rid of these limitations but it's too late for that due to backwards compatibility.

Does ZDoom currently have such a parser? If not, I believe that it would be better to leave complex statusbar scripting to DoomScript. The idea behind SBarInfo is to provide something slightly better than ACS statusbars (since they can not play with the inventory bar or the mug shot).

[Graf Zahl]

Code: Select all

statusbar inventory
{
  drawimage INVBAR 0 168
  drawinventorybar Doom 7 INDEXFONT 50 170
}

Would allow something similar to what Heretic and Hexen do right now.

Mostly, yes. I'd have to run some tests though. For a first step it's enough.

No, that's not the point. The Hexen-style parser doesn't know anything about special characters, tokens etc. It treats any consecutive sequence of non-spaces as a string and as a result only spaces work as separators. But this severely limits the options. It'd be better to use a token based parser and use commas as separator between arguments. That way you could implement optional parameters or other enhancements later.
DECORATE suffers from this problem as well because it was initially written for the same parsing mode. I'd like to get rid of these limitations but it's too late for that due to backwards compatibility.

Does ZDoom currently have such a parser? If not, I believe that it would be better to leave complex statusbar scripting to DoomScript. The idea behind SBarInfo is to provide something slightly better than ACS statusbars (since they can not play with the inventory bar or the mug shot).

[/quote]

Yes, it's fully implemented. Instead of using SC_GetString, SC_GetNumber etc. you use functions like SC_GetToken, SC_CheckToken etc. Parts of the DECORATE parser use these functions. If you search the source for TK_ you should find enough code to see how it works.

[Blzut3]

I added support for bars since I had to kill time while waiting for Graf's reply. So the last 2 things (zip support, and switching the parser to using tokens) are not done yet.

http://blzut3.maniacsvault.net/sbarinfo-docs.txt - documentation
http://blzut3.maniacsvault.net/zdoom-sbarinfo4.zip - compiled binary (The latest source code is available for internal testers on skulltag)

Graf, for zip/pk3 support I need to change the function FTextureManager::AddPatch(const char *patchname, int namespc) to use CheckNumForFullName(const char *name) if the initial call to CheckNumForName() fails right?

Edit: Wait, that wouldn't work right. I would need to check in AddPatch if the name is more than 8 characters long or has slashes. Otherwise it would shift into the global name space and probably wouldn't be a good idea.

[Graf Zahl]

Graf, for zip/pk3 support I need to change the function FTextureManager::AddPatch(const char *patchname, int namespc) to use CheckNumForFullName(const char *name) if the initial call to CheckNumForName() fails right?

Do it the other way around. First full names, then lump names. Otherwise you may get false positives. You also need to do some checks for the lump name.

Here's the DECORATE code for #include that's doing the same thing:

Code: Select all

			lump = Wads.CheckNumForFullName(sc_String);

			// Try a normal WAD name lookup only if it's a proper name without path separator and
			// not longer than 8 characters.
			if (lump==-1 && strlen(sc_String) <= 8 && !strchr(sc_String, '/')) 
				lump = Wads.CheckNumForName(sc_String);

			if (lump==-1) 
				SC_ScriptError("Lump '%s' not found", sc_String);

[Blzut3]

I suppose I should just leave the modifications of AddPatch to you or Randy. ZDoom is crashing out when I change the code to use:

Code: Select all

	lumpnum = Wads.CheckNumForFullName (patchname);
	if (lumpnum == -1 && strlen(patchname) <= 8 && !strchr(patchname, '/'))
	{
		lumpnum = Wads.CheckNumForName (patchname, namespc==ns_global? ns_graphics:namespc);
	}

I attached the latest code with includes the change to the token parser. Arguments are now separated with commas, and terminated with semicolons. Any reference to and image names are enclosed in quotes. The size limit error is commented out so it shouldn't need any modifications when full path support is added.

http://blzut3.maniacsvault.net/zdoom-sbarinfo5.zip - Compiled Binary
http://blzut3.maniacsvault.net/sbarinfo-docs.txt - Lastest Documentation (Revision 3)

[Lemonzest]

Could this be used to make the Boom hud? where the health/ammo etc numbers change colour to indicate there levels?