Problem with object offsets and Spring.CreateUnit

[Argh]

I had a big problem with some fences tonight, where I was building the scene in World Builder then playing it back, and the fences were coming out wrong- offset visually from where they were supposed to be. The funny thing was... they were right when first built by the World Builder editor... they were only wrong when I played the resulting script back.

After much work, cussing etc. (at first I thought it was a serious flaw in my write logic, since that was the most obvious location for a fault) I eventually determined that the offset was because I'd moved the centroid of the hitspheres (the fence sections are 1 footprint deep, and must lie along the back of that footprint to operate correctly, and I moved the centroid back).

I finally caught it when I did a check vs. footprint coverage, and discovered, to my consternation, that the fence was offset in the relative Z visually, but the footprint was correctly positioned in the gameworld.

IOW, it's a visual glitch, but a rather serious one (my scene was basically ruined until I found the problem). This appears to be strictly some goofy behavior in the Lua callout Spring.CreateUnit(), and probably nobody's really seen it before because very few hitspheres are offset in the X or Z axis, and other than me and the Chicken Mod, hardly anybody's been using that functionality yet.

It only affected the axis that it was offset on, and as I said, the effect was visual only- the object was exactly where WorldBuilder told it to spawn, in every other respect. Whatever it is, it's tied explicitly to Spring.CreateUnit() in some way, because the fences are visually correct, and not offset, when built the "normal way".

At any rate, I have it fixed on my end, and so if everybody wants to just write it off as a "non-problem" for now, that's fine with me, although I suspect that this might be a quick fix.

[lurker]

Can you be more specific about exactly how they were offset?

[Argh]

So far as I can tell, without repeating the error condition (which I'll get to tomorrow evening, I really have to go to bed soonish) they were offset visually by exactly the amount that the centroid was offset. I.E., I had the centroid offset in the Z axis - 7.8 units in UpSpring (i.e., half a footprint), and they were getting offset about 8 units visually (in relative Z, not absolute) when placed by Spring.CreateUnit(), whereas they were correct when built otherwise.

[Gnomre]

We had a similar problem with our upgrades. One in particular with an emit-sfx'ed smoke CEG, where the smoke would always emit from the wrong place (I forget exactly how), instead of the location of the emit piece itself. This only happened when upgraded (using CreateUnit of course), but the smoke was fine if you normally built it or /gave it. I inadvertantly fixed that when I was fixing something else, related to the spawn heading in CreateUnit, so maybe this will help:

Pre-fix:

Code: Select all

	local px, py, pz = Spring.GetUnitBasePosition(unitID)
	local newUnit = Spring.CreateUnit(udDst.name, px, py, pz, 0, Spring.GetUnitTeam(unitID))
	Spring.SetUnitRotation(newUnit, 0, -Spring.GetUnitHeading(unitID) * math.pi / 32768, 0)

Non-borked CEG:

Code: Select all

	local px, py, pz = Spring.GetUnitBasePosition(unitID)
	local heading = Spring.GetUnitBuildFacing(unitID)
	local newUnit = Spring.CreateUnit(udDst.name, px, py, pz, heading, Spring.GetUnitTeam(unitID))

	if(udSrc.speed > 0) then --only mobile units being upgraded should be rotated
		local rot = Spring.GetUnitHeading(unitID)
		Spring.SetUnitRotation(newUnit, 0, -rot * math.pi / 32768, 0)
	end

If you're using SetUnitRotation for building orientation then I'd at least take a look there. Otherwise, disregard this post

[Pressure Line]

So far as I can tell, without repeating the error condition (which I'll get to tomorrow evening, I really have to go to bed soonish) they were offset visually by exactly the amount that the centroid was offset. I.E., I had the centroid offset in the Z axis - 7.8 units in UpSpring (i.e., half a footprint), and they were getting offset about 8 units visually (in relative Z, not absolute) when placed by Spring.CreateUnit(), whereas they were correct when built otherwise.

one way to "fix" that is in UpSpring. once you have offset the object from 0,0,0 (in your case to 0,0,7.8 ) hit the 'only move origin' button, and move the origin back to 0,0,0

if that doesnt fix it,, then yeah, a fix is probably needed.

[Argh]

one way to "fix" that is in UpSpring. once you have offset the object from 0,0,0 (in your case to 0,0,7.8 ) hit the 'only move origin' button, and move the origin back to 0,0,0

It's not the actual center location of the Unit's base Piece, it's the center of the hitsphere that's causing this. IOW, an offset of the hitsphere causes a visual offset of the Unit's geometry when Spring.CreateUnit() is used.