[how to] Find a 3do unit's ingame height

[Nemo]

Backstory:
So. A lot of cool scripting tricks depend on knowing what unit you're dealing with, and the best (or only..) way to do that is by checking the heights of the units.

Examples of these tricks include using zwzsg style 'raw' transports (which depend on unit heights so that they don't load everything around them), or upgrades (see CvC v0.4), and basically any behavior that stems from the existence of a specific unit.

I was struggling to get an accurate height for a 3do model because the source just says "height=height" and that wasn't incredibly helpful to me (it probably spells it out somewhere, but I wasn't skilled enough to find it..), UpSpring doesn't give an accurate reading for 3dos, 3dobuilder doesn't give heights...ect, ect.

How to get the height of a 3do unit:
Create a transport which can load anything of any size. If you're confused about this, find a transport in any mod and copy its FBI, then crank up all the values that have "transport *" next to them.

Next: go into the script for that transport and find where it says TransportPickup(unitid). Add this line inside the brackets:

Code: Select all

SET VETERAN_LEVEL to (get UNIT_HEIGHT(unitid)*100)

And poof. Now whenever that transport loads a unit, the exp value of the transport will be the exact height of the unit it loads. Then write down that value, and you're good to go.

This works for s3os too, but they have much easier ways of figuring out heights (ie, 65536*radius).

If you get errors about VETERAN_LEVEL, just put

Code: Select all

#define VETERAN_LEVEL  		32 

at the top

Hope this is helpful to people.

PS. I didn't know about Zwzsg's cool caliper unit when I went about doing this. I don't know if that works in spring or not, but if it does, I'm sure it would work equally well, if not better.

[KDR_11k]

I made a counter unit that will show you the exact number but I think this'll work better.

[rattle]

This kinda replaces your counter unit. Is XP limited to some value? If you begin to check heights be sure to convert them, i.e. height=height/[1];

[KDR_11k]

[1] is significantly larger than 1 elmo. Also the height rounded to elmos will make it useless for identifying units as too many will have the same height after rounding.

[FLOZi]

Ah, I knew someone had made a counter unit. Got the wrong german though.

[zwzsg]

Or:
- Download my caliper
- Include it into your mod, or simply drop the ufo into Spring root.
(Leaving ufo in root is VERY dangerous, it creates synch error if you don't remove it before going online multiplayer.)
- Run settings.exe, set Spring to windowed, half your screen size.
- Run Spring
- Type:
.cheat
.give caliper
.give the_unit_you_want_to_measure
- See and recopy value
- Type:
.give another_unit_to_measure
- See and recopy value
- Repeat until all needed units are done.



My explanation seems lengthy because I can't help but type all the details, but honestly, this is the most efficient way to get the height of all units. (Until trepan comes with a three lines LUA spell outputing the whole height list of all units completly automatically, I guess.)

Also, I always found odd that apparently KDR_11k made his own counter unit, unaware of mine. Even checked the code, seems all his own. And I made mine unware of SOI_Sentinel's one, but his wasn't ever finished or released, so it's more understandable. Yet I am positive I mentionned and even linked to the caliper every time I talked about scripts needing unit identification by height.

[MadRat]

What is this measuring when you say unit height? The numbers are extremely large for any unit of measure I'm familiar with in Spring.

[FLOZi]

A unit you are not familiar with.

[zwzsg]

It is the result of get UNIT_HEIGHT()

It use the real internal units. Indeed they are very large numbers. So, when writting scripts, the Cavedoggies said, hey, would it be nice if instead of writting 10 000 we could just write 1, and have all distance multiplied by some factor? Yeah sure. So they made it so every number betwee [ ] would be multiplied by a constant. At first that constant was 65536, which was neat because it's a very round number, hexadecimal wise, and because 65536 equaled one pixel ingame. Internally, every position in TA are stored on four bytes, the two higher bytes being the pixel position, the two lower bytes being the position within the pixels. So [1] in a script was equal to 65536 was equal to one pixel, and it was all pretty neat.

Then something scrounched, I guess they resized all units without wanting to rewrite all scripts or something, and instead they used: [ ] means multiplied by 163840. And it was less neat, because [1] would equal 2.5 pixels, and it wouldn't fall right betwen the two low and the two high bytes. But it worked and so it stayed. When some fan later made 3do builder, instead of giving you some unreable overlage coordinate, they used the same distance multiplier, so that you'd write for instance 1 in 3do builder menu for 2.5 pixel ingame for [1] in a script.

Then Spring was made. Well, it's like TA, but with the zoom you can't talk about pixel anymore. The exe use for unit script the compiled cob, with already the multiplier applied, so it doesn't care about what it is.

Then jcnossen made UpSpring. He thought, 163840? What kind of f*ed up multiplayer is that? Let's use 65536 instead, makes more sense to use a round number.

Of course every modder around the world had kept their Scriptor (the prgm that turns source unit script into compiled unit script) settings with a multiplier of 163840, so much confusion ensued, since there was a 2.5, or 0.2 depending which way you look at it, factor between UpSpring and the tradionnal TA distance notation of Scriptor and 3do Builder. But little did jcnossen cared.

Anyway, point is, the coordinate and height you usually see use small number because they're scaled right before being displayed and right after your input, they're scaled using an abritrary factor Spring.exe doesn't care about, and they're scaled only so a regular unit has dimension written in number a human mind can handle. But internally it really use the large numbers you saw in my picture.

Of course you could write:
#define ARMMLV [11.48]
instead of
#define ARMLV 1881478
Since after all [11.48]=11.48*163840=1880883
Problem is, as you can just see, there would be rounding errors. 1880883 isn't perfectly equal to 1881478. The difference is small enough to be overlooked when writing an animation, but nevertheless a == test would fail, and so if you don't use the real values, all the nice unit identification script you'll write around would fall apart.

[trepan]

Assumes the SVN DoLine widget is running:

Code: Select all

/luaui echo math.floor(65536 * Spring.GetUnitRadius(Spring.GetSelectedUnits()[1]))

The COBSCALE constant (65536) is also available, but only to synced scripts at the moment.

P.S. To use this, select a single unit, type in the line, and hit enter.
You can also paste the line using CTRL+V, and use the up arrow
for following invocations. A proper widget could be made to display
all kinds of unit information (I have one, but it's part of a framework
that will not be released for a while).

[KDR_11k]

Whenever Spring uses a float it's usually multiplied by 65536 if you get it because COB don't do float.

All this different scale stuff annoys me, tho. Can't we have brackets that mean "multiply by 65536"? Sounds like Spring is a hack layer over a hack, doubly confusing.

[Argh]

Download latest UpSpring.
Convert to S3O.
Set height.
Save converted model.

[KDR_11k]

But that means you have one texture atlas per unit instead of a global one which can waste a LOT of texture memory.

[Argh]

<shrugs> if it's that critical of an issue, you can always limit that to the things where it actually matters. However, as my project now has about 40 S3Os in-game, I'm not really noticing much of a problem, and I'm tempted to just go ahead and convert all the remaining models just to see what happens.

[KDR_11k]

Are those s3os made from 3dos, though? A handmade s3o has a much more efficient texture use. Automatic s3os would introduce a lot of redundancy to the texture memory (unless you can predict how the tex atlas will look, map the s3os accordingly and use a bug to make it use the tex atlas...). Since the only limit 3do makers kept in mind was the 2048x2048 total limit they probably didn't care much how many textures each unit uses. Of course I don't think they'll hit the limit of a modern gfx card but careless use could cause severe framerate issues for users of those old computers many still use for Spring (no idea what'd happen if one of these super-large TA mods gets converted completely...).

[zwzsg]

All this different scale stuff annoys me, tho. Can't we have brackets that mean "multiply by 65536"? Sounds like Spring is a hack layer over a hack, doubly confusing.

Use UpSpring instead of 3do Builder. In Scriptor, press Alt F7 and set your own constant. Then there won't be anything using the 163840 anymore.

Problem is, most BOS assume the constant is 163840 and no 65536. So much mayhem and confusion will ensue when you'll trade source BOS scripts with other people.

[Argh]

@KDR:

Well, I'm working on one of those, so I guess we're going to find out. I'm evaluating whether 3DOs that weren't modeled too poorly can be "salvaged" and re-used as S3Os, and the first step is to get them exported. I just wish that more of the models I'm dealing with weren't of rather poor quality- the way that people made things look good with 3DO really limited the overall quality of the art, frankly. That, or people just make much better models these days, or the original artists weren't very good.

[KDR_11k]

Alt F7 to change the multipliers? Thanks for the tip.

[rattle]

Yeah it's in the options. Thanks for the explanation, didn't know that.