Useabilty requests

Its been a while since we had many updates to the editor, so I thought I might make a few requests, a few of which are probably already on the todo list.

Is overlapping at offset between minimum, and maximum:

An additional condition like overlap at offset, but checks all pixels between two values. Like if you gave it 4, and 8 it would check all the pixels between the hotspot +4, and the hotspot+8. Something like -10, and 10 would basically check both the left, and right for a collision if it were on the x. I realize you can use the los behavior for this, but that can complicate things, like a 45 cone would get just one direction, but if you need multiple directions you must add another behavior. Blah, blah, blah 360 degrees misses corners, etc.

Run time editable hot spots:

The origin is where and object can be scaled from. Say for example an object had the origin on the left center, and you scaled the width higher, it would look like the object was growing towards the right. The only way to make it look like its growing in some other direction is by either changing the angle, which may not work in some situations, or add another object that has the hot spot set to the preferred side.

Origin for los, other than hot spot:

The hot spot isn't always the ideal position for the cone origin, and using a dummy object is overly complicated.

Also: Can't see around square corners, so using "solid" can be an issue with something else that uses solid, say tilemaps.

Object.timescale:

We have object.dt, but using the actual timescale would simplify some things.

Weighted random:

It would be nice to have an expression that that gave us random as a chance, or dice roll, or percent. Like in this thread:

There are so many good places to use that, but implementing it for each "roll" is a big hassle. Id say use a function, but then you get the picking issue.

Is overlapping at offset between minimum, and maximum:

An additional condition like overlap at offset, but checks all pixels between two values. Like if you gave it 4, and 8 it would check all the pixels between the hotspot +4, and the hotspot+8. Something like -10, and 10 would basically check both the left, and right for a collision if it were on the x. I realize you can use the los behavior for this, but that can complicate things, like a 45 cone would get just one direction, but if you need multiple directions you must add another behavior. Blah, blah, blah 360 degrees misses corners, etc.

You can use -n & n in the expression field.

Run time editable hot spots:

The origin is where and object can be scaled from. Say for example an object had the origin on the left center, and you scaled the width higher, it would look like the object was growing towards the right. The only way to make it look like its growing in some other direction is by either changing the angle, which may not work in some situations, or add another object that has the hot spot set to the preferred side.

What about "scale" action? Doesn't this one will work from the center? If not, then +1

Origin for los, other than hot spot:

The hot spot isn't always the ideal position for the cone origin, and using a dummy object is overly complicated.

Also: Can't see around square corners, so using "solid" can be an issue with something else that uses solid, say tilemaps.

+1

Object.timescale:

We have object.dt, but using the actual timescale would simplify some things.

+1

Weighted random:

It would be nice to have an expression that that gave us random as a chance, or dice roll, or percent. Like in this thread :https://www.scirra.com/forum/viewtopic.php?t=66495&start=0

There are so many good places to use that, but implementing it for each "roll" is a big hassle. Id say use a function, but then you get the picking issue.

+1

Could I throw in "Disable collision between selected instances" ?

Overlap at offset only checks the one spot, not all the spots in between, so -n, and n both would be in the same condition, in the same x, or the same y.

It scales from its origin, so if the hotspot is in the center, then yes.

The scale action works on both width, and height, so it has little to do with this.

Overlap at offset only checks the one spot, not all the spots in between, so -n, and n both would be in the same condition, in the same x, or the same y.

AH

It scales from its origin, so if the hotspot is in the center, then yes.

The scale action works on both width, and height, so it has little to do with this.

Ok.

I'm just worried that request 1, and 2 aren't feasible due to limitations, the rest should be doable.

Weighted randoms would probably have the biggest impact.

1. "overlaps at offset" just moves the object, checks for collision then moves back. I've done your request before in events by resizing the object, checking for collision, then setting the size back to what it was. I do see how it would be tied in to request 2 since you would want to know the center to scale from.

2. Would moving the hotspot leave the xy positions the same or would it also change the positions so the object would stay visually unmoved?

Yeah, I've seen the first done with dummy objects as well.

As to the hot spot giving the texture new coordinates, yeah that might be considered a downside, but when using it for visual effect the size would be set to 0.

I made an example: [attachment=0:15w1cph8][/attachment:15w1cph8]

This is especially useful when doing effects to menu's, gui's, window's , etc.

I mean why add the same exact texture just for an effect?

On the weighted randoms, just remembered, and realized: min(int(random(100)),int(random(100)))= a chance out of a 100, or at least a reasonable representation of that.