looking at this, your options are:
list of datums
list of lists/associated lists
list of href lists/json
href lists
json
While Json sounds like the right fit, I dislike the idea of hamfisting more syntax into an engine aimed at beginners.
| |
I personally don't think BYOND is a very beginner-friendly engine to begin with... And why limit the power of the experts? Beginners don't have to use these techniques. I never understood that logic.
| |
Where I'm at with filters is that all of the options currently pretty well suck.
List of datums: It's not just a matter of creating a list and datums on the fly, but altering the live object. A list of filters would be best implemented like overlays/underlay lists are, as an internal type (actually five of them: one for each atom type, plus images); the filter itself would have to be a different internal type, requiring the same housekeepign as atoms/datums/images/etc., that understood which object it was linked to. (Also, chaining . or : after list indexing isn't yet a thing.) On the upside, the syntax for this approach is super clean and easy to work with. List of associative lists: Most of the same issues apply. The syntax is not as clean, although there's no worry about having to deal with an unsupported syntax like filters[1].color, since filters[1]["color"] is viable. (Side note: Both of the above would work fairly well with mutable appearances, since those are designed to allow temporary lists that they don't resolve until the appearance is "validated". But that doesn't solve the problem of trying to work with an obj more directly.) Parameter lists: Way too ugly to work with. Lots of people already don't like that skins are saddled with this format; I'd prefer not to go this route with filters, and it also makes filters harder to modify. JSON: While JSON support is in the language now, I can't in good conscience use that as the format. Now another way to go here is to not allow live filter editing at all, but simply to make them inert objects much like overlays/underlays currently are. They'd still be datums, but basically read-only unless you modified the filter list. (This would work really well with the first concept, treating each filter list as a special type.) | |
Lummox JR wrote:
Now another way to go here is to not allow live filter editing at all, but simply to make them inert objects much like overlays/underlays currently are. They'd still be datums, but basically read-only unless you modified the filter list. (This would work really well with the first concept, treating each filter list as a special type.) this would be really neat | |
Lummox JR wrote:
Where I'm at with filters is that all of the options currently pretty well suck. Which means that there is a bigger problem under this. The dragon must be slain one day. God be with you, brave one! (I'd say "list of datums", because of "super clean and easy to work with".) | |
Don't worry I have the best solution.
//Do the filters!
There nice and easy and all your filter needs are ready to go. | |
Lummox JR wrote:
JSON: While JSON support is in the language now, I can't in good conscience use that as the format. It wouldn't hurt to replace some of DM's ubiquitous formats with it to make it more standard. =) IMHO interface files, dmi files, settings files, etc could all benefit from using a universal format like JSON instead of a hand-rolled custom INI-esque format. | |
So does this mean I'll be able to do something like a circular outwards moving pressure wave effect moving through the air using a filter?
| |
Clusterfack wrote:
So does this mean I'll be able to do something like a circular outwards moving pressure wave effect moving through the air using a filter? Something like that would be a displacement filter, and that's an even more complicated setup. Displacement filters take a second image as input, and I haven't figured out any way to do that. | |
mob/var/tmp/list/filter = list("filter_mode"=FILTER_GAUSSIAN,"gaussian_size"=3) | |
Why use a filter when you can just use an animate()?
| |
Akto wrote:
Why use a filter when you can just use an animate()? Animation is a completely different concept: it involves changing a parameter over time. A filter is a modification to the way an object is drawn. | |
I meant that toward Clusterfack, more or less asking why not just use animate() for now.
| |
Ah. Well I would think the best he could do for a shock wave currently would be a ring of smoke. You could use animate() for it, although a regular animated icon would work too.
| |
I think he was thinking more along the lines of something like a magnifying effect. Is magnifying a filter?
| |
Rushnut wrote:
I think he was thinking more along the lines of something like a magnifying effect. Is magnifying a filter? Magnification would be a displacement filter, yes. | |
MAKE IT HAPPEN.
| |
Unless you mean something different than what I think you mean.