Jump to content
The Dark Mod Forums

Apples and Peaches: Obsttorte's Mapping and Scripting Thread


Obsttorte

Recommended Posts

Well, currently I'm using bottle_pickup IIRC. :smile: Don't know if it makes much of a difference. But yeah, I remember the door anim. If you can tell me it's name I could try it.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

This sounds very cool.

 

What is the range for torch pickup?

 

AI is alerted. Does he go to the storeroom to pickup a torch, or should the torch be in the same room the AI is in? I mean, in order to have a solid gameplay effect, there should be moveable torches lying around here and there? Otherwise the use -at first glance- seems a bit marginal.

 

Could this be generalised for any item pickup, use and drop? Mapper could easily use these scripts to set up custom behavior like:

*Patrol, walk to kitchen, take a sip from a bottle, eat an apple, put the food and drink back, continue patrol. If bottle contents or the apple was poisoned by the player, die.

*If AI is wounded and notices a health potion, they would drink that and be restored to full health.

*Player sneaks in a kitchen and poisons food. Servant takes food to the lord. Lord eats the food and dies.

*A rival thief has a flashbomb on his belt (binded onto the AI). If the AI sees the player, the takes the flashbomb and throws it at the player.

 

That sort of thing?

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

What is the range for torch pickup?

 

AI is alerted. Does he go to the storeroom to pickup a torch, or should the torch be in the same room the AI is in?

The range is defined by the stim range. In this beta version it is 256 doom units. I will make it adjustable later on. However, the code does not test whether or not both ai and the torch are in the same room.

I plan to

  • add a player-ai-torch distance check, so that the ai can evaluate if it makes sense to grab the torch
  • could add a location check, thus meaning if the mapper has set up the location system (zones), the code could check if ai and torch are in the same location. If the mapper makes a location for every single room, this would lead to the desired effect

I mean, in order to have a solid gameplay effect, there should be moveable torches lying around here and there?

This script is not for moveable torches lying around, it's for wall torches. The code adds the torch to the ai's hand and than replaces the wall torch by a hanger model.

Could this be generalised for any item pickup, use and drop?

This is similar, but nat what the code was designed for. Setting up the first behaviour (item pickup) is much more easier.

Patrol, walk to kitchen, take a sip from a bottle, eat an apple, put the food and drink back, continue patrol.

This can be done right now using path_interact and the specific anims together with path_anim. Although this could be bundled in a scriptobject, too, I'm not sure it is really necessary.

If AI is wounded and notices a health potion, they would drink that and be restored to full health.

Similar, can be done with stim/response.

Player sneaks in a kitchen and poisons food. Servant takes food to the lord. Lord eats the food and dies.

This is quiet special, but can be scripted easely I guess.

A rival thief has a flashbomb on his belt (binded onto the AI). If the AI sees the player, the takes the flashbomb and throws it at the player.

Except the animation (I would use the rock-throwing one here) this shouldn't be too hard. I'll test it. I guess the basic problem would be, that it is most certain that the ai blinds itself. I guess this can be avoided by ignoreStim(), but I have to test it.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Alright. I was able to write a scriptobject that let's ai throw flashbombs. But I encountered a little problem. I'm not able to deactivate the flash response on the AI. ResponseEnable(24,0) didn't worked. This means the ai is always blinding itself, too. Don't know how to fix this.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Tres Kool!!

Thanks!

Überc00l!

Thanks again! :smile:

BTW: what software did you use to capture the video?

fraps to record it and super to scale it down.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Very cool! Does need a good animation though.

 

Does this require use of specific torch entities?

Link to comment
Share on other sites

Does this require use of specific torch entities?

Nope. Actually you could even use it on a goldfish :smile: The code basically does the following

  • if alerted guard is near, tell him to come to me
  • if guard arrives at my position, give the guard a torch
  • replace me with the hanger model

The code would need extension so that the prop given to the ai equals the torch beeing replaced. Currently it uses prop_torch_gothic_on, as I only use those gothic wall torches when mapping. There is also prop_torch_on, what is the torch type used by torchwielding guards in most mission and looks like the wall torch (without the gothic). You could use it on other entities, too, as said, but that may look weird.

 

In addition it could be used with lanterns, basically everything that we have a prop for, so we can attach it to ai with it using the proper animation though.

 

Does need a good animation though.

I had the bottle_pickup animation, but turned it off as it didn't worked properly with it. Need to investigate what went wrong (thus meaning what I did wrong :smile:).

 

I'm happy you like it.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Thts very impressive, one question though, if the player douses the torch the ai is holding can they relight it..?

I've updated the scriptobject for the fog system. The usage is the same as described above, but with some little changes.

Good man, we have needed the ability to have localized/customizable fog in TDM since the beginning.

Link to comment
Share on other sites

Thts very impressive, one question though, if the player douses the torch the ai is holding can they relight it..?

 

An AI will toss a doused torch. However, if that can be overridden, it's possible via scripting to make the AI walk to a flame and hold the torch out to it, the same as he does when relighting a doused light. The fire stim on the flame will relight the torch.

 

For gameplay reasons, we decided not to allow that, though.

Link to comment
Share on other sites

I'm currently working on updating the hitman_style script. For remembrance, it was the script allowing neutral ai to become hostile to the player if they encounter him by some illegal behaviour, like stealing, carrying a weapon etc.

 

If everything works as suppossed to be, I can upload it this evening or tomorrow.

 

The major advantage will be it's usage. When it's complete you only need to do three things to get it running:

  1. Create a info_location entity with a scriptobject on it
  2. Add a scriptobject to all ai who shall behave as described above
  3. Use the zone system and mark all zones where the player isn't allowed to be as hostile via a spawnarg.

So minimum work and much more error-prone then my first attempts. :smile:

 

Thts very impressive, one question though, if the player douses the torch the ai is holding can they relight it..?

Thanks. As grayman already said this could be added. But I think that in that case it would make more sense if the ai becomes immedialety aware of the players position if he shoots a water arrow at him.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Another update on the fog system. It's a minor change, but the results should look better.

 

EDIT:

 

There was a little typo in the script, sorry. Here is the corrected (and hopefully last) version.

 

tdm_fog.script.txt

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I'm currently working on updating the hitman_style script. For remembrance, it was the script allowing neutral ai to become hostile to the player if they encounter him by some illegal behaviour, like stealing, carrying a weapon etc.

 

If everything works as suppossed to be, I can upload it this evening or tomorrow.

 

The major advantage will be it's usage. When it's complete you only need to do three things to get it running:

  1. Create a info_location entity with a scriptobject on it
  2. Add a scriptobject to all ai who shall behave as described above
  3. Use the zone system and mark all zones where the player isn't allowed to be as hostile via a spawnarg.

So minimum work and much more error-prone then my first attempts. :smile:

It's done. As said above, you do not need to do much to set it up. I'm going to add some custimization possibilities, so mappers can adjust the behaviour using spawnargs, and will than upload an example map as well as the script needed.

 

Basically, the script identifies the following behaviours:

  • stealing
  • thrawing a weapon
  • carrying a body or other objects
  • going to a place were you aren't supposed to be
  • using tools like flashbombs
  • picking locks
  • being ducked (crouching)

what may still could be added is

  • handling doors to not allowed areas (DONE!)
  • climbing around (DONE!)
  • beeing the only one next to an open door that should be closed or next to a missing item (abandoned)

what does not belong to this topic but would be nice to have

  • ai noticing the dissapearence of other guards (after a while, of course) (I'll keep this for later :smile:)

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

HITMANSTYLE III

 

Hi everyone. I'm very happy to present my updated and improved version of the hitman-style script.

 

Everything you need is included in this zip file: hitman.zip.txt

 

How to set it up

  1. Create an info_locationsettings entity and add the spawnarg "scriptobject" "observer" on it
     
  2. On every neutral or friendly ai, which you want to become hostile to the player when they see him doing something illegal, set the spawnarg "scriptobject" "ai_observer"
     
  3. Use the locations system in your mission and set the spawnarg "hostile" "1" on every info_location entity, which belongs to an area where the player is not allowed to be. This areas I call "hostile areas".

That's it :smile:

 

What the script does

 

Neutral/friendly ai will turn to enemies if they see the player

  • stealing
  • beeing in hostile areas
  • using tools
  • drawing weapons
  • climbing (this includes ladders)
  • crouching
  • carrying bodies or objects around (like crates)
  • opening doors that should be closed or that leads to hostile areas

Configuration

 

There are a couple of spawnargs to configure the behaviour of the script.

 

(I) Everytime the player picks something up, this will counted as stealing. This also refers to books, apples and so one. In addition, all objects that dissapears upon frob (for example due to a script) will count as stealing. If you don't want this behaviour for a specific object, for example for a book the player needs storywise, just set the spawnarg "allowFrob" "1" on those entities. The same counts for items, that can be carried around like crates.

 

(II) You may don't want to disallow all of the above mentioned things. That's why you can disable them via spawnargs on the info_locationsettings entity using the observer script. All of them default to 0. Set them to 1 if you want to allow the behaviour.

  • allowWeapon: player can draw weapons
  • allowTools: player can use tools such as flashbombs or mines
  • allowDoors: player can open doors leadng to hostile areas (but not the "should be closed" ones)
  • allowCrouch: player is allowed to crouch
  • allowClimb: player is allowed to climb and to use ladders

(III) By default, the player will alert ai who can see him for two seconds after the last suspicious deed. You can change this period, by setting it via "awarenessTime" (in seconds). Note that you can set spawnargs difficulty-dependent, so you can set higher values for higher difficulty levels.

 

Additional notes

  • neutral ai near already "hostilified" ai, which can see the player, will turn hostile, too
  • by default, stim number 1000 is used. If you've already custom stims in your mission, you can change the number by adding "observer_stim" "X" on worldspawn, where X is the desired number
  • I've tried to check for all possible bugs in the code. Anyways, if you find one or notice strange behaviour, please report hear. Thanks.

Credits

 

:laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh:

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Unfortunately there is no texture blending in idtech4. So I tested something to gain a similar effect. Could need some feedback, though.

 

post-11230-0-55242900-1368139900_thumb.jpg

 

Creating this took roughly 10 seconds, so it's really just a short test, nothing optimal.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Well it looks like you've covered most of the bases for the security levels already with your "hitman" script, so I think we ought to stick with it and build from it, rather than bother reinventing it. Actually the title of your system might be changed to "Security Level", since that's the internal name for it we've been using from the start. Anyway, I'm going to use SL in what I say because that's how I was working with it. There are a few things a SL feature has that you might think about rigging your script system to. Or at least for discussion. These ideas are things the team talked about in the past or that I thought in my own calculations. Let's talk how feasible any is to rig in your system or what's good for gameplay.

 

 

 

- The biggest immediate difference is the Security Level feature had 4 security levels with batches of crimes they'd go on alert for, like a spawnarg "SecurityLevel", with 0-3, and -1 for a custom level.

o Level "3" is normal, high security (the default option for all info_locations. AI always go on alert on sight).

o Level "2", normal security, is street in good neighborhood or like in a public museum, so the AI don't go on alert, but if they see the smallest infraction they will go on alert (pull out a weapon, lock picking -- with lockpicking it's probably ok to have them out, but to use them starts the alert.)

o Level "1", low security, is street in a bad neighborhood. The AI doesn't go on alert except for serious crimes (the player kills someone & steals). If they see a body or evidence of a crime, they do not go on alert since someone else in the neighborhood might have done it.

o Level "0" is no security. This is like a criminal den largely agnostic to the player. The AI will never go on alert unless directly attacked. Even if other people are attacked & killed, that's their problem. This AI is staying out of it. (Well we can debate if an ally is attacked.)

 

This way, the player can pick from varying packages of crimes they want to trigger the switch just with a number.

 

o Level "-1" is custom, which means the mapper selects the list of crimes in a spawnarg that cause a switch to whatever list they want. In one past example, a mapper wanted an AI that only went on alert if they saw the player lockpicking, but not for other crimes. The solution I came up for this is one spawnarg that by default has all the crimes that cause a switch, listed out separated by commas, then the mapper can selectively delete the ones he doesn't want involved, so it's easy for the mapper to pick and choose.

 

- Is it sensitive to the current location of the player or AI? It should be the player, if it's not already (so the AI can see the player through a window in another location doing something illegal=alert; if sees player in ok location=no alert).

- It could be improved with a memory system with two options. In one option ("SL_memory" "0"), if the AI later sees the player in a non-security-level'd area, he does not go on alert then. In the other option ("SL_memory" "1"), the AI will be an enemy of the player & go on alert on sight from that point on for the rest of the game. The default should maybe be "1" I think, but sometimes you have AI that are ok with the player anywhere else (some thugs or whatever), as long as it's not on their turf.

- Do you have a spawnarg that opts some AI in and some AI out by spawnarg on the AI? That is, AI opted "in" will obey the security-level for that location, AI opted "out" will not obey the security-level for that zone and behave normally (always attack).

- It'd be good if you had a parallel system which is a security-level not on the location, but on the AI itself. That is, you have a "security_level" spawnarg on the the AI itself, works about the same way as for the info_locations but on the AI, and it will stay friendly to the player on sight, but go on alert if they see them commit a crime in any location. (Then maybe you'd want a way to decide which system overrides, like a spawnarg to decide if the AI personal SL or the location SL trumps).

- Does your system know NOT to make AI that are meant to be on a friendly team switch? This is the big question I had since you didn't go through the sourcecode but a script. How do you distinguish AI meant to switch from friendly to enemy and AI not meant to switch? In the source code system, the "team" never changes. On a friendly team from the start will always stay on a friendly team. An enemy from the start will stay an enemy team. What changes is a completely new system of "security" states. Enemy team members with a low security have their alert averted directly at the alert code unless that's excepted by seeing a crime. Does your system just switch "team" membership? It might be worth looking into making a parallel system so team membership isn't switched around. Unless we can make your system work around the issues, like I mentioned above, make sure AI meant to stay friendly always stay friendly.

 

I have some other notes I'll try to track down and write down. This is a good chunk for now.

 

- Edit: I'll add things in an edit below here so you know what's new.

- With the "no criminal frobbing" item, it's cumbersome (a pain) for a mapper to tag every single non-criminal pick-upable item in the entire gameworld ok-to-frob. IMO you need to separate the "no steal" or crime into two parts, one ("stealing") that triggers alert when any category of object that's loot is frobbed, and any other category of object is fine to frob. You can get the category of object by spawnarg. The second ("criminalFrob") is to trigger an alert on any object only if it *has* a spawnarg for "criminal_to_frob" "1". That way you are opting objects in, not out. It's much much better that way IMO, to opt objects in by spawnarg than out.

 

 

 

Edit2:

I'll put it all in a spoiler so it doesn't distract from the topic of your FM.

Do you want this discussion here in this thread, or would you like to create a new thread to discuss it in more detail?

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...