I was scratching my head over this one;
This works:
go.get("#", "model_url" )
But this:
go.get(".", "model_url" )
Produces this error:
ERROR:SCRIPT: n/player/player.script:15: '/instance6' does not have any property called 'model_url'
I’ve been treating “.” and “#” the same (until now). What’s the difference?
From manual https://defold.com/manuals/addressing/#relative-addressing
Defold provides two useful relative address shorthands:
.
Shorthand resolving to the current game object.
#
Shorthand resolving to the current component.
. Is the game object while # is the current component (the script)
Posting a message to . will send the message to all components of the game object. While #foobar sends only to the foobar component.
Thanks guys, this makes sense and I’ve added it to my ever-growing Defold Arsenal of Knowledge ™.
This is how I feel my one is like during the past few days, running into silly mistake after silly mistake:
Same here, I don’t know how much time I wasted during last LD wondering why setting the timestep to 0 didn’t work, before “realizing” that I should post a message to collection proxy instead of script or wondering why GUI is not behaving as I want due to setting pivot of GUI to something that makes no sense in hindsight XD
Is there something you feel we could do to help you avoid things like this?
Well if you could make compo jam last longer that would be awesome! 
Jokes aside, in my case fault is entirely mine, since I was rushing and didn’t read things properly 
Docs, manuals and examples are superb. I don’t think I could ask for more.
Similar answer from me.
I think because the last year or so I have been focusing on story and quests for a game where the ‘engine’ was all already in place, moving back to the fundamentals for a new project has been a bit of a shock. I thought I had a firmer grasp on things than I actually do, but turns out I’m a bit rusty.
Specifically, I have been struggling with finding a comfortable way of working with input, UI, and cameras. I think to an extent that is my own fault because I try to adapt things to my own style, when I would probably be better suited to adapt to what is already there. Finding it difficult to match input and UI to different resolutions in a way that I like.
Could you please elaborate on this?
This is my experience from the last two game jams, so bear in mind that I haven’t exactly been thorough in my research of the documentation.
In both jams I attempted to use rendercam. I found that if I changed the size of the game window, my mouse co-ordinates wouldn’t match the on screen position - even when filtering the mouse position through screen_to_world_2d and trying all kinds scales modes and camera settings. Maybe I’m missing something.
It’s possible that my approach to input handling is an obstacle. I was resistant to using the on_input function on a per script basis, and have instead been capturing input in a single dedicated module which other scripts then access in update(). Almost certainly inefficient, but potentially also interfering with logic. I don’t know.
Now I am working on getting a handle on Gooey, because I get the feeling I have been wasting time reinventing the wheel, and to extend the analogy, making a square wheel in the process. My experience with Gooey is good so far.
My latest struggle as I am prototyping mechanics for my next project is handling GUI nodes in different resolutions. No matter the combination of pivots, anchors and adjustment modes, I just can’t get it quite right. I feel like I need to actually detect the window size and move GUI node positions in order to achieve what I want to achieve. Is that normal? I don’t know.
You can achieve quite a lot with pivots, anchors and adjust modes and in the most common cases get a UI that adjusts as the screen size changed. But it will not work in all cases. If you have a specific problem please post it here to get help!
can I ask sth in this ? if you make a parent object and inside has a script and others objects inside if you send one msg with . will go to all object under it? the message? So in object parent — obj 1 and obj1/script — obj2 and obj2/script both these scripts will receive the message of script in obj parent? thanks
No, a message can only ever be sent to one game object (and its components) or a single component.
ok thanks
