Wouldn't it help for compile (or is it update?) to not clear unused instances?

Wouldn't make sense.
i noticed when generating from icon states in map editor when i place 2 of the icons it generates onto the same tile it only shows one when you start game up. been a while since ive tried this tho
Don't use generate from states/dirs. It changes the tag, which defeats the entire purpose of my tutorial.
Not bad. From this, I gathered that I should be able to save myself from programming more than I need to.

Will re-read when needed. Good job, Ter.
This can be very handy and I intend to make use of it soon. Thanks!
In response to Ter13
Ter13 wrote:
Don't use generate from states/dirs. It changes the tag, which defeats the entire purpose of my tutorial.

I could see how that would be annoying if you actually used the tag variable in your code, but why does that defeat the "entire purpose?" Why should I go through the instance editor 7 times just to change dir from 2 to 1,4,5,6,8,9, and 10?

I know I'm a little late, but a very nice read. Thanks for the advice, Ter. :3
I changed how I do maps immediately, and can't believe how much easier it is now. I can't wait for the next read!
I'm really late, but I do have a question, Ter.

In regards to the separations between the artist and programmer, do you have any other advice to keep that separation steady?

For example, the player's character and all of its icon states for its actions, as well as accounting for the length of the animation in cases where you cannot move until it is done. Is there a way to keep the programmer and artist separate here, when map instances aren't involved?
Hold a serious development meeting where you guys go over the projected animation lengths and what not? I understand that these are harder to have when you can't meet in person, but we have software like Skype and GoToMeeting.

There is always a way to keep them separated, and unless a member is on "both teams", they should remain that way. You just have to know how to be a manager.
Effects programming is more involved with the artists than regular programming. In the industry, generally speaking there are people that do just that --they form a bridge between the engineers and the artists, but unfortunately, being limited to what we are, in a lot of respects we don't have that liberty.

The best advice I can really give for that is communication between the two skillsets. Generally speaking, your designer should be communicating between the programmers and the artists, but direct communication between artists and programmers isn't always a bad thing.
I have been dabbling with BYOND for around 15 years and have used the instance map for a large majority of it. not only does it save time in coding, once you get the hang of it, it's so easy, you will never go back. To be able to place 2 "identical" barrels next to each other and have them generate different items without the need for 2 chunks of code to do so. Just edit a sort of "treasure" variable in the instance editor for barrels.
In response to Magicsofa
Magicsofa wrote:
Ter13 wrote:
Don't use generate from states/dirs. It changes the tag, which defeats the entire purpose of my tutorial.

I could see how that would be annoying if you actually used the tag variable in your code, but why does that defeat the "entire purpose?" Why should I go through the instance editor 7 times just to change dir from 2 to 1,4,5,6,8,9, and 10?

Missed this a while back. It defeats the entire purpose because tag is meant to be a unique identifier. It doesn't make sense to have an instance's tag automatically set by generation, because you may need multiples of it. The automatic tag setting was a bad idea by whoever designed it.
In response to Magicsofa
Albro1 wrote:
For example, the player's character and all of its icon states for its actions, as well as accounting for the length of the animation in cases where you cannot move until it is done. Is there a way to keep the programmer and artist separate here, when map instances aren't involved?

Your designer (if you have one) and programmer should be brokering that information between the two. Your programmer should make the designer aware of any code constraints that may affects art, and the artist should make the programmer aware of any art constraints that will affect the code.
I only have one problem with this - what happens if you need to modify a world in real-time? This is a common feature in many games, and being able to modify turfs where they're needed by referencing pre-defined instances in code is much easier than most other alternatives I'm able to see.

e.g.
proc/BuildArena(var/arenaSize)
var/mob/builder = src
var/turf/t

for(t in block(locate(builder.x, builder.y, builder.z), locate(builder.x+arenaSize, builder.y+arenaSize, builder.z)))
var/turf/arenaFloor/F = new(t)

for(t in block(locate(builder.x, builder.y, builder.z), locate(builder.x+arenaSize, builder.y, builder.z)))
var/turf/arenaWallLeft/L = new(t)

for(t in block(locate(builder.x, builder.y, builder.z), locate(builder.x, builder.y+arenaSize, builder.z)))
var/turf/arenaWallBottom/B = new(t)


vs

proc/BuildArena2(var/arenaSize)
...

for(t in block(...)
t.icon = 'arena.dmi'
t.icon_state = "floor"

for(t in block(...)
t.icon = 'arena.dmi'
t.icon_state = "left wall"
t. ... ...


Can't actually come up with a way to show what I mean without spending an hour or so on it.. Seems that becomes exceptionally difficult to have specific properties assigned to different turfs. For instance, a proc that is only called when said turf is bumped, and only from one direction.

This would definitely be the optimal solution with a static world, though. Or smaller worlds.
Inline typedefs are useful here, though to the compiler, they are syntactically identical to your approach. Am in physics at the moment, so i'll explain better when i have a moment tonight.
Curious as to what you mean by inline typedefs. Typedefs as in what you'd use in a lower-level language, i.e. a function alias?
In response to Medicator
Well, this is a typedef:
obj/thing
icon = 'thing.dmi'
icon_state = "normal thing"
density = FALSE
opacity = TRUE

And this is an inline typedef:
mob/verb/get_special_thing()
new /obj/thing {
name = "special thing"
icon_state = "special thing"
density = 1
} (src)

// or
var special_thing = /obj/thing {
name = "special thing"
icon_state = "special thing"
density = 1
}
new special_thing (src)

Are they ever really worth using? Maybe.
Are they ever really worth using? Maybe.

It's only really good for containment of code. They compile down to basically the same thing, only the inline type has a numeric path as its final type.
In response to Kaiochao
This could definitely be useful. Thank you!
Page: 1 2 3