Apples and Peaches: Obsttorte's Mapping and Scripting Thread

[Obsttorte]

So, as everybody seems to have his own mapping thread, I thought about starting my own.

 

I'm currently working on my map for the "unusual gameplay contest" and just set up a nice working elevator. I took a look one the multi-level elevator tutorial on the wiki and I think that my approach is much more easy to implement, so I thought I could describe it here.

 

The elevator consists out of three parts:

 

- a func_mover entity that will be our elevator-platform

- the buttons that will control the elevator

- a couple of waypoints, one for each floor

 

what else do we need: a really short script, I'll go to explain further down

 

The first step is to create an elevator-platform. This is your part . If your done with it change its classname to func mover (under entities/func/movers). Rename it to platform. (The names are for referance. Of course you can choose them as you like).

 

The next step is to create some path_corner entities and place them, where you want your platform to stop. Be aware that the origin of the platform entity will move to the center of the bottom face of the pink block representing the path_corner. Let the platform target the path_corners. Make sure you start with "target0", then "target1" and so one. Start with the lowest path_corner and move upwards level by level.

 

Create buttons for every floor on one of the levels. For the other you can just copy them around when we've set them up. On the buttons, you have to set three spawnargs.

 

- target: let the buttons target the platform (so you have to insert its name here)

- state_change_callback: set this to "movePlat". This is the name of the function we'll use to move the elevator

- moveDir: set this to "0" for the lowest button, "1" for the next one and so one. This spawnarg controls which path_corner the platform should move to

 

When you're done, copy the buttons to where else you'll need them.

 

Ok, that's the setup in Dark Radiant. Now everything that's is needed is a script. And here it is.

 

void movePlat(entity button,boolean bOpen,boolean bLocked,boolean bInterrupted) {
    entity mover = button.getEntityKey("target");
    entity target = mover.getEntityKey("target"+button.getKey("moveDir"));
    mover.moveTo(target);
}

 

The "state_change_callback" is called everytime when the state of the specific object was changed, for example if a button is pressed. The function receives four arguments, of which we will only need the first one. The entity that we get here is the one who has called the script. In this case, the button we have pressed. Now what does the code do.

 

The first line brings us the entity targeted by the button. This is our platform. We need to know this as we want to make it move

The second line gives us the path_corner the platform should move to. Here you can see why you should start targeting them from 0 upwards and what the "moveDir" spawnarg is used for.

 

An example: If you push a button whichs "moveDir" spawnarg is "1", than the platform targeted by the button will move to the path_corner targeted by the platform via the spawnarg "target1".

 

The last line is quite self-explaining. It tells the platform to move to the designated path_corner. That's it.

 

Pro's:

 

- short code that is used for every elevator in the map (in fact you can use it for everything that translates)

- fast setup

 

Con's:

 

- As I didn't tested it very much I don't know any if you find some please report here

 

What is missing:

 

- there are no sounds set up yet (will add them as soos as possible)

- AI's should not yet be able to use the elevator (dido)

Edited December 25, 2012 by Obsttorte

[demagogue]

I thought buttons couldn't pass self, only the activator (what pushes it, i.e., $player1) so you could never get a button's target. That was the whole debate with really needing a pass self function in the sourcecode, because not being able to get spawnargs off buttons and into scripts was awful. But maybe you can get it anyway. Did you at least confirm it basically works like it's supposed to. You press the right button and it goes to that floor?

 

If it works, then basically any conditional script should use this form, since you just set up a button (and its spawnargs) for each conditional you want to check for to any outcome you can imagine & cook up.

[Obsttorte]

I did check it with a two-state elevator and it worked perfect so far. Elevators with more stages should also work as the only thing that changes would be an additional button and a path_corner entity.

 

You may be aware of the fact that the above described function is called for every kind of state change. So even when the button closes again. The hole setup interprets the button more like a general mover moving from one state to another then as a button. You could use the same function on a door for example.

[Tels]

Swift Mazes uses the same state function to do all sort of aehm interesting things with doors and buttons

[Springheel]

If this does work you should add it to the wiki so it's not buried.

[demagogue]

Incidentally, FYI, there's a function to get a target directly.

You don't have to getEntityKey("target"). You can just "getTarget(n)":

I guess it's more important when your entity has multiple targets & you want to specify it by number.

 

"entity X = $<item>.getTarget(n);" (where n=the target number)

[Obsttorte]

Thank you for that tip.

 

As it does the same it is more for shortening the code, but that's also something useful.

 

If this does work you should add it to the wiki so it's not buried.

There are some things that I was told to add to the wiki. But I don't have write access and have no idea how to get it.

If anybody knows please teel me. Else I will post helpful stuff in this thread.

[Tels]

The method of "getTarget()" is does also not work with multiple targets, because it only takes the first one, or even none (when the first spawnarg is named f.i. "target0").

 

Here is how to correctly loop through all target spawnargs (or others if you need)

 

  string lastMatch = "";
  string key = "";
  string prefix = "target";  // or something else

while ((key = ent.getNextKey(prefix, lastMatch)) != "")
{
	entity target = sys.getEntity(ent.getKey(key));
	if (target != $null_entity)
	{
		// do something here
	}
	lastMatch = key;
}

 

Edit: GetTarget(n) is useful if you query first how many targets you have, but it is specifically for the "target" spawnarg. The method above works for every spawnarg where there can be multiple. It is a bit more slower than directly accessing getTarget(), I guess, but the difference likely won't make any difference in game.

[Obsttorte]

My first wiki article: http://wiki.thedarkmod.com/index.php?title=Multistate_elevator

 

It describes the elevator as in my first post here. Any criticism is appreciated .

[grayman]

Excuse my ignorance, but what is the advantage of this type of elevator design over what we've been using? Atm all I need to do is drop in the 3-story elevator prefab and change it to fit my map's architecture. And AI already know how to use it.

[Obsttorte]

Excuse my ignorance

I will

 

The 'advantage' was in reference to the method described in the wiki. The setup is much easier then the one described there. Of course you can use the prefab. I'm not sure how important the AI support is as it seems to me that this wasn't implemented in any FM so far.

 

However, the above described setup also works for other moving things. I used it for something else in my contest FM, but don't want to spoiler it here. In the end it's just another way of doing it.

 

EDIT: I may add that i didn't know about the prefab. Of course it is always easier to use such an existing prefab. But if you have to completely do it for yourself, I think my way is the easier one.

Edited December 27, 2012 by Obsttorte

[grayman]

I'm not sure how important the AI support is as it seems to me that this wasn't implemented in any FM so far.

 

Though code existed for AI to use elevators, they preferred to use stairs, which is why we haven't seen much of this behavior used in FMs.

 

In 1.08, I cleaned up and enhanced the elevator code (#3029 and #3005) and--while some dmap issues beyond my control remain--AI are much smarter now and more likely to use them. Existing FMs (Outpost and Siege Shop come to mind) now show some elevator use by AI in 1.08.

[PranQster]

An AI (cook) used the 3-floor elevator in Siegeshop well before 1.08. I forget if his path brought him up to the third floor in the original siegeshop release. I know the second release had him visiting the guards on the upper floor as well as the second floor office and the stove on the ground floor.

Visportals placed in the elevator shaft affected the AI's ability to use the elevator, if I remember correctly.

[Springheel]

AI used to use elevators only if there wasn't another way to their destination. Now they'll generally use them if they're the fastest way. I've had builder guards come down the elevator in Outpost to check out a disturbance in the kitchen.

[Obsttorte]

I just took another look at the wiki article and realized that there were two different ways described on how to set up an elevator. I mixed them up and thought that in addition to what is described in the first part the bunch of scripts in the second part is needed. My mistake

 

Comparing the first method described there with what I've done I would say that both methods are quiet similar. There are some more spawnargs that needed to be set there, therefore a little script is needed for my approach. I didn't tested the AI functionality jet, so in this perspective the 'old' approach may be the better one. I guess the entities used there somehow have to tell the AI what they are there for. So if you want to implement an elevator that is not used by AI or make something similar that is not an elevator, it is possible that my approach save some resources at least.

 

In the end this little excurse may have inspired some taffers to get more in touch with some scripting. At least this would be worth it.

[Obsttorte]

I thought I could collect some links to some posts I've made. I'll try to setup some wiki articles in the future.

 

Making a map where the AI is friendly to you unless you do something forbidden or go to an forbidden area:

http://forums.thedarkmod.com/topic/12833-sir-taffsalots-mapping-thread/page__view__findpost__p__300595

 

Spawning an entity once a certain amount of objectives have been completed (same thread later post):

http://forums.thedarkmod.com/topic/12833-sir-taffsalots-mapping-thread/page__view__findpost__p__302296

[demagogue]

Even if there are existing ways to do something, IMO it's helpful to for people to make stuff themselves and see that it works, just so they get some scripting experience and feel more confident with it. So I think it was worth it. Teach a man to fish...

[Obsttorte]

OK, I have another wiki article online.

 

Spawning an entity once a certain amount of objectives is completed:

http://wiki.thedarkmod.com/index.php?title=Objectives,_triggering

 

Any criticism or correction is appreciated.

[Obsttorte]

Added another article.

 

Player actions dependent AI-player relations (Hitman-style gameplay):

http://wiki.thedarkmod.com/index.php?title=AI_behaviour_depending_on_player_actions#Summary

 

Again, criticism is appreciated. If anyone that is not familiar with scripting and the use of triggers and targets could try to set up an example map that uses this approach and could post some feedback here, that would be of great help. (A single rom with one piece of loot and one AI is enough. The whole setup should only take ten until fifteen minutes).

[Sotha]

I find it very important to have good wiki articles that tell stuff like these. They help new mappers a lot.

 

Some problems is saw in a quick read-through:

 

* Some strange language: "beeing steeling."

* "Spawning" is different thing than just showing/hiding entities. Spawning requires use if sys.spawn IMHO.

 

[grayman]

Spawning an entity once a certain amount of objectives is completed:

 

Thanks for the articles. Both have spelling/grammar problems. Do you want to take a crack at correcting them yourself, or are you okay with me correcting them for you?

 

"Spawning" is not equivalent to "hide/show". An object doesn't exist until it spawns, whereas an object that exists can have its visibility toggled using hide/show.

[Obsttorte]

Of course you can correct the articles. I guess that when I do it I will just replace one mistake with an other.

 

For the "spawning" thing. I know the difference. The problem is that I'm not sure if "showing an entity once a certain amount of objectives is completed" is understandable for everyone, as in this setup the object does not appear before that. But maybe one of you knows a better word.

[grayman]

Of course you can correct the articles.

 

Done.

[Obsttorte]

Thanks a lot, Sir.

[Obsttorte]

I just experienced some very strange lightening behaviour on the map I'm currently working on.

 

To make it short, if I open a door several torchlights start casting through worldspawn brushes, although they all cast shadows and are in the level just below me, which is seperated from the room I am in via several visportals, so they just shine trough the floor.

 

Indeed the area were the torches are in is not even rendered when opening the door, as all the visportals leading to that area are closed. I reduced the light_radius on them what decreases the effect, but still it can be seen and it looks really weird.

 

Any suggestions what could cause this behavior? Thanks in advice.