Detecting the zone currently occupied by the player - how?

[+Team Microdot]

Completely new to building Wherigo's but a few years IT experience under my belt and not bad at programming generally - but I've very quickly run up against a brick wall

 

I want to do something a bit more complex than a tour guide style cartridge - I want to have characters and items to interact with.

 

Not wanting to dive into LUA? coding at this early stage, I thought I would cut my teeth on the Earwigo builder - it seems to work very well

 

Thought I would begin with something simple - replicate the classic fox/chicken/grain puzzle as the basis of being able to move objects from one zone to another and do some relatively simple if/then stuff.

 

Got the first half done no problem - two zones, three items - fox/chicken/grain - and the ability to pick up each one from Zone A and move them into the player's inventory - the Earwigo web interface made that part easy

 

Dropping the items again was another thing altogether I fully expected to be able to move the items out of the inventory and into some simple system variable such as PlayerCurrentZone or something - but nope

 

If such a system variable does exist, it isn't presented as a target option via the Earwigo interface - my only options are the two zones I've created. Problem is of course that I need to be detecting which zone the player is actually in so that my Drop command places the items in THAT zone.

 

Am I trying to run before I can walk?

 

Does such a system variable exist?

 

Do I need to start hand-cranking LUA code?

 

Help gratefully received

[+redsox_mark]

I don't know if there is such a system variable.

 

One way to do it would be to create a variable of your own (e.g. CurrentZone), and when you enter a zone you set CurrentZone to the name of the zone (or a digit, or whatever you want). Then you have an IF statement check the value to know where to drop. That would not require handcoding lua.

[Ranger Fox]

I am not aware of any convenient "PlayerCurrentZone" function or attribute on any object.

 

In essence, you'll have to determine if the player is in each individual zone. It IS possible to create a function for that, though:

function PlayerCurrentZone()
    for _,z in ipairs(zcart:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end

In the above, you'll have to replace "zcart" with your cartridge's object.

 

It's easily possible to create what you're after without using this. In fact, I had a little fun tonight and created a fully functional Fox, Chicken, and Feed cartridge. I assume you don't mind looking at author script, so almost all the functionality is contained therein. I also included a few fun Easter eggs since this is a demo. I just couldn't help myself.

 

Have fun! If you have any other questions, please ask. If you'd like to critique my odd sense of humor, let's do it over barbecue chicken--your treat!

Fox and chicken.zip

[+Team Microdot]

Thanks Ranger Fox - that looks like really good learning materials for me

 

I am making reasonably good progress doing it my way - but my coding, while functional, is pretty ugly compared to yours

 

Can I take it that you hand-cranked the code rather than used something like Earwigo?

[Ranger Fox]

Ha, ha! Yes, I really enjoy writing cartridge code by hand. I use Groundspeak's Builder to set up the cartridge's objects and some event stubs, then I write the functional code by hand.

 

I'd you'd like to learn more about coding in Wherigo, I highly suggest you look at the code in my Battleship cartridge. While not as overly complex and well-known as Whack-A-Lackey, it's cleaner and well-commented. If you'd like, feel free to look at both. I was learning and experimenting when I wrote Whack-A-Lackey and didn't write it with the intent of letting others see the code. Thus, it's disorganized and is certainly not clean. I open-sourced the cartridge, anyway, to show how the magic was done. I was never happy with how the code looked in that one. Later, I created Battleship with the intent of people looking at the cartridge's code and learning from it. Thus, it's cleaner, organized, and very well-commented. This is why I suggest it over Whack-A-Lackey these days. I mention both to you, though, so you can see how my style has changed.

 

Well, have fun looking and learning. Please feel free to post any questions you may have to the forum!

[+redsox_mark]

I enjoyed playing Ranger Fox's game!

 

I did have the thought that a player can be in multiple zones (as they can overlap); so a simple "PlayerCurrentZone" that returns just one zone name probably isn't available.

[+Team Microdot]

I do already have a couple of questions as it happens - one relates to this thread so I'll ask it here.

 

I'll use the context of building web pages to illustrate the point I'm trying to make in the question.

 

I like using GUI based web development tools for certain things - particularly those things GUI based tools are good at (don't ask me to cite examples - my head is already too full today)

 

I also like hand coding in notepad and that ability also helps when I'm building HTML based cache pages too

 

I'm not incredibly adept at either, but by combining and switching between the two, I generally end up with the desired results.

 

In that scenario, I find it very easy to switch between the two - and see the changes I've made in either, replicated fairly instantaneously in the other.

 

When I look at Earwigo though (the only tool I've used so far for building cartridges - and only for a couple of days at that), I can't see any easy way to drop out into a text editor to make changes and see them reflected in Earwigo when I come back to it.

 

(I realise this question might be better asked of the author of Earwigo, but I expect there are plenty on here who have used it for long enough to be able to provide a useful answer)

 

For example - say I have a bunch of 8 items, and I want to have same/similar item command code on each. I'd like to be able, maybe, to construct the bones of it using the point-and-click interface of Earwigo, but then drop down into a text editor and simply copy and paste that block of code however many times I need it and then tweak each individual instance of the code to suit the particular purpose intended for it. To me, that would be a lot quicker than doing each one in the point-and-click interface.

 

So, does anybody know if/how I could so something like that?

 

Part of me says I should just dig in, learn Lua code and do everything by hand - but I'm too impatient so I have to 'hack' my way through things - which is probably what leads to my code being so ugly

 

I know I can export the Lua code from Earwigo - that came in handy last night when my code didn't work and I was able to discover that a line of code visible in the Gui was for some reason missing completely from the Lua, and I know there's an import feature too - but that appears to be greyed out for me.

 

Maybe once I learn to code properly and use open-ended functions instead of item specific code it won't matter anyway

Edited March 9, 2012 by Team Microdot

[Ranger Fox]

I'm at work at the moment, and the question as to how you can mix Urwigo with author script would require me to play around with it. I'll have to wait until this evening to get that opportunity. I thought it was accessible, though, from one of the top menus in Urwigo. Can someone help with this question, please?

 

@redsox_mark: Due to my handle, I couldn't resist the jokes I could make with the game's scenario. Just try leaving the chicken with something. And in the code, one function name in particular is a joke. Since I photographed my avatar myself, I have plenty of photos I can crop however I desire. (On a side note, I do have a proper Groundspeak volunteer pixel icon, but use my own because I made it myself.)

[+tozainamboku]

On reason that their is no current zone is that zones can overlap or one zone can be inside another zone. So the Player may be in more than one zone at a time. I don't think that other objects can be in more than one zone.

[+Team Microdot]

...In fact, I had a little fun tonight and created a fully functional Fox, Chicken, and Feed cartridge. I assume you don't mind looking at author script, so almost all the functionality is contained therein. I also included a few fun Easter eggs since this is a demo. I just couldn't help myself.

 

Have fun! If you have any other questions, please ask. If you'd like to critique my odd sense of humor, let's do it over barbecue chicken--your treat!

 

Read through the code and while your programming is more elegant, it looks like it works in a very similar fashion to what I've cobbled together so far.

 

There's one section of code though that has so far outfoxed me (you see what I did there? )

 

It's the ZoneEnter function - it seems counter-intuitive (to me) which is why I can't seem to fathom it

 

Could you explain it a little in plain English for those of us less gifted in the arts please?

 

One thing I can't quite work out is why you are, apparently, disabling the Pickup buttons on the basis of entering a zone????

 

I also don't understand the check for Player:Contains(zitem) OR PlayerHasAnItem - aren't they both true at the same time??

 

Sorry if I'm being a bit slow

[Ranger Fox]

The ZoneEnter function:

It's better if you look at it from the other way around. When the player left the zone, I needed to disable the "Drop Off" command from what s/he was holding so the player didn't drop it anywhere. To do this, I created the "ZoneExit" function. For convenience and simplicity's sake, I disabled all the events, then performed the check for if the player made a mistake, the oddly-named "DoesRangerFoxEatTonight" function. Now, about entering a zone: When the player enters a zone, I wanted to enable the "Drop Off" command only on the item the player was holding. Likewise, if the player was not holding an item, I needed to enable all "Pick Up" commands on items within that zone. I did not want to create several if/then statements or clutter the demonstration code with too many lines. Thus, I decided to keep it simple and use the same logic on each item without performing if/then statements for the item's location. Thus, the "Drop Off" command is enabled if the item is in the character's inventory and the "Pick Up" command is enabled if the player does not have the item AND if the player doesn't have any item--the latter being determined by the "PlayerHasAnItem" function). Thus, my "ZoneEnter" function is short and easy to read, two very good things for demo code.

 

Disabling the "Pick Up" command:

I mentioned it in the above paragraph, but I'll answer it clearer here. In the game, you're only supposed to be able to transport one item at a time. Thus, at some point, you're going to have to do something to enforce this. You could have, instead, performed a check in the player's inventory when s/he left a zone for the number of items s/he was carrying. This leads to headaches as you'd then have to disable the other zone, force the player back into the previous, get him/her to drop off an item, then do another check as the player left that zone so you could enable the other one. I didn't want that. Thus, the "Pick Up" command's state is adjusted when the player enters a zone and after s/he performs a pick up of drop off action. The end result of this is the player can only pick up one item at a time and cannot drop off an item s/he doesn't have. I made gratuitous use of the "ZoneEnter" function to enforce this. It may have been better called "SetItemCommandStates", but I left the original name as I had it.

 

Player:Contains versus PlayerHasAnItem:

You're partially right. I should have just used "not PlayerHasAnItem" as that would have had the desired effect. However, these two Booleans are not the same. The first asks if the player has a specific item and the second asks if the player has any item. Since "Pick Up" should be disabled while the player has an item in his/her inventory, calling "Player:Contains" is not necessary. I didn't notice at the time I could have just used "not PlayerHasAnItem" because I created that function later on.

[+Team Microdot]

Thus, my "ZoneEnter" function is short and easy to read, two very good things for demo code.

 

I didn't find it easy to read - still can't follow it

 

I think I may have taken a slightly different tack.

 

Picking up any item immediately disables all the Pickup Item buttons - preventing more than one item being picked up at a time.

 

Dropping an item moves the item to the zone the player is in, unless they are in no zone in which case a message is displayed telling them that they cannot drop the item there.

 

When an item is dropped, all the Drop Item buttons are disabled - can't drop anything if you're not carrying anything - and all the Pickup Item buttons are enabled again.

 

This is all done within the code linked to the associated item commands - don't have any separate functions as I'm not up to speed enough with the syntax yet to write any.

 

I don't bother checking inventory - I just assume that a successful Pickup Item command means there will be an item in the inventory, and a successful Drop Item command means it will be empty, given that I've prevented the picking up of more than one item at a time.

 

Thus all the command buttons are interlocked to each other, rather than linked to anything to do with entering or exiting zones.

[Ranger Fox]

Oh, okay. I thought you were referring to what I was doing within the logic test and not the thing overall. I'll provide a more thorough explanation. I don't know where you are with your understanding of lua and how it relates to the Wherigo Player, so I'll start from scratch if that's all right with you.

 

Let's say the player enters the west side zone. The Wherigo Player will fire the zoneWestSide:OnEnter() function. This is the entry point. I then call my ZoneEnter function and pass a reference to the west side zone (zoneWestSide) so my ZoneEnter function knows which zone the player entered. My ZoneEnter function is separate from the rest because I want to reuse the same code between the two zones. In ZoneEnter, I set each item's commands' enabled states. The item commands are what you see as the buttons in the UI. Setting a command to enabled means the player will see the command when s/he clicks on an item, and the opposite for disabled (that is, enabled being false). And, now, we come to how I'm assigning the enabled value. The first argument, "Player:Contains(zitemFeed)" asks the Wherigo engine if the player currently has the zitemFeed item (the name comes from the Bulder's naming convention) in his/her inventory. When Wherigo puts something in a player's inventory, it's represented on the back end as putting the item in the Player object. The PlayerHasAnItem call does much of the same thing, testing to see if a player has any of the three items. Finally, a "not" logic operator outside both tests flips the value because the command should be enabled only if the player does NOT have an item in inventory. I should have simplified that line to be "zitemFeed.Commands["PickUp"].Enabled = not PlayerHasAnItem()".

 

And comments on what else you said:

"Picking up any item immediately disables all the Pickup Item buttons - preventing more than one item being picked up at a time."

-- I do the same thing with what I wrote, but I go so far as to disable all the drop off commands save for the item currently in inventory.

 

"Dropping an item moves the item to the zone the player is in, unless they are in no zone in which case a message is displayed telling them that they cannot drop the item there."

-- Same here for the first part. Since I'm using a ZoneExit function and disabling the commands on exit, I don't have to worry about a player dropping an item outside a zone.

 

"When an item is dropped, all the Drop Item buttons are disabled - can't drop anything if you're not carrying anything - and all the Pickup Item buttons are enabled again."

-- That makes sense for both of us.

 

"This is all done within the code linked to the associated item commands - don't have any separate functions as I'm not up to speed enough with the syntax yet to write any."

-- That's fine. I was trying to avoid reusing code since you have to check the same things regardless of which zone the player is in.

 

"Thus all the command buttons are interlocked to each other, rather than linked to anything to do with entering or exiting zones."

-- This is a stylistic difference in how we both view the cartridge. It's nothing bad, doing it one way over another as long as it works, is maintainable, and looks sane. In fact, having two different viewpoints is a good thing because it gets both people thinking about how else it could be solved and the pros and cons of each way. By no means will I ever in this forum say I have the only right answer and someone should do something my way. If someone challenges what I write, it's to my own benefit because I might end up being the one who learns the most from the exchange.

[+Team Microdot]

So...

 

zitemFeed.Commands["PickUp"].enabled = not (Player:Contains(zitemFeed) or PlayerHasAnItem())

 

Checks if the Feed item is in the player's inventory?

Checks if the player's inventory contains ANY item?

And DISABLES the pickup button for the Feed item if EITHER of those tests = true?

 

Am I getting there?

[Ranger Fox]

That's right. I think you have it, but to be specific just to make sure you do:

zitemFeed is the item.

zitemFeed.Commands holds all commands associated with this item.

zitemFeed.Commands["PickUp"] is the pick up command. I've also seen it referenced in Groundspeak's spaceship demo cartridge using the style zitemFeed.Commands.PickUp.

 

Player:Comtains(zitemFeed) checks to see if the player has zitemFeed in his/her inventory.

PlayerHasAnItem calls my function that checks to see if the player has any item in inventory. I can use it in this way because the function returns a true/false value.

 

not reverses a true/false (Boolean) value to its opposite. In C#, my main programming language, it's an exclamation point. So, yes, the command will be disabled if EITHER of the tests is true because I put both tests within parenthesis and used a logical OR operator between them.

 

Thus, you can read the statement like this: "zitemFeed's PickUp command will be enabled when both the player doesn't have zitemFeed in his/her inventory and the player doesn't have any item in his/her inventory."

 

As I mentioned before, I should have written it as zitemFeed.Commands["PickUp"].Enabled = not PlayerHasAnItem(), which would be read as "zitemFeed's PickUp command is enabled when a player does not have an item in his/her inventory." (Somehow, I don't think I'm going to live that oversight down for this thread's life...)

 

-----------

 

Welcome to the wonderful world of author script! You'll find there are some things easier to do in a builder and others easier if you edit the lua yourself, then reload it in a builder. There will always be, of course, some things you can't accomplish using a builder. The more you do this, the more you'll develop your own style and preferences that work for what you like to do. Just please make sure to test what you create by loading it onto a couple Players (upper-case to denote a Player application and not a player person) before publishing your cartridge! The more custom work you do, the more you'll need to make sure all the Players can handle it. Nothing turns people in an area off to something new faster than hearing of others who have had problems.

[+Team Microdot]

As I mentioned before, I should have written it as zitemFeed.Commands["PickUp"].Enabled = not PlayerHasAnItem(), which would be read as "zitemFeed's PickUp command is enabled when a player does not have an item in his/her inventory."

 

I do find that easier to read, but I can follow the original code better now that I know what constitutes a 'line' of code within that block.

 

I think in the original code that line straddled two lines visually, so I was struggling a bit to know for sure which bits belonged together - sorry

 

It all makes much more sense now - thanks for the clarification

[Ranger Fox]

I think in the original code that line straddled two lines visually, so I was struggling a bit to know for sure which bits belonged together - sorry

Word wrap isn't a good thing when looking at code. I also prefer indenting my code so I can scan it faster with my eyes.

[+sTeamTraen]

I also prefer indenting my code so I can scan it faster with my eyes.

And one day you will write in Python, where indents are (incredibly) part of the syntax.

[Ranger Fox]

I also prefer indenting my code so I can scan it faster with my eyes.

And one day you will write in Python, where indents are (incredibly) part of the syntax.

Oh, sweet ASCII art, no! The insanity! I think I'll keep to working with C# and JavaScript for the time being, then. But you already knew that since that's what I wrote "Kit" with. (I really need more time to add more to it... One of these days...)

[+sTeamTraen]

And one day you will write in Python, where indents are (incredibly) part of the syntax.

Oh, sweet ASCII art, no! The insanity!

Yeah, but at least spaces never, ever get compressed, or converted into tabs. So nothing could possibly go wrong.

[K-and-K]

On 3/8/2012 at 8:22 PM, Ranger Fox said:

I am not aware of any convenient "PlayerCurrentZone" function or attribute on any object.

 

In essence, you'll have to determine if the player is in each individual zone. It IS possible to create a function for that, though:

function PlayerCurrentZone()
    for _,z in ipairs(zcart:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end

 

In the above, you'll have to replace "zcart" with your cartridge's object.

 

It's easily possible to create what you're after without using this. In fact, I had a little fun tonight and created a fully functional Fox, Chicken, and Feed cartridge. I assume you don't mind looking at author script, so almost all the functionality is contained therein. I also included a few fun Easter eggs since this is a demo. I just couldn't help myself.

 

Have fun! If you have any other questions, please ask. If you'd like to critique my odd sense of humor, let's do it over barbecue chicken--your treat!

Fox and chicken.zip 119.65 kB · 45 downloads

 

How do I enter this into Earwigo

 

function PlayerCurrentZone()
    for _,z in ipairs(zcart:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end

[K-and-K]

Copied and pasted one by one, or as an entire line I am not sure ?

[K-and-K]

[+Hügh]

1 hour ago, K-and-K said:

Copied and pasted one by one, or as an entire line I am not sure ?

 

That is only defining a function called PlayerCurrentZone that returns a reference to the zone currently containing the player. You never explicitly call this function.

 

Consider putting this function as-is in the Author Script (I believe it's under Cartridge.) Then, whenever you need to get the player's current zone, you execute a Lua statement that grabs the user's current zone and assigns it to a variable.

[K-and-K]

I know I think it will work awesome in Urwigo, I have not tried because I am I'm trying to do this with Earwigo.

 

I wish I could go back in time with Landon Smith aka Steven Vase.

 

https://www.youtube.com/channel/UCh5n99Lp94oNytIzx2FoI5A

https://www.youtube.com/watch?v=CTser84ENPs&list=PLIJExYUsAIWev2Ufb36md1_NE2RGzVHlv

 

Stompy&Stampy too !

 

https://www.youtube.com/watch?v=_bBz_JK0_eo&t=2s

 

 

[K-and-K]

Zone eventually pops up in next step, but wants to throw you under the bus - if you run before looking or listening or seeing and reading. Designed for use ADHD folks whom have issues with rules and regulations , flight and flee response, or as I like to call it the bee line approach of stepping out into traffic. You see so much of this with smart phones, watching your GPS and not looking where you stand or walk.

Edited May 18, 2021 by K-and-K

[K-and-K]

But I believe your level of response is above my skill level at this time, I have never programmed LUA, C, +C , +CC, my era used a Commodore 64, Basic and machine language, dabbled with something called "COBOL" then learned I had to make money to eat , instead of doing what I enjoy. Education and schooling all got away from me , and the world passed by me. Now I'm a WIndows XP Pro, using a Windows 8.1 tablet, in a Windows 10 world. I think I got a good grasp on Boolean, Binary and even hex-decimal, however when it comes to Quantum Computing ... I think you lost me at Q.

Edited May 18, 2021 by K-and-K

[K-and-K]

7 hours ago, Hügh said:

 

That is only defining a function called PlayerCurrentZone that returns a reference to the zone currently containing the player. You never explicitly call this function.

 

Consider putting this function as-is in the Author Script (I believe it's under Cartridge.) Then, whenever you need to get the player's current zone, you execute a Lua statement that grabs the user's current zone and assigns it to a variable.

 

Okay cool, clicked on - multi quote - , I think I am doing this right, ... a response to yours .

 

I read, and red and read and readed ... "thought you'd laugh at that".

 

Figured I would give it a try. As you can tell I visually have to test these out, words and timezone appear to get in the way.

 

[K-and-K]

function PlayerCurrentZone()
    for _,z in ipairs(zcart:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end

 

However ..

I am uncertain if it should not just look like this !

 

PlayerCurrentZone()
    for _,z in ipairs(zcart:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end

[+Hügh]

When you enter the author script, enter it like this.

 

 

Make sure the bit with the arrow matches this bit.

 

 

Whenever you want the zone containing the player, you can do

 

 

Now the variable "theZoneThatContainsThePlayer" is a reference to the zone containing the player. Does that make sense?

[K-and-K]

Ah of course, LOL I forgot about those elements at the top, so excited to test now.

Okay he used zcart - as in zone cartridge for short I figured.

You changed it up to example to show I could call it something else if I wanted to, gotcha.

I might want to call it CurrentPlayerZone or CPZ or CurrentlyPlayersZoned.

 

Oops , no wait a minute okay so yours: or your cartridge name , hum .. okay but the Lua named equivalent without spaces ...

Ok I added my image. Mines simply something else and RangerFox used his ... okay I think I got it.

6:29 AM 19-May-2021

 

function PlayerCurrentZone()
    for _,z in ipairs(cartPortBruceProvincialPark:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end

 

Nest step ?

 

"theZoneThatContainsThePlayer"

local theZoneThatContainsThePlayer

local_theZoneThatContainsThePlayer

 

I wasn't sure with the blue underlined image.

I assume the word "local" is a command instruction in LUA programming maybe ?

You have put the word local in front as in one of the two formats above I do not think there is an _ underscore in there, probably just a space ?

I also assume PlayerCurrentZone() is a mandatory instruction not to be deviated upon.

 

 

 

 

[K-and-K]

  

Alleviate another

So still no luck , I left out the (.). , simply using local  PZ=PlayerCurrentZone()

But I am not sure if I need to use yours.

I assume I completely misinterpreted the entire command structure here !

[K-and-K]

updated photo

[K-and-K]

Thanks for all your help Hugh, I know this is all new to me, ... and not so much you.

I found this : https://www.tutorialspoint.com/execute_lua_online.php

https://www.tutorialspoint.com/execute_lua_online.php

Kinda cool.

function PlayerCurrentZone()
    for _,z in ipairs(cartPortBruceProvincialPark:GetAllOfType('Zone')) do
         if z:Contains(Player) then
              return z
         end
    end
    return nil
end
print("Hello World!")
print(Z)

 

If it is all the same, I may just as well write my entire Wherigo using LUA code, in the end LOL.

 

[K-and-K]

Result

 

 

$lua main.lua
Hello World!
nil

[K-and-K]

Lua Console , executed not in the zone

2021-05-19 13:49:43: INFO AttributeChangedEvent ZInput Password Visible

2021-05-19 13:49:43: nil2021-05-19 13:49:43: [01] Zone:Distant - Posted Entry Point

2021-05-19 13:49:43: INFO AttributeChangedEvent ZCharacter Earwigo Name

2021-05-19 13:49:43: [01] Engine Version , Player Name: Earwigo, Device ID: webwigo

2021-05-19 13:49:43: [01] ZCartridge:Start - Downloaded Wed Dec 31 19:00:00 1969

2021-05-19 13:49:43: [01] PlayAudio - start

2021-05-19 13:49:43: ERROR MediaEvent 1 a ZMedia instance (not implemented)

2021-05-19 13:49:43: ERROR Alert (not implemented)

2021-05-19 13:49:43: [01] MessageBox:Show - Welcome to Port Bruce, get ready to enter catfish creek, you may go west or east to have a look around. Do you know which way to go ?

[K-and-K]

Restarting cartridge and now placing the character into the zone, and clicking on "play" again.

 

2021-05-19 13:54:01: INFO AttributeChangedEvent ZInput Password Visible

2021-05-19 13:54:01: nil

2021-05-19 13:54:01: [01] Zone:Enter - Posted Entry Point

2021-05-19 13:54:01: [01] MessageBox:Show - So it looks like you jumped the gun. Having a look around may have seemed like a good idea while loading your cartridge at the posted point. However by not paying attention you just fell in some quicksand. Please take your butt out to the road and start there. Then restart your cartridge.

2021-05-19 13:54:01: [01] Player:SetInventory - Will add cell phone

2021-05-19 13:54:01: [01] Player:SetInventory - added cell phone

2021-05-19 13:54:01: INFO InventoryEvent cell phone

2021-05-19 13:54:01: INFO AttributeChangedEvent ZCharacter Earwigo Name

2021-05-19 13:54:01: [01] Engine Version , Player Name: Earwigo, Device ID: webwigo

2021-05-19 13:54:01: [01] ZCartridge:Start - Downloaded Wed Dec 31 19:00:00 1969

2021-05-19 13:54:01: [01] PlayAudio - start

2021-05-19 13:54:01: ERROR MediaEvent 1 a ZMedia instance (not implemented)2021-05-19 13:54:01: ERROR Alert (not implemented)

2021-05-19 13:54:01: [01] MessageBox:Show - Welcome to Port Bruce, get ready to enter catfish creek, you may go west or east to have a look around. Do you know which way to go ?

[K-and-K]

So in both scenarios it appears to run the code, make the decision although I see "NIL" on both ?

It appears to apply the correct message, but overwrites as though it is not acknowledged just yet.

 

[K-and-K]

I do have one question though and I ran into this with Urwigo I load it up I try everything, then delete 1/2 of it but the file size does not decrease ?

 

It only gets larger and larger ? Shouldn't the file size get smaller ?

PortBruceProvincialPark(3).gwc            44 KB

PortBruceProvincialPark(274).gwc   2,114 KB

Edited May 21, 2021 by K-and-K
spelling

[+Hügh]

3 hours ago, K-and-K said:

then delete 1/2 of it

 

Removing code isn't going to do much; it'll (at best) shave a kilobyte or two off the filesize. It's removing images that will reduce your cartridge size. 

Edited May 20, 2021 by Hügh

[K-and-K]

Awesome , thanks hugh I really appreciate this communication, I hope my contribution will help others. I may go back and delete some images as they could possibly confuse others, we only need the correct procedure, when I do get it working, field testing it I will come back.

 

Again thank you very much.