TA:K
Moderator: Moderators
-
Necronator
- Posts: 8
- Joined: 13 Jun 2007, 11:09
TA:K
Someone should make a Total Annihaltion: Kingdoms mod.
-
Necronator
- Posts: 8
- Joined: 13 Jun 2007, 11:09
-
Machiosabre
- Posts: 1474
- Joined: 25 Dec 2005, 22:56
-
Necronator
- Posts: 8
- Joined: 13 Jun 2007, 11:09
well, if you changed every hit sphere to just fit the exact size of the object, tho every hit sphere would have to be different, or make everything relatively the same size
Last edited by Necronator on 13 Jun 2007, 11:50, edited 1 time in total.
The problem is that tons and tons of aiming and damage-handling code would need to be revised. Imho, the revision is necessary, as this is really a bug that exists for any case where you're attacking a much-larger target with a short-ranged weapon.
Basically, the problem is that all distance calculations to target need to be calculated from the target's surface, not from it's centre. Theoretically simple, but tricky to actually do.
Plus, it could create more problems when/if more complex collision geometry is supported (why I prefer the multi-sphere approach to complex-collision-geometry - simply use the sphere that is at the lowest distance, where distance is as the definition above).
Basically, the problem is that all distance calculations to target need to be calculated from the target's surface, not from it's centre. Theoretically simple, but tricky to actually do.
Plus, it could create more problems when/if more complex collision geometry is supported (why I prefer the multi-sphere approach to complex-collision-geometry - simply use the sphere that is at the lowest distance, where distance is as the definition above).
Bingo.Pxtl wrote:The problem is that tons and tons of aiming and damage-handling code would need to be revised. Imho, the revision is necessary, as this is really a bug that exists for any case where you're attacking a much-larger target with a short-ranged weapon.
Basically, the problem is that all distance calculations to target need to be calculated from the target's surface, not from it's centre. Theoretically simple, but tricky to actually do.
Plus, it could create more problems when/if more complex collision geometry is supported (why I prefer the multi-sphere approach to complex-collision-geometry - simply use the sphere that is at the lowest distance, where distance is as the definition above).
I've got a patch that modifies 1 (one) function (except all the add-a-tag related stuff) that does this:
http://neoteric.pl/~imbaczek/spring/targetBorder.avi
as you can see, it makes the unit fire at the edge of the collision sphere instead of it's center. (I hope it's the collision sphere, at least ;p) you can make the weapon do that by setting targetBorder=1 in the weapon's tdf.
now I understand that this is not good melee implementation, but is it enough? there are some pathfinding issues, but nothing unsolvable. just tell me if this approach is workable.
http://neoteric.pl/~imbaczek/spring/targetBorder.avi
as you can see, it makes the unit fire at the edge of the collision sphere instead of it's center. (I hope it's the collision sphere, at least ;p) you can make the weapon do that by setting targetBorder=1 in the weapon's tdf.
now I understand that this is not good melee implementation, but is it enough? there are some pathfinding issues, but nothing unsolvable. just tell me if this approach is workable.
most melee units for either TA or spring have used a very short range laser to simulate the melee weapon unforturnately that doesn't work in spring due to the bump code and the target-center-of-unit code which apparently imbaczek fixed. Three cheers for imbaczek!!
however the bump issue still remains unless im forgetting some addtion to the modder's arsenal that removes the bumping...
however the bump issue still remains unless im forgetting some addtion to the modder's arsenal that removes the bumping...