Random Nikos questions

[Roody_Yogurt]

Yeah, I have code in Roodylib that runs after every new game, restore, or restart so this Hugor code will be going in there.

I was just thinking about how I'd like to handle clickable e-mails in menu pages. I find programs that use the mailto URI annoying most of the time, so I was thinking a better alternative would be to copy the text to the clipboard. In my cursory googling, I'm not seeing a URI for that. Is there one or would it require an opcode on your part (and if so, it's not so important that you should obliged to make one)?

[RealNC]

The clipboard opcode is in. I also added an opcode for setting/unsetting fullscreen mode.

I uploaded the new build (same url.)

I included a Hugo include file (hugoropc.h), for easy use of the opcode mechanism, where every opcode has its own routine. You can include that in Roodylib if you like, or completely take ownership of it and change it in whatever way fits Roodylib best.

[Roody_Yogurt]

Cool, yeah, I'm definitely going to add all of the same functionality along with a Hugofix (Hugo's debug mode) Hugor monitor for printing out opcode results. I may try to redesign it a little so it works off of object files and property routines, though (something I try to do when certain routines are unsure how many arguments they'll get).

Another opcode idea- informational pop-up windows? I was mainly thinking how it'd be nice to be able to pop something up that said "copied to clipboard" when someone clicks on a menu page e-mail link, but I can imagine it being used for other things, too. Ideally, one would be able to pick between a timed, disappearing window (like for the clipboard thing) and one that has to be closed.

No worries if it's not doable or currently worth your time. This opcode stuff is a great addition to Hugo games and I appreciate what you've done.

[Ice Cream Jonsey]

This is so cool, Nikos! I was away this weekend but I am going to try this out right now. Thank you!

[RealNC]

Note that since the opcodes are not part of the Hugo engine, they are not affected by undo points. You need to take care not to leave the screen faded out if the player does UNDO, RESTORE or RESTART. This is especially true with asynchronous fades, where the game goes on while the fade executes.

[RealNC]

Another opcode idea- informational pop-up windows? I was mainly thinking how it'd be nice to be able to pop something up that said "copied to clipboard" when someone clicks on a menu page e-mail link, but I can imagine it being used for other things, too. Ideally, one would be able to pick between a timed, disappearing window (like for the clipboard thing) and one that has to be closed.

Should be doable. There's quite a few other things I have in mind, like specifying the input caret shape (like underline and block) and blink rate, downloading files (can be used for game update checks, display of game-related news items, etc.), custom menu items, and generally stuff that helps games look more unique.

[Ice Cream Jonsey]

I found the Hugor repo on Github and I am now WATCHING the repo. I'll fork a local copy soon. I figure there ought to be someone else capable of understanding your wizardry here.

[RealNC]

Ah, yes. Any sufficiently advanced technology is indistinguishable from magic.

Now, multithreading is not really "sufficiently advanced technology", but let's pretend ;-)

[Roody_Yogurt]

Ah, I was wrong, adding mouse click support to menu page e-mails and web links won't work. I was forgetting the fact that while my clickable menu pages are written in monotype, the pages themselves are in proportional font which pretty much throws all cursor location stuff out of the window (whenever I've played along with it and hoped it'd be *close enough*, it almost never is).

I have added a HugoFix Hugor opcode monitor to Roodylib and have implemented most of the opcodes (well, they're all implemented but I'm undecided if I like the way I did a couple of them). I force games to reset their opacity after a restart or a restore (I think undo behavior will have to be left up to the author).

I also added Hugor version printing to the banner of any game using Roodylib's default DoVersion so it'll be an easy way for people to know if they're playing on an opcode-capable version of Hugor.

[pinback]

In this thread: Nikos doesn't let us down!

Let's RETURN THE FAVOR, folks!

[Roody_Yogurt]

Oh, and the clipboard thing doesn't seem to work under Windows, but considering I mainly wanted that for the e-mail thing which I couldn't do, that's no biggie.

[RealNC]

the clipboard thing doesn't seem to work under Windows

Oops. Should now be fixed. Same URL.

[Roody_Yogurt]

Awesome, yeah, that works for me.

I've got the opcode stuff all put into Roodylib, but I'm in the process of improving some other stuff and then I'll update the documentation for everything and put out some kind of release.

As far as the negative numbers bug from the other thread, I'll add it to the Hugo bug list at some point (i've somewhat gotten out of the habit of updating it):

http://develop.generalcoffee.com/hugo/trac/report/1

That list might also be a good source of inspiration for some other opcode ideas.

Anyhow, here are some opcode ideas I have:

• an opcode for saying whether a song is currently
• an opcode for changing default interpreter colors so authors have access to that whole range (ideally, it'd only affect the session- not permenantly changing the player's settings and there would also be an opcode for going back to the player's settings so we can allow players to turn off colors mid-game).
• an opcode for "pseudo-real time" games. I imagine it working like, every minute without any input, it automatically sends a "Z." command. I personally don't have any interest in designing a real time game, but I know some others have wanted to do that in the past.

In other Hugor feature request news, I think it'd be cool if there were a command line option to the interpreter that spits out a configuration file with Hugor's current settings (or blank, but I figured the current settings makes more sense). I'm always kind of unsure if I've missed any updates to configuration file options and that'd be a good way to always be sure one has everything.

[RealNC]

Good ideas. Except for the realtime thingy :-P The opcode mechanism should be for optional stuff. Games should still run on the official terp without issues.

[Roody_Yogurt]

So, I've implemented the opcode stuff into Roodylib as an object-based system with a feeder routine. Admittedly, it's kind of wasteful to not use constants for the opcode values, but since Hugo has a hard limit of constants that can be defined (and, as it is, the Hugo library and Roodylib already use up like half of them), I just want to always leave a bunch open in case people need them for their games for readability.

I've also felt a little guilty about how Roodylib often requires people to raise their routine max limit so I wanted to keep the routine numbers down (I'm actually in the process of reorganizing some other parts of Roodylib now, too).

When a game starts or is restored, Roodylib checks to see if Hugor is being used. If it is, it sets a hugor object as switchedon (and if not, clears it). This gives authors an easy way to tell if Hugor is being used at any point. At the same place, it also saves the version and port info to the following properties:

Code: Select all

object hugor "Hugor interpreter monitor"
{
	os 0
	version 0 0 0
	type settings
}

I've added Hugor version printing to the default game banner, so an author and player can see it in effect as soon as he starts a game:

GAME TITLE
Copyright 2016 by YOUR NAME
Hugo v3.1 / Library 31031 / Roodylib 4.1.2 / Hugor v1.0.99
Release 1.0 / Serial Number 033116
(New players type "INFO")

I don't include the OS there just because I figure it's not needed, but I do add it the beginning of beta transcripts:

This is a beta release! If you'd like to start a transcript right away, press B. Otherwise, push any other key to begin without starting a transcript.

Starting beta transcript for GAME TITLE (Hugor v1.0.99 Windows)

Here is the routine for running opcode files:

Code: Select all

routine ExecOpcode(op_file,str)
{
	if op_file.type ~= opcode
	{
#ifset DEBUG
		if debug_flags & D_OPCODE_MONITOR
		{
			print "[ExecOpcode run with non-opcode type object
			\""; op_file.name;"\"]"
		}
#endif
		return
	}
	writefile "HrCtlAPI"
	{
		writeval op_file.opcode_value
		if str
			writeval str
		if &op_file.execute
			run op_file.execute
	}
	local failure
	readfile "HrCtlAPI"
	{
		failure = readval
		if failure
		{
#ifset DEBUG
			if debug_flags & D_OPCODE_MONITOR
			{
				select failure
					case 10 : print "[Incorrect number of parameters for \
					opcode "; op_file.name; " ["; number op_file;"]"
					case 20 : print "[Hugor returned unexpected byte count \
					for opcode "; op_file.name; " ["; number op_file;"]"
			}
#endif
			return failure
		}
#ifset DEBUG
		if debug_flags & D_OPCODE_MONITOR
			print "[\""; op_file.name;"\" success.]"
#endif
		if &op_file.save_info
			run op_file.save_info
	}
	return
}

I may have to add more string arguments at some point, as I imagine the color-changing opcode might take at least a couple. Just the same, I think it's mostly set up to handle whatever an opcode needs.

Here is an example opcode file:

Code: Select all

opcode fade_screen "hugor fade screen opcode"
{
	nearby
	opcode_value 400
	block 0
	duration 0
	start_opacity 0
	end_opacity 0
	execute
	{
		! This just checks to make sure that somebody didn't accidentally
		! run ExecOpcode on this class object as it would hide all text on
		! the screen
		if self = fade_screen
		{
#ifset DEBUG
			if debug_flags & D_OPCODE_MONITOR
			{
				print "[Do not execute opcode
				\""; self.name;"\" itself. Create a fade_screen
				object with timing and fade values you want. Fade canceled.]"
			}
#endif
			return
		}
		local start_alpha
		start_alpha = self.start_opacity
		if self.start_opacity = -1
			start_alpha = -9999
		writeval self.duration , start_alpha, self.end_opacity, self.block
	}
}

The fade opcode is a little different than the others since I set it up to be an object class, so authors can just define whatever kind of fades they want and use those repeatedly. Since I figured authors will have different preferences for how long fades should be, Roodylib only defines a "restore to full opacity" fade object:

Code: Select all

fade_screen full_opacity "restore full opacity opcode"
{
	in fade_screen
	block 1
	duration 1
	start_opacity 255
	end_opacity 255
}

Roodylib executes that at every game start or restore just to make sure Hugor's opacity is not caught in a suboptimal place (I might eventually add that to UNDOs, too, but I thought that scenario might need a little more finesse depending on what the author is trying to do).

[Roody_Yogurt]

Oh, since that last opcode example doesn't show how "save_info" is used, here's another opcode:

Code: Select all

opcode getversion "hugor version opcode"
{
	in hugor
	opcode_value 100
	save_info
	{
		hugor.version = readval
		hugor.version #2 = readval
		hugor.version #3 = readval
	}
}

Anyhow, for the most part, not even authors will have to worry about this, as they'll just be doing stuff like:

ExecOpcode(getversion)
ExecOpcode(clipboard, "copy this to clipbloard")
ExecOpcode(open_URL, "http://www.google.com")
ExecOpcode(full_opacity)
ExecOpcode(fullscreen)

[RealNC]

I'd recommend using -9999 for the default start_opacity property value (-1 won't work due to the negative numbers bug) and true for the default block value, as these are the common values everyone would want by default.

[Roody_Yogurt]

Done!

[RealNC]

I added IS_MUSIC_PLAYING (800) and IS_SAMPLE_PLAYING (900). They return either false or true.

Also, when an opcode is not recognized, UNKNOWN_OPCODE (30) is returned, followed by the amount of parameters passed, followed by the parameters. For example, if you try to execute:

8888 11 22 33 44

What you get back is:

30 4 11 22 33 44

You can ignore this of course. It's there in case you want to print detailed debug information about what was actually passed to the interpreter that causes the error.

New build in the same URL.

[RealNC]

For example, if you try to execute:

8888 11 22 33 44

What you get back is:

30 4 11 22 33 44

Typo. You get this back:

30 8888 4 11 22 33 44