I was working with a train on horizontal tracks, and attempting to move the selection box (and bounding box) to the left to be biased toward the left around the center. While I was reducing the Y coord of the selection box (which was claimed to be an AABB box) the rectangle kept moving up AND left.
So I moved the train to a vertical orientation and started there with -1,-1 to 1,1 . Then interitivly move the box up a bit, moved the bottom up a bit, etc... all was working as expected. Then I decided to record the settings and make a composite. Repeated. Moved the train to hoizontal track and took screenshots of the same coordinates.
I'm baffled how factorio manages to draw everything so well
I used some purple lines to make sure the images were all aligned with each other; decided to include them for reference on the output.
What I was attempting to do, was to setup a bounding box for connection points that are closer toward the center and offset; much like a Semi truck tractor. And then I was going to make the trailer part as another type of wagon. But the selection and collision box seem to be aligned the same so .. I can't move the selection box to the left when the tractor would be facing horizontally... and there's no horizontal shift correction, only vertical_shift.
I know it's really not that difficult to rotate around an origin 0,0.... and it must have taken some intersting math to get this effect out.
I'd probably have to settle for a single image that's a semi with trailer that just moves flat around a road (when alternate track types ever get implemented) but I decided I could just enforce the constraints manually and just never merge the track types but always make them cross instead so trucks will stay on truck rails (roads) and trains on train rails.
Selection Box coords; support for semi-trucks.
Re: Selection Box coords; support for semi-trucks.
Really not sure if I understand this... Your problem is that the collision/selection box always rotates around its center, ignoring the initial 0,0?
If so, what you could try is doing the offset in the sprite. Not sure if this is helpful for you issue as I don't quiet get it
If so, what you could try is doing the offset in the sprite. Not sure if this is helpful for you issue as I don't quiet get it
Re: Selection Box coords; support for semi-trucks.
not around 0,0... it rotates around 0, (ymax-ymin/2) and does not shift horizontally at all.
in the left facing horizontal position, the selection box should never be further to the right than the -1,-1, 1,1 box. it should be more to the left in the horizontal position.
the sprite itself is making this hard to see because of the semi fake perspective.... maybe I should make a flat paper sprite with a 0, 0 mark on it.
in the left facing horizontal position, the selection box should never be further to the right than the -1,-1, 1,1 box. it should be more to the left in the horizontal position.
the sprite itself is making this hard to see because of the semi fake perspective.... maybe I should make a flat paper sprite with a 0, 0 mark on it.
Re: Selection Box coords; support for semi-trucks.
cleared image offset, cleared vertical selection offset...
where selection ends up... and what I would expect....
where selection ends up... and what I would expect....
Re: Selection Box coords; support for semi-trucks.
Good idea, maybe even draw a grid on it.d3x0r wrote:maybe I should make a flat paper sprite with a 0, 0 mark on it.
- eradicator
- Smart Inserter
- Posts: 5207
- Joined: Tue Jul 12, 2016 9:03 am
- Contact:
Re: Selection Box coords; support for semi-trucks.
As far as i can tell from building bounding boxes (trains probably work similar) the game tries to snap objects either to the center of a single tile or the intersection point of four tiles. So an object of {{-0.4,-0.4}{0.4,0.4}} would be centered on the tile it's placed on but an object {{-0.9,-0.9},{0.9,0.9}} would be centered on a tile intersection. If the game tried to center the second entity on a tile center it would occupy 3*3 tiles instead of the expected 2*2.
So in conclusion i think you're observing the game trying to guess the "least number of tiles occupied". And because you're using integer collision boxes (i.e. {-1,-1]{1,1}) instead of slightly-smaller-than-a-tile boxes the algorithm produces unexpected results. If you substract 0.05 from all sides of the boxes (like all the base entities do) this would probably be fixed.
So in conclusion i think you're observing the game trying to guess the "least number of tiles occupied". And because you're using integer collision boxes (i.e. {-1,-1]{1,1}) instead of slightly-smaller-than-a-tile boxes the algorithm produces unexpected results. If you substract 0.05 from all sides of the boxes (like all the base entities do) this would probably be fixed.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Re: Selection Box coords; support for semi-trucks.
It only centers the X axis.
if the bounding box was [1,1]- [2,2] it would be one tile. and rotating it in any direction it's still one tile.
okay that's a bad example since it's diagonal from the center... [-0.5,1]-[0.5,2] would be one tile no matter which direction it's turned but pivoting around 0,0 would still be expected... but I wouldn't expect it to collide with something that ended up with another bounding box that is [-0.5,-0.5] - [0.5, 0.5] (where the diagonal would only be out to 0.707).
But I realy wouldn't expect the offset bounding box to stay centered on [0,x] ... 'sides tile counts shouldn't really matter anyway; the whole sprite is apparently 4x4 anyway.
If it was a box on a static building block, there would only be the 4 direcitons,,, so rotating the building 90 clockwise, [-0.5,1]-[0.5,2] would be at [1,-0.5]- [2,0.5] but it actually ends up at [-0.5, psh I don't even know...]
Looking back, I didn't carry the investigation to the other directions (180 reversed, and 90 reversed)
if the bounding box was [1,1]- [2,2] it would be one tile. and rotating it in any direction it's still one tile.
okay that's a bad example since it's diagonal from the center... [-0.5,1]-[0.5,2] would be one tile no matter which direction it's turned but pivoting around 0,0 would still be expected... but I wouldn't expect it to collide with something that ended up with another bounding box that is [-0.5,-0.5] - [0.5, 0.5] (where the diagonal would only be out to 0.707).
But I realy wouldn't expect the offset bounding box to stay centered on [0,x] ... 'sides tile counts shouldn't really matter anyway; the whole sprite is apparently 4x4 anyway.
If it was a box on a static building block, there would only be the 4 direcitons,,, so rotating the building 90 clockwise, [-0.5,1]-[0.5,2] would be at [1,-0.5]- [2,0.5] but it actually ends up at [-0.5, psh I don't even know...]
Looking back, I didn't carry the investigation to the other directions (180 reversed, and 90 reversed)