Jump to content

Garmin Oregon Freezing on my Cartridge


triga
Followers 1

Recommended Posts

I'm busy working on a cartridge to play a Cluedo-like game in my town.

The mechanics work fine on the emulator and on my Android Phone. We were able to finish a game yesterday with it.

We also wanted to test this with an Oregon.

This device showed the 2 intro messages without a problem but when it reached the standard Wherigo-screen (Zones, You See, Inventory and Tasks) it totally froze.

At that moment 6 zones are active and the player can see 6 persons and 6 items in the 6 zones. Is that too much or could it be my other code?

The weird thing is that the code for swapping items/persons and checking whether the combination is ok (which is pretty heavy) isn't called for yet at that point.

 

When a player enters a zones he'll get an Input window to swap the suspect/weapon and to check the combo. In a zone 3 tasks are also active which are, when clicked, made to do the same thing (swap and verify).

 

Some other facts:

* The outcome is random (done with random-number variables at cartidge.OnStart)

* The swapping code is VERY heavy (smartphone with old mid-end CPU runs it fine though)

* No Images yet included

* The input window that appears when entering a zone is there because the Colorado series can't do an OnClick (is that correct?, We had issues with a Colorado and Onclick in another Cartridge of ours)

 

Questions:

* Any ideas on how to make it work for the Garmin players?

* Is it possible to show the current inventory (as text in an input window?) (other than again working with 2 6-branch IF/ELSE statements based on variable numbers)

* Would it be the code, random variables or the amount of active zones and items causing the freeze?

 

If needed I can post the .urwigo file here, but I'd prefer not to if not needed.

 

Thanks in advance!

Link to comment

I read somewhere that you shouldn't have more than five zones active at any one time (can't remember where I read it). I have an Oregon and when testing a cartridge which is much simpler than yours, the unit gave up and had to be switched off and on again before it responded. It worked, ultimately, but only when I'd got rid of grandiose ideas and reverted to basics. Frustrating ain't it?

Link to comment

I read somewhere that you shouldn't have more than five zones active at any one time (can't remember where I read it). I have an Oregon and when testing a cartridge which is much simpler than yours, the unit gave up and had to be switched off and on again before it responded. It worked, ultimately, but only when I'd got rid of grandiose ideas and reverted to basics. Frustrating ain't it?

 

Very frustrating, especially since we don't have one ourselves to test it on.

The unit was completely locked up, rebooting didn't help. I believe 5 zones would be on the very low side as a limit.

Link to comment

Are there any OnEnter/OnExit etc. events firing until/at the moment the screen freezes?(BTW it's really a freeze or is the screen fading to gray?)

 

Oregon can definitely handle five active zones. I think ten zones is the limit.

 

No OnEnter/OnExit events at all at that point. It actually freezes, when you tap the options sometimes they become blue after about half a minute (as in selected) but still nothing happens

Link to comment

Sounds as if the device is busy. I know this behaviour, but in my cartridge after few seconds of lagging the menu is displayed.

 

Maybe Oregon doesn't like so many objects in the 'You see' section (there are 12 if I understand you correctly). Oregon behaves very strange under certain condidtions.

Link to comment

Six zones is getting near the limit. Also, make sure that you are not displaying any screen other than "Main", and don't show messages longer than about 850 characters.

 

I really need the 6 zones to be active all the time as the player has to run forth and back from them. They are very simple zones anyway (4-5 points) Perhaps the problem is indeed with the 12 objects that are visible. I will set them visible in proximity instead as a means of test. At the moment I'm doing a complete rewrite of all the code (from the graphical code from urwigo to real LUA) to make it ALOT more optimized, but at the point the oregon froze that huge chunk of code didn't even run yet. The longest messages displayed were around 400-500 characters.

 

As for the screens: The first 2 message screens ran fine, then it froze when showing the main screen. (I just exitted the message screens, did not call for any other screen)

Edited by triga
Link to comment

I made a fast cartridge and can reproduce the behavior. Six zones a character and an item in each and Oregon freezes (and works on Colorado BTW). With five zones and ten characters/items it works (although it's lagging).

 

Also removed all the items from the zones (six characters in six zones). Works fine.

 

Anybody has an idea where these limitations of the Oregon come from (I remember reading a discussion about it in this forum but I can't find it)?

Link to comment
Anybody has an idea where these limitations of the Oregon come from (I remember reading a discussion about it in this forum but I can't find it)?

Garmin wrote (or subcontracted) their player code to Groundspeak's definition, but didn't use Groundspeak's code base. They also didn't do a lot of testing. Wherigo isn't the most reliable platform in the history of computing, but Groundspeak's player code (as seen in the emulator and the PocketPC player) really isn't bad at all.

Link to comment

I made a fast cartridge and can reproduce the behavior. Six zones a character and an item in each and Oregon freezes (and works on Colorado BTW). With five zones and ten characters/items it works (although it's lagging).

 

Also removed all the items from the zones (six characters in six zones). Works fine.

 

Anybody has an idea where these limitations of the Oregon come from (I remember reading a discussion about it in this forum but I can't find it)?

 

Thanks for testing this, I do not have an Oregon myself so testing is rather hard.

It's no problem for me to make the items visible only when in or near the zone. (I actually set them visible so the testing would go faster).

I'm having MAJOR problems now re-writing my code. I did my first version in urwigo with graphical "code" and number variables but the tree is so huge that it even lags my PC (Quadcore with 8GB ram :P).

 

Anyone knows how you determine if an item is in the current zone? (I want to make the commands on the item visible when entering the zone, but also need the location to put into another function)

 

I tried: Item.Container, Item.CurrentDistance < 20 (meters I guess), and Item.Visible=True, but none seem to work (with container the result seems to be a table, and I don't know how to parse it to a string, I want the zone-identifier)

Link to comment
Anyone knows how you determine if an item is in the current zone? (I want to make the commands on the item visible when entering the zone, but also need the location to put into another function)

If by "current zone" you mean "the one that the player is in" then you can check if "MyCuteItem.Container:Contains(Player)" is true.

Link to comment
Anyone knows how you determine if an item is in the current zone? (I want to make the commands on the item visible when entering the zone, but also need the location to put into another function)

If by "current zone" you mean "the one that the player is in" then you can check if "MyCuteItem.Container:Contains(Player)" is true.

 

Exactly what I meant. Thanks!

Link to comment

Grrrr,

 

Now I'm having issues again. Example:

 

This is an globally defined array I use with all the characters in it.

 

tabeldader = {'zcharacterHendrikMus','zcharacterKarelSpecht','zcharacterMeneerDeRaaf','zcharacterMerelDeWitte','zcharacterMevrouwKievits','zcharacterTreesDeMees'}

 

I'm getting these outputs in the debug window:

 

print(tabeldader[1])  => zcharacterHendrikMus
print(tabeldader[1].Container) => nil
test = tostring(tabeldader[1]) print(test.Container) => nil
print(zcharacterHendrikMus.Container) => a Zone instance   (I guess this one is good) 

 

it appears that I can only call for the containers etc directly and not through a variable? If that is so, it's pretty bad :s

Link to comment
This is an globally defined array I use with all the characters in it.

No, it isn't. It's a table with a set of strings in it. Strings don't have a ".Container". Try removing the quote marks:

tabeldader = {zcharacterHendrikMus,zcharacterKarelSpecht,zcharacterMeneerDeRaaf,zcharacterMerelDeWitte,zcharacterMevrouwKievits,zcharacterTreesDeMees}

Link to comment
This is an globally defined array I use with all the characters in it.

No, it isn't. It's a table with a set of strings in it. Strings don't have a ".Container". Try removing the quote marks:

tabeldader = {zcharacterHendrikMus,zcharacterKarelSpecht,zcharacterMeneerDeRaaf,zcharacterMerelDeWitte,zcharacterMevrouwKievits,zcharacterTreesDeMees}

 

I got it working by changing my tables to zcart:GetAllOfType('Zone/ZItem/ZCharacter') but somehow those tables aren't always filled :s. Sometime they contain all the objects but most of the time only partially. Is this normal?

 

IF I get to finish this I'll probably release to sources as a help for others. There isn't much info around on the web about Wherigo so every little bit helps I guess...

Link to comment

Hi guys!

 

Here is my source code (the user written part).

 

masterclue.zip

 

I tried to document it well enough for people to understand.

Please note that this is my first "real" programming apart from a PHP script so excuse me for sloppy code/bad formatting etc :P

 

Thanks to everyone who helped my out in this thread.

Everything runs smooth now in the emulator and shouldn't be causing any problems on Garmin devices (reduced visible items drastically by only making them visible when entering a zone).

 

SIDENOTE: I wanted to post this in

 brackets so the forum search engine can pick it up, but I'm guessing it would be too much characters no?
Edited by triga
Link to comment

I read somewhere that you shouldn't have more than five zones active at any one time (can't remember where I read it). I have an Oregon and when testing a cartridge which is much simpler than yours, the unit gave up and had to be switched off and on again before it responded. It worked, ultimately, but only when I'd got rid of grandiose ideas and reverted to basics. Frustrating ain't it?

 

I've had cartridges I've built with 15. I was and will admit playing with [red]fire[/red]!

Link to comment

I read somewhere that you shouldn't have more than five zones active at any one time (can't remember where I read it). I have an Oregon and when testing a cartridge which is much simpler than yours, the unit gave up and had to be switched off and on again before it responded. It worked, ultimately, but only when I'd got rid of grandiose ideas and reverted to basics. Frustrating ain't it?

 

I've had cartridges I've built with 15. I was and will admit playing with fire!

 

Edit: Guess I can't use colors in the forums. Or, just haven't figured it out.

Link to comment

I read somewhere that you shouldn't have more than five zones active at any one time (can't remember where I read it). I have an Oregon and when testing a cartridge which is much simpler than yours, the unit gave up and had to be switched off and on again before it responded. It worked, ultimately, but only when I'd got rid of grandiose ideas and reverted to basics. Frustrating ain't it?

 

I've had cartridges I've built with 15. I was and will admit playing with fire!

 

Edit: Guess I can't use colors in the forums. Or, just haven't figured it out.

 

You can use colors using brackets and closing with [/color ][/color] ;-)

As for the zones, it seems to depend on other items aswell. 6 zones + 6 items + 6 characters appeared to be simply too much at once.

Link to comment
As for the zones, it seems to depend on other items as well. 6 zones + 6 items + 6 characters appeared to be simply too much at once.
That's why we say the number of active objects. Each object has a position associated with it and each object's distance to the player must be recalculated each time the thread that handles position calculations runs (this last part is my speculation as to the PDA Player's architecture; I'm assuming a multi-threaded, event-driven approach).
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 1
×
×
  • Create New...