Template Game Bug Fixes

[Cloudee1]

With a little board reorganization taking place, it makes much more sense to keep all of the template games fixes in a single thread. Especially now, with the release of an updated sci companion and a partially updated template. This first post, solely represents the necesary edits to get Brian's original template game to the same point as Troflip's version.

* This info can currently be found in sci companions help file in the compiler overview section.

Gauge.sc, line 112:

Code: [Select]

= ctlX (- (- nsRight (send btnCancel:nsRight) 4) )
should change to

Code: [Select]

= ctlX (- (- nsRight (send btnCancel:nsRight) ) 4)

SysWindow.sc, line 579:

Code: [Select]


(procedure (IsSaveDialog)
should change to

Code: [Select]

(procedure (IsSaveDialog) of SRDialog

Jump.sc, line 62:

Code: [Select]

= xStep ((send client:xStep) neg)
should change to

Code: [Select]

= xStep (neg (send client:xStep))

Controls.sc, line 387:

Code: [Select]

(+ text (* x position))
should change to

Code: [Select]

return (+ text (* x position))

Cycle.sc, line 32:

Code: [Select]

(+ (send client:cel) cycleDir)
should be changed to

Code: [Select]

return (+ (send client:cel) cycleDir)


[Cloudee1]

Setting Inventory views to any cel, loop, or view

While trying to set the inventory items instance found in the main script, you will find that no matter how you set the loop or cel, only loop 0 and cel 0 is shown.

To fix this bug, we simply need to change a couple of the default variable values found in the Iitem of InvI class found about halfway down the main script. In the showself method, the default inventory icon variables manually set the cel and loop to 0, just like it's doing. If you would like to be able to set these variables via the instance of the item located at the bottom of the main script, we simply need to change the zeros to loop and cel respectively.

In main.sc

Code: [Select]

...
(class Iitem of InvI
    (properties
    said 0
    description 0
    owner 0
    view 0
    loop 0
    cel 0
    script 0
    )
(method (showSelf)
    Print(
    description
    #title objectName
    #icon view loop cel // Changed from: #icon view 0 0
    )
  )
)
...
* This bug has been fixed as of template version 1.1 found on the tools page.

[Cloudee1]

A small typo in the doit method of timer class

This is actually a small snippet from Lars' post on how to use timers. Just in case your looking for a bug free template and you happened to overlook that post I'd thought that I'd copy it to here as well.

...

There's the setReal method. Like set, it
performs all calculations on its own, but it uses the seconds
counter, and it does not adjust for game speed. Thus, it is
ideal for game events that depend on how much "real time" passes.
However, it does not work out of the box due to a typo in the template
game. To fix it, find the doit method of the timer class (in
Timer.sc), and the line that says:

Code: [Select]

(if (not seconds)
    CueClient()
)
Fix the first line so it reads:

Code: [Select]

(if (not --seconds)
* This bug has been fixed as of template version 1.1 found on the tools page.

[Cloudee1]

I have gone ahead and updated the standard template with all of the bug fixes that I currently know about and have uploaded it to the tools page. As of now, Parser Template v. 1.1

The point and click template has also been updated to reflect any bug fixes, even though most of them had already been fixed. I did tidy up just a hair and have uploaded the latest version of it too. With any luck, I hope to keep the versioning relatively close together. So Point and Click Template v. 1.1 is ready and available. If you haven't checked it out in a while, take a peak. I seriously need to rewrite the pnc tutorial as it is absolutely nothing like the template that is available now.


Changes:
Toggle Sound issue fixed.
DisposeLoad typo fixed... Change Load to Unload in disposeLoad.sc
Program/Playercontrol fixed.
Timer class typo from this thread fixed.
Inventory class from this thread fixed.

[gumby]

Did you add the fix for the jumping bug?


* Bug fixed in both parser and pnc templates as of version 1.1a

[Cloudee1]

What's the jumping bug?

[gumby]

Here's the 'jumping bug' thread:

http://sciprogramming.com/tutorial/tchapter5.html

[Collector]

Yet one more reason that I think Brian chose the wrong game to base the template on, along with other things I have noticed. Some games have a jump action built into them, accessible from the in-game menu.

[Cloudee1]

I have fixed that bug now... 

Both current Template versions are now set to 1.1a

[gumby]

Got another one, in menubar.sc:

Code: [Select]

...
SetMenu(MENU_QUIT smMENU_SAID 'done[/game]')
SetMenu(MENU_PAUSE smMENU_SAID 'delay[/game]')
SetMenu(MENU_INVENTORY         smMENU_SAID 'all')

Doesn't make any sense that 'all' should open up the inventory screen.  I think this is a bit more appropriate:

Code: [Select]

...
SetMenu(MENU_QUIT smMENU_SAID 'done[/game]')
SetMenu(MENU_PAUSE smMENU_SAID 'delay[/game]')
SetMenu(MENU_INVENTORY         smMENU_SAID 'inventory')

The vocab also needs to include 'inventory' as a verb.

[Collector]

The vocab also needs to include 'inventory' as a verb.

It is odd that Brian ripped that one out.

[Cloudee1]

Here's one that I know is coming... at the same time that I was moving the site to the new server, Gumby posted about the game speed and clicking the normal speed button. In that, the games default speed is not the "normal" speed when selected in the menubar. To see it all you have to do is open a new game, select speed and then select "normal" and the gauge moves and you wouldn't think that it should. Since afterall, shouldn't the default speed be the normal speed?

There are two approaches to fix this issue, which is really more of consistency than an actual bug. Your approach will depend entirely on your personal preference.

You can edit the initrooms script which is where the initial game speed is set. By default it is set to 6

Code: [Select]

(method (doit)
   (super:doit())  
(send gGame:setSpeed(6))
...

Now, to my understanding this essentially builds in a wait 6 cycles kind of deal. So to speed up the game from the start, you could set this to 0 and the game will run as fast as it is going to. 15 I believe is the max, setting it to 15, slows the game down as it builds in an extra 15 cycles of nothing happening. So really in essence don't think of the gamespeed as a speed, but more so, think of it as a delay.

The problem with the normal button comes in as a result of the game.sh file. The menubar script makes a call to NORMAL_SPEED which is defined in the game.sh file.

Code: [Select]

// Defaults
(define NORMAL_SPEED  8)

As is, the variable is defined as 8, which actually gives us a game speed, or I guess delay would be the better word to use here, of 7. The menubar script takes the gauge value and subtracts it from 15 to determine the actual game speed to be utilised. Because as described above 0 is the fastest and 15 is the slowest. That however is kind of counter intuitive to a visual gauge.  

So, the inconsistency comes in because the normal_speed variable being set to 8 gives us a game speed of 7 and the init rooms script sets the default speed to 6.

To fix it, either change the init rooms script to set a default speed of 7, which will give you a slightly slower game from the start, but match the result of pressing the normal button as defined in game.sh, or change the NORMAL_SPEED defined in game.sh to 9 which will cause the normal button in the game speed menu option to produce a game speed of 6 when pressed (15-9). Either way.

You will need to compile all scripts and rebuild if you go with changing the game.sh value. Otherwise you will think I am crazy as it doesn't appear to load the changes otherwise.  

[Collector]

It seems like the normal speed of the template should match that of the initial speed of the game. If a dev wants a different default he could change it at the points you mention.

[Cloudee1]

Code: [Select]

...
SetMenu(MENU_QUIT smMENU_SAID 'done[/game]')
SetMenu(MENU_PAUSE smMENU_SAID 'delay[/game]')
SetMenu(MENU_INVENTORY         smMENU_SAID 'inventory')

The vocab also needs to include 'inventory' as a verb.

Are you sure that inventory needs to be a verb? I am in the template now and "all" and "inventory" are both in there under the same entry. It is currently just set as noun. I would think that if "all" currently works then "inventory" would also work just fine as is.

[gumby]

For examining inventory from the menu, it doesn't make a difference.   In this context I think I was thinking about when the player issues a command 'inventory' from within the parser.  Just typing 'inventory' won't work if it's not also classified as a verb.

That's how I always open up my inventory in text adventures (just typing 'inventory'), so I'm sure I just carried it over from my experiences there.  Since a command like 'examine inventory' works just fine and is syntactically more correct, I concede that it really doesn't need to be a verb