View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021655 | AI War 2 | Gameplay Issue | Sep 16, 2019 12:38 pm | Sep 17, 2019 8:40 pm | |
| Reporter | RocketAssistedPuffin | Assigned To | Chris_McElligottPark | ||
| Severity | minor | ||||
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 0.890 Lighting and Darkness | ||||
| Summary | 0021655: Buildings can be put together close enough to really overlap | ||||
| Description | Can see in the image the Station and Factory on the left are overlapping badly. In between the Station and the second Factory, I can fit in a Forcefield, which immediately decollisions away from everything. You can CTRL build 5 Turrets to see overlap there too. Save just has that set up prepared. It seems to be only the center point of a structure is checked for if you can place it there or not. I'd suspect this is a large cause of the issue with the Forcefields decolliding. This is done with the fix to that issue. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Thanks! * You can no longer place units overlapping on top of one another. Previously it was allowing you to do that, which could lead to all sorts of accidental structural placements as things moved out of the way of where you invalidly put them. ** There's now proper interface feedback about this and everything. * Additionally, fixed a bug where auto-placing a group of units would let them partially overlap as well. All of the logic is now centralized to not have that happen. |
|
|
Still seems possible to put Forcefields in positions to decollide when finished with this. |
|
|
I believe I did this on purpose, but it depends on what you're placing things on. Essentially I made it so that if you place something down, it will only collide with things are either immobile, or a flagship or generate a forcefield, OR which have a higher or equal collision priority to it if the first conditions are not true. So it would intentionally let you place anything in a crowd of bombers, for instance. And the bombers should then move out of the way while the new thing sits there. If that latter part isn't working, then that's a problem. |
|
|
I think it's more to do with how imprecise the range check for decollisions are. If the forcefield is horizontally in line with the structures you build it can get much closer than at a 45 degree diagonal. This means you can place the forcefield just fine at that 45 degree angle, but as soon as it's done building it'll decollide somewhere else. |
|
|
It all started with the change to the decollision radius a while ago, when I submitted a fix so that decollision_planning always uses the largest radius of the two objects when calculating collision. |
|
|
Whatever the decollision checks are using, the GetIsSafePointToPlace() (or whatever it's exactly called) method should also use. If it's using square ranges rather than circular ones, that's fine, but it needs to be consistent between the two. And if it's using "largest radius of the two plus largest radius of the two," I think that will always give very strange results. It should be the radius of each of them added together. Otherwise a small thing next to a big thing will always get knocked super far away. Would you happen to have time to look at that? It sounds like it will take some experimentation, and my notes are in svn recent checkins if you want to see what I put in. |
|
|
There was a recent rewrite of the decollision code from Badger, so it'll take a while to comb through it right now, but on first glance it does look like the range check was changed to (radius_of_source + radius_of_target + some constant). Will check right now. |
|
|
For decollisions, the logic is using a square check (GetHasAnyChanceOfBeingInRange) with the distance between points being ( source.radius + target.radius + constant (50) ) For placement, the logic is using a rough distance check (ApproxDistanceBetweenPointsFast) with the distance between points being ( source.radius (object being built) + target.radius ) So decollision is far more conservative than placing objects. Maybe the way to go would be to multiply the radius of each ship in the decollision code by .7 to get the inscribed square of the ships? |
|
|
Chris did the decollision rewrite. I just did a few minor bugfixes of his code |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Sep 16, 2019 12:38 pm | RocketAssistedPuffin | New Issue | |
| Sep 16, 2019 12:38 pm | RocketAssistedPuffin | File Added: ForcefieldCollision.save | |
| Sep 16, 2019 12:38 pm | RocketAssistedPuffin | File Added: BuildingCollision.jpg | |
| Sep 16, 2019 2:18 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Sep 16, 2019 2:18 pm | Chris_McElligottPark | Status | new => resolved |
| Sep 16, 2019 2:18 pm | Chris_McElligottPark | Resolution | open => fixed |
| Sep 16, 2019 2:18 pm | Chris_McElligottPark | Fixed in Version | => 0.890 Lighting and Darkness |
| Sep 16, 2019 2:18 pm | Chris_McElligottPark | Note Added: 0053148 | |
| Sep 16, 2019 5:31 pm | RocketAssistedPuffin | Note Added: 0053155 | |
| Sep 17, 2019 10:10 am | Chris_McElligottPark | Note Added: 0053161 | |
| Sep 17, 2019 12:39 pm | wm46 | Note Added: 0053162 | |
| Sep 17, 2019 12:41 pm | wm46 | Note Added: 0053163 | |
| Sep 17, 2019 1:33 pm | Chris_McElligottPark | Note Added: 0053164 | |
| Sep 17, 2019 7:23 pm | wm46 | Note Added: 0053165 | |
| Sep 17, 2019 7:58 pm | wm46 | Note Added: 0053168 | |
| Sep 17, 2019 8:40 pm | BadgerBadger | Note Added: 0053169 |
