Can you post your project?

In general you should never manually type in the UID of an object when using Pick by UID. Imagine for some reason you need to delete a RoomZone during runtime, and then re-add it into the game. The UID will be different after you recreate it

Instead, you can use an instance variable called "zone" or something, and do:

RoomZone zone = "garden" ? play garden

Roomzone zone = "forest" ? play forest

This way you can assign any RoomZones the appropriate "zone" variable and they will work

No, it's entirely possible. Have you read through the Multiplayer tutorial?

construct.net/en/tutorials/multiplayer-tutorial-1-concepts-579

Groups work great for things like this, because you can disable them completely when you're not using them. Here is how I would do it:

Every 0.03 seconds (30 times per second, because no need to check every tick)

-Is mouse overlapping Whatever

-and

-Is Group "Tooltip" Deactivated

-> Activate Group "Tooltip"

TOOLTIP GROUP

trigger once

-> Move tooltip to spot, make visible, etc (this is showing the tooltip)

every 0.03 seconds

-is mouse NOT overlapping whatever (checking to see if tooltip should be disabled)

->move tooltip far away, make invisible, etc

-> deactivate Group "Tooltip"

This way you're only checking if NOT OVERLAPPING when the tooltip is actually active, so your collision checks are halved (or fourthed if you were checking every tick and not every 2 ticks before)

You can do it the way you would do anything else with peers

On Peer Created > Set ScrollTo disabled

is peer's peer.peerid equal to multiplayer.myid? -- > Set Scroll To Enabled

Or, you can make a separate "Camera" object with ScrollTo enabled and set it to follow your peer. I like doing it this way so I can do a smooth-interpolating camera that lags behind the player a bit

jobel

Well I am a rookie programmer and when I run into problems like this it is not uncommon for me to have to do some searching

I am not judging after the fact, but from a position of someone who has to deal with the very same manual as you and sees no problem with it. The result you wanted was in the third result

I would suggest changing up your strategy for searching the manual if you cannot bear to have to look past the first search result

Yikes

dop2000 Ashley

if you go to construct.net/en/make-games/manuals/construct-3 and type "set color". Nothing comes up. Then you assume its in System Actions because that is the first result. Then you do a CTRL-F and search for "set color" and again nothing. So I honestly looked for a good amount of time. I'm happy to learn the Set Color info is in the doc, but unhappy to know its not easily accessible. In fact, without that link, I don't exactly know how to get there.

> I prefer using google when searching for something here, for example:

>

> "set color" site:construct.net inurl:manuals

>

I've been told many times to do my searches using Google that way; with that 'site' and 'inurl'. It's not going to happen, I've never used google that way and its extremely cumbersome for me. Not only do I always forget the syntax, but I've left that command-line style typing back in the 90s. Seems like that syntax could easily be added to the Construct search form no? Is there a reason the Construct Manual Search function is so terrible? Is it a lot of work to make 'search' perform as expected? It almost seems as if it's not indexed or something. Search doesn't seem to be going through all the branches.

Set Color is in the 3rd result "Common Actions"

Taximan

Best way to do this at runtime is to have one visible tilemap for graphics and an invisible tilemap underneath it for collisions. You can delete and add tiles to the collision tilemap