ID:147555
 
I'm making a mess of commands that work through the browser or a popup window (It's just so much niftier), but I can't seem to make the \icon[] instruction work.
The \icon macro doesn't work in the browser. Instead you need to use browse_rsc() to send an image, and use the filename you defined for it as the src attribute for your img tag.

Lummox JR
In response to Lummox JR
Ah. Yet another simple solution that slipped my mind.
In response to Enigmaster2002
Enigmaster2002 wrote:
Ah. Yet another simple solution that slipped my mind.

Well, it's not immediately obvious. To that end I've added a note to reference entry that will appear in a future update.

Lummox JR
In response to Lummox JR
Arg, not as simple as I thought.
What I'm doing is listing all of a certain mob in the world and I'm including their icon, but the problem is that there's going to be many many instances of one mob with completely different icons.
In response to Enigmaster2002
Your code doesn't seem to use browse_rsc() at all, which you need to send an icon to the client before using browse(). In browse() just use whatever filename you chose in browse_rsc() as the filename for the image.

Lummox JR
In response to Lummox JR
Okay, I'm getting somewhere, I tried using browse_rsc and I forgot the instruction to output to src the first time... anyways... I can cache the icon, but I can't figure out how to store the icon_state; I'm getting the first state in its' specified icon. Also, is there a way to remove these files after they've been intitialized and displayed? I don't want to distribute people's icons to my moderators.
In response to Enigmaster2002
Enigmaster2002 wrote:
Okay, I'm getting somewhere, I tried using browse_rsc and I forgot the instruction to output to src the first time... anyways... I can cache the icon, but I can't figure out how to store the icon_state; I'm getting the first state in its' specified icon.

You're doing well so far. To specify an icon state you need to use new/icon() in the first argument to browse_rsc(). This is okay even though an /icon datum isn't the same as a regular icon, which normally does matter for something.
browse_rsc(new/icon('myicon.dmi', "mystate"), "myicon.png")
I usually name my images .png for the browser, because that's what they become when exported. But the browser recognizes them regardless.

Note that the result is not animated.

Also, is there a way to remove these files after they've been intitialized and displayed? I don't want to distribute people's icons to my moderators.

This isn't a huge concern; it's only as much a worry as taking screen shots, which anybody can do.

Lummox JR
In response to Lummox JR
Success!

Thanks Lummox, I haven't a clue where I'd get without you.
In response to Enigmaster2002
Hmm, it appears I need to delete these files in the cache regardless; if I were to use this verb, it lists all the custom-made cars. I delete two of them, and now two of the images in the cache are obsolete, because browse_rsc() doesn't do anything if the specified file is already in the user's cache.
In response to Enigmaster2002
Eeeek! Long unbreaking lines on forum.... arrrgh... *dies* =) You can split those up onto multiple lines using slashes, you know, like this:

<code>html_doc+="all the HTML stuff, etc. goes here; but now this line is getting a bit long, so.... \ we jump down onto another line. All the blank space before "we" will be cut off."</code>

Much friendlier.

Anyway, to your problem - I believe that if the file already exists in the cache, but the file your sending is different, DS will detect that and replace the old cached file with the new one. I might be wrong on that though.

A way to avoid the issue altogether is to get a unique ID number for each car image. For example, in my latest project the NPC dialogue images are called "talk\ref[src].dmi" - where src is the NPC mob. So there'll be one "talk[whatever].dmi" file in the cache for each NPC the player has talked to, and each one will be unique to each NPC mob because I've used the \ref macro to get a unique reference to the mob.
In response to Crispy
Obsolete image files are still being used.
for(var/mob/Car/Custom/C in world)
src << browse_rsc(new/icon(C.icon, "[C.icon_state]"), "\ref[C]car.png")
html_doc += "<tr><td><center><a href=?src=\ref[C];action=driverpassengers><img src=\ref[C]car.png border=\"0\"> [C.name]</a></td>" //etc etc
In response to Enigmaster2002
Hmm... really? Not good. Try basing the name of the file on the icon state, that should work until you change the icon state itself.
In response to Crispy
I also add a string based on world.realtime to the filename. As long as people don't look at a different icon with the same name within 6 seconds or so, it will have a new name and use the new icon.
In response to Crispy
Crispy wrote:
Eeeek! Long unbreaking lines on forum.... arrrgh... *dies* =) You can split those up onto multiple lines using slashes, you know, like this:

<code>html_doc+="all the HTML stuff, etc. goes here; but now this line is getting a bit long, so.... \ > we jump down onto another line. All the blank space before "we" will be cut off."</code>

Much friendlier.

I my self am a fan of,
html={"
"}

That way, I can write the html just as if it were in a txt file. ^_^
In response to Goku72
Goku72 wrote:
I my self am a fan of,
html={"
"}

That way, I can write the html just as if it were in a txt file. ^_^

I use the {""} format so that I don't have to escape quotes in the code, but I also end each line with \ so that it ignores the carraige return and leading whitespace on the next line for more compact HTML files. It's not much, but each and every character that isn't tieing up bandwidth is a triumph in my book. :)
In response to Shadowdarke
Shadowdarke wrote:
It's not much, but each and every character that isn't tieing up bandwidth is a triumph in my book. :)

You, strange, strange individual...=P
In response to Crispy
Crispy wrote:
Anyway, to your problem - I believe that if the file already exists in the cache, but the file your sending is different, DS will detect that and replace the old cached file with the new one. I might be wrong on that though.

You're not; that's correct.

Lummox JR