[REQ] Y model offset

[Absolver]

I'm not even sure if this is possible to add, but I'm hopeful. And it might already be there, but I sure as heck can't figure out how to do it.

Some objects will appear to be partly under ground when they are spawned, and moving them about will not make them appear over ground. If you somehow add an Y offset to the model placement, an object can 'rest' on the ground, but the model itself will be lifted above ground and thus be usable as decoration.

An example of an object that exhibits this behavior is 4433 (staticobjects/wizard_spires/single_spire_1).

[Wdneq2]

Would be kool if available/worked. Not sure though as ive seen this happen in EQ and EQ2 (live servers), more so in EQ having to pull a mob out of a wall or especially in in old Highpass fighting the orcs in the tree

[LethalEncounter]

I could add in such an offset, however the placement of spawns should be the exact values from Live as that is where we get them. If they appear underground there might be a flag in the spawn that Live sets which we are not.

[John Adams]

I think Absolver might be creating his own spawns, not from collections. If not, collected objects that appear to "hover" (like the Torch of Ogguk in Big Bend) need to have the include_location flag set to 1, or to 0. I remember raw collected data hovering but by toggling this flag, placed it nicely on the ground where it should be.

LE can correct me if I'm wrong, but include_location means, use the zone's "location_id" to place the object - otherwise it's off in space somewhere, and all that is really there is some artifact from the zone graphics themselves.

[LethalEncounter]

LE can correct me if I'm wrong, but include_location means, use the zone's "location_id" to place the object - otherwise it's off in space somewhere, and all that is really there is some artifact from the zone graphics themselves.

That flag actually tells the widget to use the location data in both the regular data positions as well as the widget specific data position. That probably doesnt make sense, but there are two sets of locations in the widget data and using this sets both of them

[John Adams]

That's probably more what I meant, I just didn't really understand why toggling the value worked, just that it did. Thanks for clearing it up.

[Absolver]

To clarify, what the intent is in having that offset value, is making an asset able to 'stand' on the ground, rather than disappearing into it. Perhaps an easier way to do this (And more consistent, at that) is to set a flag that either (1) makes the object stay at its assigned coordinates, unaffected by gravity, or (2) makes it unmovable at all, except through /spawn set x/y/z and orientation?

[ZexisStryfe]

Might this also help for flying mobs?

[John Adams]

I am not real clear what the issue is here, so forgive my lack of understanding.

When you place a spawn in the world, you give it an x,Y,z coordinate. Whatever 'Y' is, is where the spawn sits above or below the terrain. Example, in our Queen's Colony, we have Hawks that are spawned up in the air, far enough out of reach where a ranged attack is all that will bring it down.

If it were true that 'Y' has no functionality, these hawks would be spawned on the ground along with the deer and bears.

Why do you need an offset, when you can simple add or subtract the 'Y' value and raise or lower it? If your request is to allow a spawn to seemingly randomly appear at ground level once, then above ground the next spawn, or below ground the next, then I can see a need for a 'Y' offset (which btw we already have in spawn_location_placement).

What is the actual problem, if any? Explain it to us simple folks

[Absolver]

The easiest way is perhaps to see this in action.

1) /spawn create object 4433 1 1 "Wizard spire" 1 32
2) Do a /spawn details and then /spawn set y +50 of the current value to move it up into the air
3) The object will fall back down to the ground.

The Y might be preserved for NPCs, but objects seem to obey the laws of physics.