wunnibald

Wherigo.MessageBox{Text=[[You are holding ]] .. variablename .. [[ items.]],} or if the whole messsage is in a variable: Wherigo.MessageBox{Text=[[]] .. variablename .. [[]],}

Make each an (empty) OnEnter and OnExit event of your zone in the builder. Save the project an close the builder. Next open (with Notepad or similar) the .lua-File (the source file) of your project. Search for the OnEnter event of your zone and modify the code that it looks like this: zoneXYZ:OnEnter() ZoneXYZ.Description = [[You are in the zone XYZ now.]] end zoneXYZ:OnExit() ZoneXYZ.Description = [[What ist this?]] end Launch the builder and load and compile the cartridge. Test it in the emulator. The description of the zone should change on entering your zone.

We‘re getting off topic here. I don‘t think the images are the problem, but the number of references to them. The first thing I did was to shrink the images to an absolute minimum size (about 1 KB). No effect. But when I removed 120 image definitions from the source the restore bug was gone. However, I’m not sure if the size of the rest of the source file is also a factor. Overall my editor counts ~ 10,000 lines (including the blank ones) of code, which is quite a bit, I think. I am not an expert in memory architecture but it seems to me that somehow there were too many pointers/addresses in my code. No matter whether image, function or variable. Or I am completely wrong? The crashes can be reproduced both on Oregon as well as on the Colorado. So it seems that this is not a typical Oregon phenomenon. BTW: When I start the game from scratch I can play it through (outdoors of course) without any crash. I don’t really understand this. I really would like to know what's happening during a restore.

Thx for answering. - Hm, mysterious ‚nil‘-Command. BTW: I’m struggling with the problem that my cartridge gets unstable and crashes after a restore (maybe because the lua file is too big). Funny enough I was able to eliminate almost all the crashes, by setting all zones (approx. 80) to ‚nil‘ right after restore. Unfortunately I could not find a solution, how to avoid the crashes, when the Player is in the ‚Inventory‘ Section. So I downsized the project (dumped 120 pics ) and now the cartridge runs stable again after a restore.

... It's been a while since the last posting ... Because I do not get any further with my project, I looked once again at this great Whack-A-Lackey code hoping to find some inspiration. My focus was on dynamic zone building and especially on how to destroy zones before they get saved. I found this code: --Destroy all the previous zones and timers local allZones = cartWhackALackey:GetAllOfType('Zone') txt = txt .. "Zones: " .. table.getn(allZones) for _,zone in ipairs(allZones) do if zone.Name ~= "Cache" then zone.Visible = false zone.Active = false zone = nil end end I've played around a bit with it but I couldn't figure out what's the effect of this line of code: zone = nil Actually it should destroy the zone(s), or not? But it doesn't. In the emulator zones that have been set to 'nil' remain existing (not visible and inactive but existing) and they are also present in a later .gws file. So what is the purpose of this line of code? Enlightment would be very welcome. Thx.

Thx for the answer. As I didn’t even know that you can add commands to zones this can’t be the reason why my cartridge crashes every now and then. Generally my cartigde runs pretty stable but after a restore it is prone to crash. I wonder why (of course I’m already trying to bypass the known Oregon bugs that are mentioned in this and other threads of this forum).

What are 'zone-specific commands'?

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)?

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.

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.

Maybe you can post a screenshot of the error message?

Instead of making lot of words i uploaded a little cartridge to show you how i would do this. Everything can be done in the builder. Have a look at it. If you would like to adopt it you have to make sure that the OriginalPoint of the (invisible) 'PenaltyZone' is set to the coords you want the player to go to fetch his information. (In my example the item 'Ball' ist placed exactly on the penalty point when the player is entering the playing field). Hope you can replay this in the emulator. PointInZone.zip

Well, if you only have one option (i.e. button script) the second screen (in my example) is left out. In any other case you'll get the sequence I documented in the preceeding post. Doesn't matter if you have two, three or ten options. But maybe I have misinterpreted you (due to my poor english). Which screen do you mean by the 'ACTIONS' screen?

Thanks for the answer. I've already thought that you have to live with this. It's a minor thing. So it is not that bad.

Yep! Here it is:Kristall.zip

Ein Bild sagt mehr als tausend Worte . This ist the code: These are the screens: Screen number 3 (with the 'Answer'-Button) is not needed in this case. How can it be omitted? Is this possible at all?

Lets assume we have an item . There’s a button on it that says ‘Answer’. If I click (or tap) this button the input screen with the keyboard should appear. But Oregon/Colorado displays a MessageBox with an ‘Answer’- Button instead. Clicking this button displays the input screen. This seems to be standard behaviour. Is there any way to bypass this MessageBox and go to the input screen directly?

Yeah! This is it! MyText = 'This is the 1st line.\060BR\062\010This is the 2nd line.' Works on Garmin, Smartphone and Emulator (and probably PPC too). Thx.

I made a few trys now. But i couldn't get the compiler to snip the <br> tags. Anyway, this is not that bad. I only will test for the garmin devices and on smartphones that run OpenWIG/WhereYouGo (great stuff BTW, appreciating it very much). The rest probably will not run properly.

Thanks once again, matejcik. Now it's ok with the \n Where is the <br> needed (besides of the emulator)? In Pocket PCs? And how can I manage the different behavior? With conditional compiling?

I would like to include a line break into a variable. If I try this way ... function zitemServiceitem:OnLinebreakTest() MyText = 'This is the 1st line.<BR>This is the 2nd line.' Wherigo.MessageBox{Text=[[]] .. MyText .. [[]],} end ... the resulting text is shown as I want in the emulator, but not on my Garmin ... Also this code does not result in what I want: function zitemServiceitem:OnLinebreakTest() MyText = string.format('%s', 'This is the 1st line. /n This is the 2nd line.') Wherigo.MessageBox{Text=[[]] .. MyText .. [[]],} end I played around for while now and didn't find a solution. Anybody in here knows what's the right command?

OK. Thx very much for patience and for the code of course.

LOL - and your Wherigo.Messagbox function overrides the generic one?

The pattern of your example is perfect. That's what I'm intending to do. Sorry if I'm nerding around here. Just for my understanding: If I paste your code in the author script part of the file and i use MessageBox etc. in the builder like I always used to, your code will already come to effect without any further change in code (can't give it a try at moment)?

I'm trying to build dialogs out of if-then-else structures (sometimes with a question to answer at the end), so I think the answer is yes.