Talk:PlaceAtMe

Distance and Direction

I was recently asked if PlaceAtMe's optional parameters determining distance and direction have any effect, and when I tested it out via the console they didn't seem to have any effect on the placement of the new reference. Can anyone confirm that these parameters are just vestigial from Oblivion?
-- Cipscis 01:29, 19 January 2010 (UTC)

In my experience when using PlaceAtMe in scripts, those parameters have never had any effect either. I'm aware you've already added this to the Notes - would it make sense to update the Example so people don't get the impression they do have an effect? I'd also wonder if we'd want to do anything to the Syntax definition, either omitting those parameters, or somehow noting right there that they have no effect. If there's other cases of this kind of thing, maybe it'd make sense to add a "Deprecated" flag to Template:FunctionArgument.

Related to this, I'm removing the following note (from the first revision of the CS Wiki's PlaceAtMe page):

• If the placement location is not safe (in the air, in a wall, etc), the object will be placed at one of the other axes or at the object's exact location.

...since it makes no sense, and what I think it's trying to say is untrue (at least in FO3). That is, the specified object is always placed at the exact coordinates of the calling reference, wherever that may be. Of course if both objects have collision and at least one is subject to havok physics, it will be pushed out, but this has nothing to do with PlaceAtMe.

--Hugepinball 18:13, 3 March 2010 (UTC)

Oops! I didn't realise when I added the note about those parameters that the example used them. I've fixed the example now.

I'd prefer it if the parameters were specified as deprecated, rather than removed completely, given that they're still recognised by the GECK's compiler. I've added a comment on the Template_talk:FunctionArgument page about this so we can discuss there how it should be represented.
-- Cipscis 01:31, 4 March 2010 (UTC)

Regarding removing the note about "safe" locations, I actually have observed the opposite behaviour: PlaceAtMe will always place the object in a "safe" location, at least if I actually make use of the "deprecated" parameters (set to 0 each). To force the object to spawn at exact coordinates and use Havok to "push it out", you need to explicitly relocate the placed object with SetPos. I have a FOSE version and a non-FOSE version of a cigarette carton destruction script, which uses PlaceAtMe to put a random number of generated cigarette packs and loose cigarettes at the exact coordinates of the now-destroyed carton.

The FOSE version uses a while loop to reposition all of the spawned objects at the exact coordinates of the carton (plus 16 units on the Z axis, so there is reduced risk of spawning underground). Then, an ultra-weak "fake force" explosion (also triggered with PlaceAtMe) gently nudges the packs all over. Using SetPos also counteracts the standard "fade in" that is typical of PlaceAtMe, forcing the object to materialise instantly.

In the non-FOSE version—which can't place 20+ randomly-generated objects in one frame without resorting to a ridiculous number of reference variables, and thus can't relocate the objects with SetPos—the packets and loose cigarettes spawn adjacent to the destroyed carton as if flying in formation, fading into the game, and are unaffected by the explosion effect.

scriptname JTCigCartonDestructionScript

ref tempref

float xpos
float ypos
float zpos
short ignorehit

short count

begin OnAdd Player
	set ignorehit to 0
end

;Cigarette cartons and packs lack the model data necessary to allow for a stage change based
; on destruction data.  Unfortunately, this means we have to ignore damage completely
; and just apply a hit counter.
;begin OnDestructionStageChange
begin OnHit
	if ( ignorehit < 1 )
		;In case a higher hit count in the condition is desired
		set ignorehit to ignorehit + 1
		return
	endif

	set xpos to GetPos x
	set ypos to GetPos y
	set zpos to GetPos z + 16
	
	set count to ( GetRandomPercent / 20 ) + 1
	if FOSE.isPresent
		Label 1
			set tempref to PlaceAtMe CigarettePack 1 0 0
			tempref.SetPos X xpos
			tempref.SetPos Y ypos
			tempref.SetPos Z zpos
			if ( count > 0 )
				set count to count - 1
				Goto 1
			endif
	else
		PlaceAtMe CigarettePack count 0 0
	endif
	
	set count to ( GetRandomPercent / 3 ) + 15
	if FOSE.isPresent
		Label 2
			set tempref to PlaceAtMe Cigarette01 1 0 0
			tempref.SetPos X xpos
			tempref.SetPos Y ypos
			tempref.SetPos Z zpos
			if ( count > 0 )
				set count to count - 1
				Goto 2
			endif
	else
		PlaceAtMe Cigarette01 count 0 0
	endif

	tempref.PlaceAtMe JTChemContainerDestructExplosion 1 0 0
	
	Disable
	MarkForDelete
end

I think what I'll have to do is test the script with and without the "0 0" parameters after the item count. It's possible one (or both) of these parameters do force a "safe" spawn, and if omitted the object spawns exactly. If so, that'd vastly simplify my script, although I don't know if the "fade in" would still exist.

--JT 19:05, 5 March 2010 (UTC)

Okay, testing results are in. The objects will spawn in a "safe" location if and only if multiple objects are spawned in the item count. The objects appear in a hexagonal pattern, offset by what looks to be 64 units at 60-degree angles, when using PlaceAtMe to spawn a large number of objects at once. The distance and direction parameters are indeed irrelevant. However, if you repeatedly call PlaceAtMe with a single object each time, ostensibly using FOSE to make a while loop, they will appear at the exact coordinates ignoring collision. The SetPos x and SetPos y in my script is irrelevant though the SetPos z is still necessary. --JT 19:36, 5 March 2010 (UTC)