Apples and Peaches: Obsttorte's Mapping and Scripting Thread

[Obsttorte]

I've just saw that the svn is availale on the darkmod page.

 

EDIT: Found the instructions on the wiki. I barely remember that I've tried this. Will see if I can build it under linux as I haven't VS 2010

[grayman]

As you can see in the beginning it checks if the point was already reached. I guess this is the best place to insert the code

 

No.

 

These states and tasks are responsible for fleeing:

 

FleeState

FleeDoneState

FleeTask

 

You'll want to familiarize yourself with these and find what they do when they complete.

 

If the Flee event is going go be extended to handle seeking out an alarm button, it needs to be handled at the start of FleeDoneState, rather than sticking it inside MoveToPosition(), which is called every frame for every AI as pathfinding tells them where to go. FleeDoneState can then let them push the button and then continue with the normal business of FleeDoneState, which is to look around for friends that might be able to help.

 

======================

 

Edit: After giving this a few moments of thought, it might be best to NOT make pushing an alarm button part of the Fleeing state.

 

If a mapper ever wants his AI to "raise the alarm" because they saw something bad, he'll want those AI to make that happen regardless of whether they're fleeing or not.

 

We have AI states for relighting lights and examining ropes, each of which causes an AI to go to a specific place to do a specific thing. Pushing an alarm button sounds like the same set of actions, so it should be handled the same way.

 

If pushing an alarm button is going to come out of the scripts, and be added to the DLL code as core behavior, it ought to be done with code that allows for finding the nearest alarm button, running to it, handling elevators and doors along the way, hitting the button, then running back to where the offense was observed. Create OperateAlarmState, and let him do the work.

 

With that in place, you can now go to FleeDoneState and have your AI enter the new OperateAlarmState. If the mapper placed a flee point right next to an alarm button, then OperateAlarmState takes care of all the details. OperateAlarmState could choose not to send the AI back to where the offense was observed, using the same conditions that got the AI fleeing in the first place: unarmed, ill health, or civilian.

 

OperateAlarmState also should handle the steps necessary for turning off the alarm later if the mapper wants to do so. There's nothing to say that the AI that turns the alarm off needs to be the one that turned it on.

 

My two cents.

[Obsttorte]

That makes sense. I barely remember seeing the states somewhere in the code, will need to look at it. Found the files.

 

Another thing. I've tried to download the svn using RapidSVN. It asks me for an authorization. Am I doing something wrong or is this normal?

[grayman]

That makes sense.

 

Better read my edit. My suggestion changed.

 

Another thing. I've tried to download the svn using RapidSVN. It asks me for an authorization. Am I doing something wrong or is this normal?

 

Yes, you need permission to deal with the SVN repository. I don't know how to grant it, though. greebo used to do that, and hopefully someone reading this thread knows what you need to do.

[Obsttorte]

Well, that gives me some time to think about the problem.

 

Just for clearence:

• operateAlarmState doesn't exist, it would be a new state to handle the alarm thingy
  
• finding a alarm button (if any) should be independent from where the fleepoints are
  
• the ai needs to be aware of whether the alarm is on or not, so he can turn it off
  
• there needs to be some condition that decides whether or not the alarm can be turned off
  
• these conditions refer both to circumstances (time passed etc.) and maybe the ai (what kind of ai's should be allowed to turn off the alarm? only guards (weapon carriers), people of high rank (->spawnarg "rank") ...
  
• The mapper should be able to control this behaviour (script functions to let an ai run an alarm or to disable it?)
  
• did I overseen something?
  

[Springheel]

Didn't I set you up with an account for SVN when I made you a team-member? I can't remember now.

[Tels]

The code SVn repository is read-only for guests, which means you can download the code freely, but if you want to commit, you need an account. (I can't set you up, btw, haven't got the permissions)

[Obsttorte]

@Springheel: You've told me, but you never gave me the login informations.

@Tels: It's mainly for testing purposes I guess. What goes into the code and what not may be decided by people who've spent more time with it.

[grayman]

• operateAlarmState doesn't exist, it would be a new state to handle the alarm thingy
  
• finding a alarm button (if any) should be independent from where the fleepoints are
  
• the ai needs to be aware of whether the alarm is on or not, so he can turn it off
  
• there needs to be some condition that decides whether or not the alarm can be turned off
  
• these conditions refer both to circumstances (time passed etc.) and maybe the ai (what kind of ai's should be allowed to turn off the alarm? only guards (weapon carriers), people of high rank (->spawnarg "rank") ...
  
• The mapper should be able to control this behaviour (script functions to let an ai run an alarm or to disable it?)
  
• did I overseen something?
  

 

OperateAlarmState doesn't exist. I suggest copying SwitchOnLightState.{cpp,h} as OperateAlarmState.{cpp,h} and add them to the project.

 

SwitchOnLightState already has states for finding and pushing buttons. Start at the Init() method and follow the path for relighting electric lights and remove anything having to do with relighting flames. At spawn time, each button registers itself with any lights it controls, and when it's time to pick a button to push, the light in question hands them over to the AI to decide which one's closest. You could do something similar for alarm buttons.

 

Remove any code that you don't need. Change the state names to what makes sense. Etc. etc.

 

If you can figure out how to set up the files, get them into the project, and start going through the code on your own, great. If you need me to get things set up for you so you can start making the changes, I'll be happy to do that.

 

As for the other bullets, they look reasonable. They all have to do with decisions to be made before entering the new state.

[Obsttorte]

Thanks.

 

As for the other bullets, they look reasonable. They all have to do with decisions to be made before entering the new state.

Yep. So I go creating the new state and we care about that later on. Springheel is gonna giving me the read access to the svn and then I'll start. I'll pm you if I get stuck (what I don't hope).

[Obsttorte]

BLOODY

 

I've just saw that I've had an error in my trigger_look script I've uploaded a while ago. It was used for triggering event when looking at something.

 

However. Here's the corrected version.

 

trigger_look.script.txt

[Obsttorte]

Last weekend I've created a throwable torch. It's basically a extinguished torch that can be picked up by the player and goes into his inventory. If he uses it it get's thrown (now burning). All in all it works similar to the T2 flares. The main difference is, that it is able to set things in fire (like explosive barrels ).

 

I've also just created a scriptobject to be used on ai. It has something to do with torches. You can see the result in my Old Habits revamp.

[Bikerdude]

I've also just created a scriptobject to be used on ai. It has something to do with torches. You can see the result in my Old Habits revamp.

Will we get a prefab with required scripts before that map is released..?

[Obsttorte]

It's a speed rebuild, so I hope it will be ready this weekend or on beginning of the next week, depending on how long beta-testing takes.

 

The script object is a file that just needs to be copied into the scripts folder and be included via the tdm_custom_scripts.script file in this folder. Then you just have to tell the ai to use it (spawnarg "scriptobject") and add a custom stim to the specific torches. It's pretty easy.

 

Anyways, I need to polish the script a bit.

[Obsttorte]

I thought I continue posting here instead of spamming up the "So, what you are ... " thread.

 

Geometry is done so far, only some details here and there, not much. A couple of visportals are missing. I start adding models and lightsources, now. I don't have a single door in the mission by now as I want to look if everything performs good when all possible VP's are open. Currently everything runs smooth around 60+ FPS

 

Here in germany we have off on wednesday, so I hope I can finish the map and start the beta this day. Btw.: Any volunteers?

[Obsttorte]

I have had a couple of ideas for my Old Habits rebuild, which I really wanna add, so it will take a few more days to finish the mission.

 

As I've already mentioned I created two new ai scriptobject, which differ there behaviour a bit. One of them is crucial for the tension in my mission, so I really don't want to spoiler it now, but the other one I think I can present, as it may appear unfair anyways if I do not inform the players about that behaviour.

 

So, what is all the fuzz about!?

 

Imagine you are a guard. You do your patroling stuff, bored as always, and suddenly you hear a noise in the dark corners of the room you are currently in. You are sure that someone is there, but it is really dark and you can't see anything in said corner. Good luck, there is a torch nearby. So, what are you going to do?

1. You stumble into the darkness, hoping that you don't get blackjacked from beyond or end up with a broadhead in your face?
   
2. You take the torch so you can enlight the dark corner of the room to reveal whoever is hiding there?
   

Your choice, my script

 

I will polish it up and upload and explain its usage tomorrow. Cheriou (or however it is written)

[grayman]

How does the guard know where it's dark and where it's light?

[Obsttorte]

I guess he don't know . The above story was just a rough explanation of what the script is doing.

[Obsttorte]

OK. So here is the ambient fog scriptobject.

 

IMPORTANT NOTE: I've uploaded a corrected version below

 

You have to use the zone system to make it work.

 

Create a copy of your info_locations_settings entity or simple create a new one, and set the following spawnargs on it.

• "scriptobject" "fog_system"
  
• "fog_fade_time": the time in seconds it should take to blend into the new fog
  
• "update_period": (optional), how often the system checks for location changes
  

On every info_location entity place the following spawnargs:

• "fog_color": a vector containing the RGB values the fog should use, each of them ranging from 0-1
  
• "fog_density": the density of the fog, the higher the value, the more dense the fog. A value of 0.1 means it is completely opaque in 1000 doom units distance, a value of 0.01 means in 10000 doom units and so one
  

You don't have to create a fog, this is done by the script. If you decide later on to remove the fog from your mission, you just have to erase the info_location_settings entity which is using this scriptobject

[grayman]

This is nice work.

 

It appears to solve the problem of crossing from a fogged area to a non-fogged area and back again, w/o encountering the nasty fog borders.

 

Being able to change fog color based on location is also very nice. We can have cold fog outside and warm fog inside.

 

If one doesn't want the fog light to have ambient_world's volume, one could create a dummy light with the appropriate volume and use that in place of ambient_world.

 

Good work.

[grayman]

Is this math correct?

 

ic_x = nc_x*t/m_fadeTime+oc_x*(1+t/m_fadeTime);
ic_y = nc_y*t/m_fadeTime+oc_y*(1+t/m_fadeTime);
ic_z = nc_z*t/m_fadeTime+oc_z*(1+t/m_fadeTime);

 

When t = 0, we get oc, which is good.

 

When t = m_fadeTime, we get nc + 2*oc, which is bad.

 

I think you want minuses instead of pluses on the oc expressions.

 

Also, since there's no guarantee that m_fadeTime is a multiple of m_updatePeriod, it's possible that you'll never see t = m_fadeTime, so when it falls out of that loop, it should probably do a final setting of setLightParms() with nc and nd so the fog arrives exactly at the desired settings.

 

And one last thing and I'll go away.

 

Since "update_period" is optional, if the mapper doesn't set it, what does that do to your loop?

[Obsttorte]

1.) Yep, it should be minus, little typo.

ic_x = nc_x*t/m_fadeTime+oc_x*(1-t/m_fadeTime);
ic_y = nc_y*t/m_fadeTime+oc_y*(1-t/m_fadeTime);
ic_z = nc_z*t/m_fadeTime+oc_z*(1-t/m_fadeTime);

2.) I'm not sure this is so important, but I can do that.

3.) update_period has a default value on the info_location_settings entity (0.1 or so).

 

EDIT: Here's the corrected version

 

 

tdm_fog.script.txt

[grayman]

2. is important. no point in finishing sloppy.

 

3. okay. default is 0.5.

[Obsttorte]

2.) Than I didn't said a word

(I've fixed that, too).

[Lux]

Thanks for this! I'm going to use it when I get to that point.