Labeling coordinates.

Page: 1 2
May 17 2015, 8:05 pm
In response to Multiverse7
That isn't very modular. It would be better to just do something like this:
proc
    tagall(turfs[], prefix, num = 1, suffix)
        for(var/turf/t in turfs)
            t.tag = "[prefix][num++][suffix]"
        . = turfs

    tagblock(start, end, prefix, num = 1, suffix)
        . = tagall(block(start, end), prefix, num, suffix)

    assignTags()
        tagblock(locate(5,1,1), locate(10,4,world.maxz), "1KC")
        tagblock(locate(5,11,1), locate(10,14,world.maxz), "2KC")
        tagblock(locate(11,5,1), locate(14,10,world.maxz), "3KC")
        tagblock(locate(1,5,1), locate(4,10,world.maxz), "4KC")
May 17 2015, 8:41 pm
In response to Kaiochao
That's nice, but tagall() doesn't have to just apply to turfs. It can be used with any list of datums, and possibly some other objects as well. Modularity works best when it works with the fullest range of possibilities.
proc
    tagall(objects[], prefix, num = 1, suffix)
        for(var/datum/d in objects)
            d.tag = "[prefix][num++][suffix]"
        . = objects
May 19 2015, 6:15 am
Tagging every turf is extremely wasteful and really unnecessary; all you're doing is growing the string table a lot to no benefit. There's no reason you can't do it, but it seems like the unasked question here is why you need to. I suspect there's a much better way to do whatever you need.
May 20 2015, 3:23 pm
In response to Lummox JR
Wow. Go easy on me, guys. I'm still a beginner. lol


Lummox JR wrote:
Tagging every turf is extremely wasteful and really unnecessary; all you're doing is growing the string table a lot to no benefit. There's no reason you can't do it, but it seems like the unasked question here is why you need to. I suspect there's a much better way to do whatever you need.

What I'm trying to do is designate squares for certain cards that go into play. The game I'm trying to program is Fluxx. So I need a spot for each player's keepers, and I need a spot on the table for all of the new rules. I've made it so that it looks at how many of each type of card in play and then places the card in the correct spot on the table. So far, it does exactly what I want it to do, I just want to know if there is a better, more efficient way to do it.

I really like the block() proc. Is there a way to make it so it loops through in an order different than bottom left to top right?
May 20 2015, 3:28 pm
Tags really aren't the best use for this. I'd actually have a proc that returns the right turf for the job. E.g.:

mob
    var/tmp/turf/home // top left for their play area

    proc/KeeperSpot(n=1)  // let's say 1 is the first spot
        var/turf/T = home
        while(--n > 0) T = get_step(T, EAST)

For my two cents, I don't think I'd put the cards on turfs at all. You're probably better off doing this entirely in the HUD. That would give you finer-grained control over where to place cards, and let you overlap them more tightly if space ran out. (Incursion does this.) It also means you could always arrange the other players at arbitrary points on the screen, with yourself at the bottom.
May 20 2015, 3:35 pm
In response to Lummox JR
Lummox JR wrote:
Tags really aren't the best use for this. I'd actually have a proc that returns the right turf for the job. E.g.:

mob
>     var/tmp/turf/home // top left for their play area
>
>     proc/KeeperSpot(n=1)  // let's say 1 is the first spot
>         var/turf/T = home
>         while(--n > 0) T = get_step(T, EAST)

For my two cents, I don't think I'd put the cards on turfs at all. You're probably better off doing this entirely in the HUD. That would give you finer-grained control over where to place cards, and let you overlap them more tightly if space ran out. (Incursion does this.) It also means you could always arrange the other players at arbitrary points on the screen, with yourself at the bottom.

To be fair, putting the cards on the map was originally your idea. http://www.byond.com/forum/?post=1842035

Lummox JR wrote:
Well the way I set this up was not as HUD objects, but IMO you don't really need the cards to be on the HUD--except maybe when displaying the owner's hand.

Haha. But maybe I wasn't clear enough about what I needed.
May 20 2015, 4:15 pm
Oh, sheesh. Yeah. Don't know what I was thinking there. If multiple players need to see the cards, a HUD is better.

[edit]
Of course, you could put center cards like rules and goals, and the deck and discard piles, on the map; they'd be the same for everyone.
May 20 2015, 9:22 pm
What would be a good way to implement a HUD for this purpose? I tried looking up the answer in tutorials and the forum, but I couldn't find what I was looking for. I don't even really know how to go about making a HUD. Basically my question from the previous post still stands. Should I just use the DM reference and try to figure it out? I just noticed that it mentioned something about HUD. I'm tired right now since it's late so I won't be trying any of this right now, but next time I go in Dream Maker I will see if I can figure something out using the reference. In the mean time, any tips would be appreciated.
May 20 2015, 9:32 pm
Basically you know that certain cards--the ones in the center--will be displayed the same way for all players. Those make sense on the map. Others you'll probably want to position differently depending on the player. (Or perhaps not; you could simply allocate a different piece of screen real estate to each, in which case the map thing still could make sense.)

For cards that should only appear to one player, you could use screen_loc to position them and add them to client.screen for that user. If a card needs to appear to multiple players but in different positions, then you'd probably want to create copy objects that shadow it, each with their own screen_loc and shown to a different player.

Thinking in place, it's probably easier to keep all players at specific places on the board and use turfs anyway, and only use the HUD for showing the current player's hand.
May 21 2015, 3:12 am
Whether you place cards on the screen, or on the map, you will want control over each player's perspective of the cards. They could appear to face up for one player, but down for another. The direction or position of each card may also need to be different for each player. You might also choose to hide cards altogether.

I think the best solution to all of these things is not to use the icon var of the card objs, but to instead use /image objects. There would be only one "physical" obj for each card, but each card would have images for each possible perspective. These images are what gives the cards a visual interface for players to interact with. They will look and act like card objs, but in reality they are not. Using images like this, instead of making new objs results in a massive increase in efficiency, so for me it would be a rule; not a choice.
May 21 2015, 8:26 am
In response to Multiverse7
You don't need to avoid using the icon var. You can set the override var on an image and it'll replace the standard appearance rather than add to it.
May 21 2015, 8:58 am
in this case I would use the face down icon as the icon and use image+override to show the one player the cards face up to avoid having to use images to display to all players in view
Page: 1 2