Jump to content
Sign in to follow this  
Snyder

Spawning units inside buildings

Recommended Posts

I would have thought this would have been answered before but I searched and came up empty.

How would you spawn enemy soldiers inside of a building? I'm sure it has something to with adjusting height but how would I do that?

Example, there is a 3 story building.

What would I have to write for one unit to be on the 1st, 2nd, 3rd floor and the roof?

Share this post


Link to post
Share on other sites

On the roof? Just put the unit over the building in the editor... spawning them by code you'd need the height of the roof to spawn them onto I think.

Many buildings have set positions though (when you're in command of another unit, press space and look at a building, it'll come up "position #1" etc on some). First thing you need is the building's ID number - open the editor, click IDs and zoom in on the building. Make a note of the number on it. For this example I'll assume it's 123456 and you're trying to put the unit in building position #2.

Place a unit next to the building, and in the unit's init code put the following:

this setpos (((getpos this) nearestobject 123456) buildingpos 1);

Done.

If you want to add them to the building later, by script, you need to define the building. Put an object next to the building (a Logic, a unit, whatever) and in it's init put:

TheBuilding1 = nearestObject [getpos this, 123456];

(or, if you created the object by script, it'd be TheBuilding1 = nearestObject [getpos YourNewObject, 123456]; instead).

Then just setPos the unit:

YourUnit setpos (TheBuilding1 buildingpos 1);

Share this post


Link to post
Share on other sites

Example, there is a 3 story building.

What would I have to write for one unit to be on the 1st, 2nd, 3rd floor and the roof?

Ever had the problem that if you put the units in the building as a group, sometimes they die falling of the roof because of getting into formation? I could only solve this using disable ai "move" for the units that needed it.

Share this post


Link to post
Share on other sites

Why did BI have to make it so difficult to do such simple things? They really need to make it much more convenient and easy. Not everyone knows how to script like a pro. Thank you for your help I will try that.

Share this post


Link to post
Share on other sites

I prefer to use ungrouped units and then use dostop unitname

It would be handy to have a no formation command though as it a pain at times.

Share this post


Link to post
Share on other sites
Why did BI have to make it so difficult to do such simple things? They really need to make it much more convenient and easy. Not everyone knows how to script like a pro. Thank you for your help I will try that.

It's really not that difficult. It's rather just that a lot of people don't know the best way to do it and thus make it more complicated than it needs to be.

Share this post


Link to post
Share on other sites

It would be handy to have a no formation command though as it a pain at times.

yep, you can set it to none in the editor, but they always move back into formation soon as game starts. Only solution is to stop letting them move, but the downside is for ex: they don't go for cover when shot at, you know they stay at that pos.

Share this post


Link to post
Share on other sites
yep, you can set it to none in the editor, but they always move back into formation soon as game starts. Only solution is to stop letting them move, but the downside is for ex: they don't go for cover when shot at, you know they stay at that pos.

Um.. no. DoStop works perfectly fine. You don't have to disable them.

Share this post


Link to post
Share on other sites

On the subject of formation Dawg do you know how to dismiss a group other than using a waypoint?

group setformation "dismissed"

does nothing.

Share this post


Link to post
Share on other sites
On the subject of formation Dawg do you know how to dismiss a group other than using a waypoint?

group setformation "dismissed"

does nothing.

Depends on what you mean by dismiss. TBH I'm not really sure what the dismissed WP does (never use it). But if you tell me what the desired effects are I can probably think of something.

Share this post


Link to post
Share on other sites
It would be handy to have a no formation command though as it a pain at times.

Actually it should be a waypoint (like the "DISMISS"-ed one which also has no formation but keeps the "dismiss"-fsm running), without any fsm running at all. And I'd totally vote for it.

Um.. no. DoStop works perfectly fine. You don't have to disable them.

So... is the wiki inaccurate then? It states that: "Stopped unit will not be able to move or fire." (doStop, commandStop)

And I guess we actually do want them to fire, no?

But if you tell me what the desired effects are I can probably think of something.

The dismiss waypoint has no group-level fsm running (no leader acting, thus no orders like: back to formation). Instead every single unit has some fsm running, which keeps them moving randomly along, running some special animations and so on. (though this is more guesswork here than knowledge, sorry)

Edited by ruebe

Share this post


Link to post
Share on other sites

They do fire and will mount a static gun if they have a waypoint on then and the gun is empty or at least they did last time I tried it, today they don't feel they want to man the gun.

Edited by F2k Sel

Share this post


Link to post
Share on other sites
So... is the wiki inaccurate then? It states that: "Stopped unit will not be able to move or fire." (doStop, commandStop)

And I guess we actually do want them to fire, no?

Yes.. It is completely wrong. DisableAI might stop them from firing, and certainly from moving, but doStop will never do either. Also, doStopped units will move if they feel the need (ex: find a medic, ammo, or man a vehicle), they just won't stay in formation. Please fix it on the wiki.

As for the dismissed behaviour... Sounds kinda pointless. Why keep the units grouped if they aren't going to be communicating or moving together? I would just disolve the group and make them wonder around aimlessly with a simple script or some waypoints.

Share this post


Link to post
Share on other sites
Um.. no. DoStop works perfectly fine. You don't have to disable them.

well then what's the difference between disableai "move" and dostop Dawg?

edit : ok just saw your post above:)

I can say disableai "move" doesn't stop them from firing (at least every time I encountered it...)

ok good idea, but on the buildings? they will fall off using dostop then? I think so.

Edited by dematti

Share this post


Link to post
Share on other sites
well then what's the difference between disableai "move" and dostop Dawg?

I'll put it this way. DisableAI is a hard disable. That is, it will force the AI to stay put and not every allow him to move. The problem is that turning their bodies is considered a move (has it's own animation and everything), so disableAI "MOVE" will make them fixed in a single direction.

DoStop is a soft disable. It will prevent them from moving around with their group, but is still able to turn around and even move to a new position if they see fit. They will still respond to orders from their group leader (like engage, rearm, board a vehicle), but all of their actions will be seperate from the group formation (unless ordered to return, which AI leaders don't do unless a script tells them to).

DisableAI should only be used when you don't need the AI to function independently.

---------- Post added at 09:14 AM ---------- Previous post was at 09:10 AM ----------

ok good idea, but on the buildings? they will fall off using dostop then? I think so.

This depends. If a unit is on a roadway LOD then doStop will work (they won't move). Even better, if they are on (or near) a valid buildingPos, even if they do move they will find the building pathway and follow it to exit the building. The only time I can see the AI falling off of a building while they are doStopped is if you place them on a building with no roadway LOD (ex: buildings you can't even stand on, not even the player). There's no way to place units, AI or player, on buildings with no walkable surface. To the game it's just a really big obstacle. Fortunately for us though, most of the buildings on Chernarus have proper roadway LODs, and all of the ones that are enterable all have proper (and mostly good) AI pathways.

Share this post


Link to post
Share on other sites

As for the dismissed behaviour... Sounds kinda pointless. Why keep the units grouped if they aren't going to be communicating or moving together? I would just disolve the group and make them wonder around aimlessly with a simple script or some waypoints.

I was testing it for something else, I wanted a group to flee without the stopping and aiming that they do in safe or careless mode, dismissing them does this upto a point.

You can still control them as a group just not in formation which stops a lot of the messing about if the leader is killed.

I just found out the dismissed command doesn't do what I thought it was doing, as soon as you order the group to move they get back into formation.

Edited by F2k Sel

Share this post


Link to post
Share on other sites

Ok I got it. Duala doesn't have that many rooftop LODs, and if there are, you can tell wich building has it and wich ones don't. So you can exclude more than half of the buildings as beeing a possible enemy position.

Anyway, thanks for explaining this man!

Share this post


Link to post
Share on other sites
Yes.. It is completely wrong. [...] Please fix it on the wiki.

Done.

As for the dismissed behaviour... Sounds kinda pointless. Why keep the units grouped if they aren't going to be communicating or moving together? I would just disolve the group and make them wonder around aimlessly with a simple script or some waypoints.

For one, there is a group-limit and a group doesn't come without some overhead. Also it's natural in lot's of situations to keep units in a group, although the units are acting individually. For example imagine you set up a group with such a non-group-activity waypoint and run individual scripts/fsm for each unit in this group. Then something happens, an enemy gets spotted, we abort the individual scripts/fsm and rejoin the group with a waypoint that kicks group-activity back in.

Share this post


Link to post
Share on other sites
For one, there is a group-limit and a group doesn't come without some overhead. Also it's natural in lot's of situations to keep units in a group, although the units are acting individually. For example imagine you set up a group with such a non-group-activity waypoint and run individual scripts/fsm for each unit in this group. Then something happens, an enemy gets spotted, we abort the individual scripts/fsm and rejoin the group with a waypoint that kicks group-activity back in.

Well, it's mostly personal preference. I think it works better, when units are acting independently, to keep them as seperate groups. Why? Because when I think of dismissed I think that units are not going to be communicating with the rest of their squad or even aware of where they are/what they are doing. What does it matter you ask? When they see the enemy, it makes a huge difference if they are in a group. When one guy sees someone, the whole group knows right away. This is the kind if behavour I don't want for "dismissed" units. I want them to act independently, and only after actually finding/reporting in with the rest of the squad will I join them all up into one group.

Share this post


Link to post
Share on other sites

EDIT:

Actually that does somewhat work, though I've opted to use:

this setPos ((position this nearestObject 967423) buildingPos 2)

Note: There is no need for a ";" at the end when placed in the init field of the unit in the editor when it's the only string or the last string, wasted bit, takes eight to make a byte, you see where this is going... The editor will add one regardless, so it just becomes extra.

Looks like the first position is for a building is always 0 rather than 1 so this causes some confusion, particularly if your using Grizzle's "Visual House Position Module" from here:

http://www.armaholic.com/page.php?id=11288

It shows the first position as 1 instead, so for every position listed you have to subtract 1 to get the correct position, Ex. 1=0, 12=11, 15=14, etc.

On the roof? Just put the unit over the building in the editor... spawning them by code you'd need the height of the roof to spawn them onto I think.

Many buildings have set positions though (when you're in command of another unit, press space and look at a building, it'll come up "position #1" etc on some). First thing you need is the building's ID number - open the editor, click IDs and zoom in on the building. Make a note of the number on it. For this example I'll assume it's 123456 and you're trying to put the unit in building position #2.

Place a unit next to the building, and in the unit's init code put the following:

this setpos (((getpos this) nearestobject 123456) buildingpos 1);

OK, so I searched, that works fine if your just doing one unit or they are far enough apart however using several units with buildings close to each other like across the street this fails and the units start showing up in the wrong buildings.

So, does anyone know how to assign it to a specific building?

Edited by callihn

Share this post


Link to post
Share on other sites
Ever had the problem that if you put the units in the building as a group, sometimes they die falling of the roof because of getting into formation? I could only solve this using disable ai "move" for the units that needed it.

That's simple move them to the positions you want and set the "Special" field to none then they spawn how you want them to :)

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×