Like...
X.icon = '[Y.name].dmi'
Something simple like this but that actually works?
Is there any way to pass a variable into an icon name? I cant seem to find any simple way to do it.
Like... Something simple like this but that actually works? | |
From DM reference on file proc:
Note that the file exists in the external filesystem (ie the hard disk) and not the cache. That means the path is specified in double quotes and will be evaluated at run-time rather than compile-time. The file need not exist at compile time and may even be modified at a later date. This is the principle reason for using a file in the filesystem rather than a cached resource file (specified in single quotes). OP is using a cache reference. A cached reference is different from a file in the server root at runtime. There is no way to pull files out of the cache by name using variable names.* *that a sane person would recommend You can put files INTO the cache via fcopy_rsc(), but that's not really what you want. Instead, you might think about using an associative list. var/list/assoc_icons = list("icon1"='icon1.dmi',"icon2"='icon2.dmi',"icon3"='icon3.dmi') X.icon = assoc_icons[Y.name] This has two principle advantages: 1) During compilation, the compiler searches through all hard-included files (the ones being marked by single quotes) and stuffs them into the RSC. If you don't explicitly reference a file using single quotes, it doesn't get included. Mr_Goober's answer would force you to package those files outside of the RSC and using them in game would stuff them into the dynamic (runtime) rsc. My approach would force them into the normal RSC. His approach might actually work well for modular content, but if you are planning for this to be an immutable part of your game, you might as well toss them into the regular RSC. 2) The associative list will have a null fallback. This means that if the index doesn't exist, you'll wind up with a null icon rather than a runtime error like Mr_Goober's example could feasibly give you without the necessary precautions. His approach nails it for runtime-included content, and mine nails it for compile-time included content. Between those two, that should pretty well do it for you. | |
GatewayRa wrote:
He can, since they are indexed in the .rsc files by name. However, he would have to parse through it to get the icons. Okay, and how exactly is he going to perform binary file reading with DM? The best we can do is raw text, and even then, the first time you run into a value of 00000000 in the file, you are boned because of DMStrings are zero-terminated. Assuming these are PNGs (DMIs are just PNGs with special metadata jammed into the ztxt block), that's going to happen almost immediately. You aren't going to get the files out of the RSC in DM. Period. If you do manage to use a C DLL, you aren't going to get the files from the DLL into DM without putting them on the HDD first. If you do manage to get them from the RSC onto the HDD, it'd be entirely pointless in the first place, because you could have avoided all of the effort of writing an RSC parser by using an associative list instead, or just using Makeii's approach and distributing them as hard files rather than cache files in the first place. I'd imagine you'd also be able to compare the address at a certain index and see how it relates to BYOND's \ref macro, in which case you'd be able to load the icons directly from the memory. \ref when applied to a cache file gives you a one-up serialization of that cache file's order in the RSC. Without knowing the byte length of every file prior to that one in the RSC, the \ref macro isn't going to help you with anything. To be more specific, the first byte will be the "cache file byte", and the remaining three bytes will be the serialization. If I recall, the first byte indicating cache file is either 32 or 3C, I don't remember which. | |
GatewayRa wrote:
Just explained how you wouldn't need a C dll from Hobnob's file_io: DM, by providing an interface to an external DLL which calls the necessary functions. Yup... Putting an RSC in the savefile is honestly the most backward thing I've ever heard suggested. Let's just pepper our code with some empty while() loops while we're at it, and do some recursive preprocessor defines just for funsies. | |
The .rsc can be saved to a savefile and read via ExportText(), which would convert it into base64, which can be edited within DM. Alright, I'll adjust my statement: There is no way to get a file from the cache by name that would be recommended by a reasonable human being. That said: Never put your rsc file in a savefile so you can get stuff out of it. It's absolutely beyond stupid. In order to do it, since there's no native way to convert a base64 string to a DMI/wav/ogg, and no native way to work with files beyond basic read/write, this is more or less what you are suggesting: 1) jam the entire RSC into a savefile 2) Read the savefile as raw text 3) Pick out the base64 string of the file and load it into a DM string whole. 4) Parse the contents in base64 --yeah... TOTALLY TRIVIAL... 5) Copy each file you find into a separate string (which is incredibly slow in DM for large strings) 6) Push these individual files back into savefiles with rawtext, mimicking the savefile format (I'm not entirely sure that this is completely possible, seeing as in every test I ran, I kept winding up with early terminators in the strings) 7) Read back each one of these files from the mock-savefile into a local file. It's... Just... massively absurd to suggest that such a thing is an option. Even if you can get around the early termination issues I ran into in my experiments. | |
If I have to do the list I'll do the list. I was just trying to avoid it.
I've got 200~ different icon files I need to run through this with more in the future. Their file names all match the "Y.name" variable in the above example. I was hoping there was something simple so I didn't have to keep updating the list every time I added a new file. I'd store them in 1 dmi as different states but each icon has 10 states and past experience with icons like this tends to have DM start acting strange at around the 150 states mark. | |
Truly, the associative list approach is the best one here. It's uncomplicated, and KISS is the order of the day.
| |
Keep in mind that file() will probably require the full path of where the icon is, so if your icon is embedded in some folders, be sure to include them.