Sep 6 2015, 9:02 am
|
|
Ter13
   |
I'm also curious how plane is gonna work.
|
Ter13:
I'm also curious how plane is gonna work.  C: | |
Plane is mostly useful for alternate draw modes like isometric, where layer takes second fiddle to nearness.
| |
I was hoping plane would be an easier method of rendering objects in layers, like a layer 3.1 3.2 3.3 etc, before hitting the mob layer.
What's the current best-practice/recommended method for multiple (dozens) of objects all visible in the same tile from 3/4 view, as if someone died and dropped all of their loot there? | |
You can use layers like 3.1 and 3.2. The MOB_LAYER is just a flag that represents a numerical value.
You can just put all the objects on OBJ_LAYER (3) when they are dropped. If you want them ordered a certain way, then add decimals yourself. Not sure where you're going with this. | |
What's the current best-practice/recommended method for multiple (dozens) of objects all visible in the same tile from 3/4 view, as if someone died and dropped all of their loot there? Layer already uses floating point numbers. For overlays, you should be using the float layer flag. For dozens of objects all visible on the same tile, the layering doesn't matter because if they all share the same layer, the objects will be rendered according to which were located there first until pixel movement comes into play. When pixel movement is a factor, I'd advise you to set their layer based on an inverse of their absolute y coordinate. | |
Albro1 wrote:
You can use layers like 3.1 and 3.2. The MOB_LAYER is just a flag that represents a numerical value. I've tried doing things like layer=3.1 and such. It doesn't seem to work. Set down tile floor turf, layer 2. Set down bartop object, layer 3. Set down food object, layer 3.1. Cannot see food object atop bartop. And that's in a brand-new project with nothing other than a turf and two objects written in code. | |
I'm at work so cant test, but if that's accurate, pack it up and send a bug report. That should work.
| |
Using this snippet:
/* When the obj has a layer value of 3.1 (Or OBJ_LAYER + 0.1) and the counter has a layer value of 3 (Or OBJ_LAYER):  When the obj and counter both have a layer value of 3 (Or OBJ_LAYER) or 3.1:  When the counter has a layer value of 3.1 and the obj has a layer value of 3:  I'm not sure what your problem is, but it isn't this. This works exactly as it always has. | |
 Explain what I'm doing wrong, please. Is it simply not going to show in the map editor but will show just fine in-game? Blood is object layer 3. Bones is object layer 3.1. Blood gets overwritten by bones in the map editor. They refuse to co-exist. /*  Because it is simply not as simple as assigning a different floating-point value to it. | |
The behavior of the map editor to overwrite objs is optional and has nothing to do with the layer variable. Try Ctrl+Click to place the object, or change that Option.
| |
Kaiochao wrote:
The behavior of the map editor to overwrite objs is optional and has nothing to do with the layer variable. Try Ctrl+Click to place the object, or change that Option. That seems un-intuitive after being told that simply using floating-point values should work. Map editor should not over-write if something has a different layer value, chosen behavior notwithstanding. I'd see it happening on the same exact layer, but not like this. On the other hand, CTRL+Click did work. | |
It has nothing to do with layers, Khyber.
| |
When you were told using floating-point values, we weren't aware you didn't know how to map objects on top of each other. I believe the map editor will still show whichever you place on top as the top-most, but the game will show the highest layer value as being on top.
| |
It's not something I considered yet. The idea doesn't even have a var name to go with it. I'm still open-minded to it, though, and if some good suggestions come together quickly I might be amenable to squeezing it in for 509.
| |
I think a variable name like "speed" in terms of appearances might work. It would speed up/slow down all animations of an atom.
On that note, being able to grab the length of an animation - both the default and the modified lengths - would be a very nice addition as well (I'm not aware that it is possible at the moment, so correct me if I just don't know about it). I also think a per-flick scalar would be nice as well, for when you want to just run one animation faster or slower (Like my example in that thread, where I wanted to modify the speed of the "attack" state based on a player's attack speed). I'm not too savvy on the nitty gritty information that you need to have to implement these things, so if anyone else could offer any opinions or suggestions, that would be nice as well. lol | |
I'm with Albro1 on this for the most part, but I think the variable name should be frame_speed, frame_duration, flick_speed, animation_length, or something to that effect. Speed is just too general of a word.
As for function, this isn't my strong suit either, but I would imagine it as capable of changing it on a per atom basis, and per flick() basis. The var could be numerical, default setting 0 for no change, and have ranges from negative through positive to alter all animations of that atoms icon by that much. Negative to slow down, positive to speed up. Unfortunately Flick() couldn't simply use the var, I guess it would need a new setting of its own added to the end that defaults to 0, and uses the same negative and positive system. The only problem I see in this method is if someone wants to alter the speed of an icon that isn't attached to a specific atom, I suppose it could be added to icons in general instead... But that just seems like a mountain of headaches. Maybe someone else could chime in here. As I said, not my strong suit, but this is just what I'd expect if I were reading about it for the first time as if it'd always been a feature. | |
I figured it would be an atom.animation_scale variable that multiplies the animation speed by a certain amount. It defaults to 1, 2 would be 2x faster, and -1 would be reverse with normal speed.
| |
I don't see why Albro's idea hasn't been implemented. It'd go so well with our infinite stat training games it's not even funny. Think about it. You can scale the punch animation against the speed variable, and you can hit pbags ten times as fast.
animation_rate is my vote for name. 1.0 = normal, 0.5 = 50% rate, 2.0 = 200% rate. | |