Discussion in 'Bug Reports' started by Xyaminou, Mar 1, 2017.
Turns out this is what was blocking turret placement on Cyclopean's battlements, and still it never got fixed.
Correct me if I'm wrong but I'm pretty sure all it takes to change something like that is changing one value, so how about it?
I'm guessing due to.....
Vector vecMax = collisionOffset + Vector(collisionRadius, collisionRadius, collisionHeight + 50);
... since a turret is only about 12 high to begin with.
If there needs to be a height buffer for buildings and turret, then maybe it should be a percentage of the object height instead of a hard number....
((int)collisionHeight * 1.2) or something similar.
Client files / emp_commander_building.cpp line 200
I wonder if this is a quick fix to some exploitable bullshit, like putting a turret in a gap.
Only time will tell. And if it is... well now you have a reference thread with revert info.
You know what, I bet what it is... is that this is what prevents you from turreting vehicles.
I think you're confusing commander turret placement and engineer turret placement. We are talking about commander turret placement, you are talking about engineer turret placement.
That being said, engineer turret placement should definitely be more restrictive. Right now it's just "can you click there and is it on a slope that's less than 45°".
As for the multiplier, I think 10% should be plenty.
Thanks for bringing this up; I'm looking into it. Off the top of my head, this is scripts for each building, the vecmaxz property. Although, as Misfire pointed out, the visualization is height + 50, so the lines you see will be different from the actual effect.
I found that DDD has already posted an issue for this. #313
After some thought, I think using something like ((int)(collisionHeight + (log(collisionHeight) * 5))) might be more desirable.
For a very short 16 unit lv1 turrent it would make a placement box about 22 high. It's still a bit big, but much better than the current 66.*
As the height of the building increases, the amount of added "height buffer" decreases.
A barracks at around 80 units would have a placement box of about 89 units and a taller VF would add even less.
(If a barracks is about 80 units then the current placement box is about 130 high)
*My thinking is that by giving smaller objects a bigger placement penalty, it would make it harder to place them in "nooks and crannies" that might create map exploits.
Larger buildings already have their penalty built in, so it adds almost nothing to those.
Seems like a more primitive solution would work out better. We only have a handful of buildings in Empires, would be a bit simpler, and probably more effective to do it on a per building basis. Although the granularity is probably overkill anyway, I doubt there'd be an edge case that would necessitate this.
I thought it was done on a per building basis until Misfire replied to this thread with the formula. Empires doesn't have many buildings so it would definitely be the way to go, you would be able to fully control it without too much effort. It should just be added to the scripts.
I decided to look in the scripts for the collisionHeight values and play with them and now I'm confused. What are they actually used for? They don't seem to affect anything other than the placement box? If that's what they are then why do we need an extra formula on top?
And how come only some of the turrets have boundary values in the scripts?
BE's level 1 MG has it but level 2 and 3 don't and MLs don't.
As Tama pointed out this code seems to be just a related to the redbox visual aid that's drawn and not the actual placement physics.
I'll need to do more digging.
Mr.X... is there mention of "collisionHeight" in the scripts you're looking at?
Ah, yes I see.... buildings.txt
Turrets .... "CollisionHeight" "80"
So this extra height is set intentionally. Do any of the long-timers recall why?
X, it seems easy enough to adjust that script and then my code change would make the red box behave to more closely match the script.
There's always more that on solution, but I'd prefer a one-liner option that could satisfy all cases instead of maintaining a separate script and possibly needing to edit other classes. Especially if the buildings were to change or there were additions.
Yeahhhhh, that's the thing... I doubt there's going to ever be new buildings, and you'd get a better result by just doing it individually. That being said, it sounds like this would require a refactor so maybe not.
I've already got a couple of small things in mind, so never say never.
The "visual aid" as you call it actually reflects the changes in the scripts, so I really don't know what the formula actually does.
I will need to do more tests, it's hard to tell when I don't really know how much "60" really is.
Definitely needs testing.
"60" is a steam unit of measurement. 1 unit is 1 inch. But in steam everything is about 1/3 scale.
For reference a player is height is 32 units.
Not confusing at all.
Both the script and code refer to "collisionHeight" so that's how they're related.
Other levels of buildings will inherit the base parameters of the first one. I'm not sure about the ml turret, if it looks the same as the mg it could be inheriting from it.
Also PYA, you can add virtually any tiers of buildings just through scripting(research is supported), with changes to the model just like turrets. So you can upgrade armories to be little pillboxes or towers if you wanted to.
Characters are 72 hammer units in height, so that makes them their height around 1.3 meters.
Separate names with a comma.