Jump to content
The Dark Mod Forums

Security Level System


Obsttorte

Recommended Posts

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?

  • 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

Does your system know NOT to make AI that are meant to be on a friendly team switch?

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"

The system sets the AI to enemies individually using the script function setEntityRelation().

- 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).

The location the player is in decides how the ai reacts.

- 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.)

Level 3 is covered by setting "hostile" "1" on the specific info_location entities.

Level 2 is the behaviour in all other locations. This could be distinguished a bit more, as you said.

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.

I don't see any point here. The ai does only become an enemy if they see the player doing something illegal. Once they are hostile, the stay hostile.

 

The only senseful application where differentiating this would make sense, if to let it be decideable depending on the deed done. But that gets cumbersome complicated.

 

What may be more useful is some sort of warning state for specific crimes.

 

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.

Loot is already differentiated from all other objects. For the other cases I could stick to your suggestion.

 

I will continue working on this today. I guess most of the things you've mentioned could be scripted. :smile:

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

Some more notes about picking up items:

 

I just discovered that picking up eatables does not use the same immobilization as crates or bodies for example. So they can be handled seperately.

 

All playertools except potions use the same inv_category. I guess all readables do either.

 

Crates and bodies use the same Immo, but they can be differentiated by there type.

 

Mantling/Climbing and using ladders uses the same Immo, so I can't differentiate them. This means if the player should be allowed to use ladders, he must automatically be allowed to climb over walls and vice versa. I'll investigate this. (SOLVED)

 

Regarding the picking, I would use categories as said:

  • tools like flashbomb, lantern etc.
  • eatables
  • readables
  • stuff like crates, barrels etc.
  • bodies

What I wanted to add: The player never gets suspicious when he has his lockpicks highlighted, only when he uses them. As the player may not remember where is inventory pointer stands, and the control over the inventory is a bit limited, I'm not going to add this behaviour to avoid frustration.

 

Regarding location/ai properties: I think that the preferences set on ai should acount higher then the location settings of the location the ai is currently in. Anyways, the ai is currently only informed that the player is commiting a crime, not what kind of crime. The latter would be much more complicated implementation wise, and the choice of a location based system was to avoidsetting the behaviour on every single ai.

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

Thanks for starting this and talking about it. :)

 

I don't see any point here. The ai does only become an enemy if they see the player doing something illegal. Once they are hostile, the stay hostile.

 

The only senseful application where differentiating this would make sense, if to let it be decideable depending on the deed done. But that gets cumbersome complicated.

 

What may be more useful is some sort of warning state for specific crimes.

 

The point of memory is, for example, an AI (like another criminal thug) that is not inherently an enemy of the player, but they will fight the player if he commits a crime where he is responsible (like try to lockpick into their own compound, or the player is in prison and tries to lockpick the door out)... Once the player stops the offending action & leaves, and the thug goes out of alert, the thug does not automatically go back on alert on sight because he is not responsible for the player anymore, but he is reset.

 

I think it's just a matter of the system reverting the hostile-switch when their alert goes back to idle if "memory" "0", which resets the AI, which doesn't sound too complicated. (And if "memory" "1", the default, then you don't do anything; just let the AI stay hostile as it is now.)

 

Regarding location/ai properties: I think that the preferences set on ai should acount higher then the location settings of the location the ai is currently in.

 

Yes this should always be the default. But there might be a spawnarg that allows the mapper to let the location have priority for special cases (like put the name of the AI in a spawnarg on the info_location entity?) It's just good to allow the mapper ways to customize.

 

 

Anyways, the ai is currently only informed that the player is commiting a crime, not what kind of crime. The latter would be much more complicated implementation wise, and the choice of a location based system was to avoidsetting the behaviour on every single ai.

 

Yes, the location system is very useful for mappers in that way. But once you implemented it, it would be good if the mapper also had the option to set it on a single AI (and not to the others), just for that case. I don't recommend an AI-spawnarg version as a replacement, but as a 2nd system.

 

Regarding "is committing a crime, not what kind", that's fine, but it's not what's important for AI vs location. The purpose of the system is setting what crimes they see (I mean all crimes) that an AI is responsible for. In a location-spawnarg system, this is good for when all AI are responsible for all crimes in one location (their house) but not another (out in the street, or the neighbor's house). In an AI-spawnarg system, this is a case where you want some AI to be able to go on alert in all crimes in all locations like a police guard, and very easily, just put the spawnarg on the AI.

 

In some cases a location-spawnarg is easier on the mapper (he doesn't need to put it on all AI, just one location). Some cases an AI-spawnarg is easier on the mapper (he doesn't need to put it on all locations, just one AI). I'm not saying choose one. I'm saying it's convenient to have both.

 

Edit: If on the "is committing a crime, not what kind", you mean where I was talking about custom settings, so the mapper can set what crimes will trigger their alert switch. I thought this would be a matter of registering whether the system recognizes a category as a crime at all. Like seeing the player with a weapon drawn. In a high security location (in the house), that's a crime. In a low security location (out in the street) that's not a crime (but killing someone could be). I don't think it would be that complicated to have a check whether that stim is counted as a crime in the given location (and so on with the other categories). It'd be work worth doing; maybe in a future version. We have time to improve the system better over time.

 

I'm trying to think of long-term goals for the system to be as customizable for mappers as we can, then they can achieve many different types of scenarios.

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

The point of memory is, for example, an AI (like another criminal thug) that is not inherently an enemy of the player, but they will fight the player if he commits a crime where he is responsible (like try to lockpick into their own compound, or the player is in prison and tries to lockpick the door out)... Once the player stops the offending action & leaves, and the thug goes out of alert, the thug does not automatically go back on alert on sight because he is not responsible for the player anymore, but he is reset.

 

I think it's just a matter of the system reverting the hostile-switch when their alert goes back to idle if "memory" "0", which resets the AI, which doesn't sound too complicated. (And if "memory" "1", the default, then you don't do anything; just let the AI stay hostile as it is now.)

OK. Than I've misunderstood that. Yeah, It would be an option. I will add that.

Regarding "is committing a crime, not what kind", that's fine, but it's not what's important for AI vs location. The purpose of the system is setting what crimes they see (I mean all crimes) that an AI is responsible for. In a location-spawnarg system, this is good for when all AI are responsible for all crimes in one location (their house) but not another (out in the street, or the neighbor's house). In an AI-spawnarg system, this is a case where you want some AI to be able to go on alert in all crimes in all locations like a police guard, and very easily, just put the spawnarg on the AI.

I've already thought about that, but would suggest another approach. The mapper could set the "team" spawnarg on the locations to mark to which team they belong to. If an ai then for example sees the player entering an are where he isn't supposed to be, the ai can check to which team the location belongs and would only become hostile if it belongs to a team friendly to him. The same mechanic could count for carrying bodies (depending on the level of the actual zone, too) or for lockpicking.

I'm trying to think of long-term goals for the system to be as customizable for mappers as we can, then they can achieve many different types of scenarios.

I don't want to say much against this point. But one of the most important critic about my earlier approaches was that you have to set a lot of spawnargs on a lot of entities.

 

I think it's ok to customize the behaviour via two sides:

  • the security level of a zone as proposed by you
  • the team relations

I think there should be some sort of standard, and customization shouldn't go out of hand. If the ai behaves completely different in every fm, this just get's annoying to the players.

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

There should be standard defaults so most mappers don't have to ever know about the spawnargs, they just set one spawnarg and the whole system works fine from there. The customization comes in when a mapper has a specific NPC he wants to handle a certain way, and I agree there should not be confusion for players, so it's not great for generic guards. But ideally the fiction would let the player know what to expect from all AI, so it's not idiosyncratic like you say.

 

But what I'd really say is, rather than take my word, this feature has been brought up many times in past threads... You could search for some & have a look at the different ideas mappers have for when they want AI cued to go hostile. A lot of times for fiction reasons, they want an NPC that only goes hostile for one thing, like some gameplay thing (BTW, another approach is to have a single dummy trigger possible; then the mapper can let anything they want trigger that dummy trigger. It's simple for a fiction set up, but doesn't really interfere with the standard defaults most mappers will probably use.) Anyway, reading some old threads could give you an idea of the kind of demand among mappers for what things they want to control, and we can talk about what's good to let them control & what's good to leave more standardized & simplified.

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

Let me sum up how I would do it at the current point.

 

The approach uses three security levels for zones:

  • Level 3: (High Security) Player is not allowed to be here
  • Level 2: (Good Neighboorhood, default) The player is allowed to be here but will be treated as an enemy if doing something illegal. The player is allowed to use ladders but climbing over walls etc. will be treated as suspicious.
  • Level 1: (Bad Neighboorhood) The player can do most things like drawing a weapon, climbing over walls and so on. If he is attempting to break in an area, ai only becomes hostile if the area is friendly to him (defined by setting the team spawnarg on the location, not setting it makes it friendly to all aiper default). If he is carrying a body, ai only becomes hostile if the body is a friend etc.

In addition the mapper can define a custom security level (0), where he can set what is allowed and what not. By default those areas behave like level 2 areas.

 

AI behaviour can be customized in two steps

  1. AI can be set to behave like in a certain security level area if the level of the current one is lower. So city guards for example may even react to bodies of ai, who are no friend of them. The same works vice versa, so that a maximum level can be set. A criminal may not care about what the player does, even if they are in a level 2 securty area.
  2. Individual behaviour can be furthermore configured by allowing/disallowing certain things. In addition ai can be set to always blame certain deeds on the player, if they saw him near a crime (like a dead body or so), and they can be set to become neutral to the player again, if there alert level has gone low enough again. The last two things can also be set global.

I think that should cover everything. Local settings (on the ai) overrides global settings.

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

One of the things we had planned for high security settings was that the AI would pay more attention to things they didn't normally, like ropes, moss patches, etc. Anything that indicated an intruder would be treated seriously. Sounds like your "high" security is more the default behaviour?

Link to comment
Share on other sites

@Obs, Yes, there may be different ways to accomplish AI #1, but it sounds like how you put it would do the job. Play around and think of a good implementation.

 

Keep in mind, if this becomes integrated in the mod, the default would need to be the base behavior in existing maps, that is enemy AI go on alert on sight (Level 3), so it doesn't break old maps. Unless we want to always keep it as a separate script entity and not integrated (then a level 2 default makes sense), which is an option too. The advantage of integrating is that the mapper just needs to add a spawnarg to the info_location or AI and it works from there, no other work. But anyway, you can develop it with the script object now, and we can discuss if integrating it like that is a good idea later.

 

@Spring... just a second, I have to run, I'll be back in a sec

Edit: I think it's said above. Having "Level 3" default to normal behavior makes sense if it's integrated into the whole mod, so default behavior doesn't break old maps. (But as said, that's not an issue if it stays a separate script object maybe.) Also it makes sense to have a setting for default behavior because we're sometimes talking about AI-settings sometimes overriding location-settings, and sometimes you might want, e.g., default behavior on an AI to override a lower-security location or something like that (maybe? Think through the logic of it.) But even aside from these issues, it does make sense to have a security setting even *higher* than default where evidence can add up to alerts more so than default. That might be, e.g., 4 levels, with #4 being higher than normal, #3 normal, and #2 & #1 as described above.

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

Sounds like your "high" security is more the default behaviour?

Yep. But as said it's still WIP.

 

I agree with demagogue.

  • Make Level 3 the default one
  • Add a Level 4, where AI is much more aware of any signs of intruders.

I have to check if such thinks can be changed during gametime. Regarding the script reference it is possible to change acuity during the game, but I have to check on how far this regards to other things as rope arrows. Additionaly most spawnargs are read during game, like for example shouldBeClosed on doors IIRC. So in a Level 4 area the mapper don't have to set this spawnargs, the code could add them once the player interacts with them. The same counts for missing items I guess, letting the code automatically add a missing item marker. I have to test this.

 

Don't know if I've overseen something, if so tell me.

 

Keep in mind, if this becomes integrated in the mod, the default would need to be the base behavior in existing maps, that is enemy AI go on alert on sight (Level 3), so it doesn't break old maps.

I would like to have this as default behaviour. Making Level 3 the default is on possibility that I will do as explained above. Anyways, I may note that the behaviour only counts for neutral ai, thus meaning the script is only used by them.

  • hostile ai is always hostile
  • neutral ai behaves according to the script
  • friendly ai stays friendly to you (this is open to discussion, one could say that the ai becomes neutral to the player if he steals from them for example and hostile if he continues doing crimes against them or attack them or one of there friends)

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

Anyways, I may note that the behaviour only counts for neutral ai, thus meaning the script is only used by them.
  • hostile ai is always hostile
  • neutral ai behaves according to the script
  • friendly ai stays friendly to you (this is open to discussion, one could say that the ai becomes neutral to the player if he steals from them for example and hostile if he continues doing crimes against them or attack them or one of there friends)

 

Does this mean you'd have to change the guard's team to a neutral team to use it?

I have the feeling we need to think about the relationship between team behavior (hostile, neutral, & friendly) and security level... Ideally we'd want a way to be rather open for hostile (in other locations), neutral & friendly, all of them, to switch to hostile or back in a location for all sorts of fiction scenarios. I mean I think we really need hostile AI obey the script, so that guards are, e.g., hostile in their mansion & non-hostile in the streets. Or is the plan here to have a script for both locations, inside the house & in the streets for this case?

 

My brain is very tired right now after a long day so I can't think through all the implications now. I think when we get a prototype working in maps, people will start understanding how it works and have a good idea of some good tweaks.

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

Does this mean you'd have to change the guard's team to a neutral team to use it?

I have the feeling we need to think about the relationship between team behavior (hostile, neutral, & friendly) and security level... Ideally we'd want a way to be rather open for hostile (in other locations), neutral & friendly, all of them, to switch to hostile or back in a location for all sorts of fiction scenarios. I mean I think we really need hostile AI obey the script, so that guards are, e.g., hostile in their mansion & non-hostile in the streets. Or is the plan here to have a script for both locations, inside the house & in the streets for this case?

I guess there is a basic misunderstanding of how the script works.

 

The script never changes the relations between teams. Hostile ai would attack the player independently of what he does or where he is.

 

So if you want the behaviour of a guard who gets only hostile to the player if he is entering the area he is guarding, yeah, you have to set him to neutral. At least if it is possible that both the ai and the player meet each other in a situation, where the guard would not attack the player. If the guard is in the mansion or whatever he is guarding all the times anyways, you could leave him as he is. But that is a mapper decision.

 

The basic assumption of the script is, that the ai is neutral to the player, thus meaning he ignores the player unless he is doing something forbidden. This ranges from intruding in prohibited areas over stealing to weapon or tool usage.

 

There is no need to manipulate the behaviour of an ai that is supposed to be hostile to the player anyways.

 

And regarding the "hostile in their mansion and non-hostile in the streets": The behaviour of getting hostile is not controlled by where the ai is, but by where the player is. Would it be the first case ai would become hostile after entering their mansion, even if the player is outside, and vice versa stay neutral if they are at the outside and see the player entering the mansion, both of which doesn't make any sense.

 

It would be good if you could build yourself a little example map (or I'll do that) to actually see how the ai using the current script behave depending on the players actions. This way we don't have to discuss things that already works as they are supposed to be. (Sorry if this sounds harsh, it's just a suggestion :smile:)

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 guess there is a basic misunderstanding of how the script works.

 

There is no need to manipulate the behaviour of an ai that is supposed to be hostile to the player anyways.

 

This is part of the debate about whether to use a script or sourcecode. In the source (or maybe it could be done in a script system too) we could have a parallel AI state for "responsible to become hostile" (probably some better term for that), and that's what this system would change, so you could still have a "hostile AI" type that has his "responsible to become hostile" state raised or lowered by security level, or other variations (friendly AI's responsibility to become hostile to enemy AI, etc). Sometimes it's easiest for a mapper to set locations for where hostile guards should/n't go hostile, that's what a location system is good for, and then adjust individual AI behavior with a spawnarg to ignore locations. It's just odd you have a system designed to target guards, which we think on a hostile team when they're responsible for it, but it doesn't apply to hostile AI. It might still work (do you set guards to a neutral team?), but I wanted to think about how the logic works for mappers.

 

And regarding the "hostile in their mansion and non-hostile in the streets": The behaviour of getting hostile is not controlled by where the ai is, but by where the player is.

 

Yes, this is the point. When the player is in the streets, obviously a guard for a mansion isn't responsible for that, so no hostility (or police only when they see a crime). If the player is in his house, now the guard & police are responsible so hostility. This is the most common purpose of the system, I'd think. If neutral AI can serve this purpose, maybe it does this job just fine. But we're mostly talking about guards that are responsible for location-A but not location-B, or for certain things the player does (crimes) but not others (walking around).

 

Would it be the first case ai would become hostile after entering their mansion, even if the player is outside, and vice versa stay neutral if they are at the outside and see the player entering the mansion, both of which doesn't make any sense.

 

I already said above it should be where the player is, not the AI. This isn't in question. You misunderstood what I meant. Actually I don't know where you interpreted that from what I said. My main point was about the system primarily being for guards protecting an area, which are going to be on a team natively hostile to the player; just they are not responsible for the public streets so do not become hostile in that case. When you say it's for neutral AI, it makes it sound like it's meant for civilians or criminal thugs, but not guards and police...

 

Edit: My basic point is, things can get tangled when you're dealing with team relations and hostile behavior, especially when you're changing the hostility, so one possible way to untangle that is to have two states, one for inherit type of AI (team: hostile, neutral, and friendly) and another for "when I'm responsible for going hostile (if that's my type)", which is security level (1-4), and then the two work together, so neutral are probably always neutral (because that's their inherit type; a hobo; he may not care if a crime is committed because it's not his job... Although we may want neutrals to turn too, since hobos should be afraid of certain crimes, killings, but maybe neutral to stealing), but inherently hostile AI (police, guards) are sometimes responsible to go hostile and sometimes not (police when they see a crime or not).

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

Yes, this is the point. When the player is in the streets, obviously a guard for a mansion isn't responsible for that, so no hostility (or police only when they see a crime). If the player is in his house, now the guard & police are responsible so hostility. This is the most common purpose of the system, I'd think. If neutral AI can serve this purpose, maybe it does this job just fine. But we're mostly talking about guards that are responsible for location-A but not location-B, or for certain things the player does (crimes) but not others (walking around).

As explained above, this would be handled by the script. The current script requires to set the ai to neutral via team change. In the future script, however, this won't be neccessary as the script will handle this. It will not change the team, but the personal player-ai relationship.

 

As for the location thingy, I've already stated that certain crimes (like unallowed entering) will only cause an ai to turn hostile if the specific location belongs to their team,a team that is friendly to them, or if the mapper didn't specify this.

It's just odd you have a system designed to target guards, which we think on a hostile team when they're responsible for it, but it doesn't apply to hostile AI.

With hostile AI I've meant ai that is hostile to the player anyway. This also means that they will attack the player onsight independently from whether he is commiting a crime or not. So why should those entities consume performance to observe something that hasn't any influence on their behaviour?

 

When you say it's for neutral AI, it makes it sound like it's meant for civilians or criminal thugs, but not guards and police...

When I say neutral AI I mean ai that will not threat the player as an enemy, unless he is doing something forbidden, what is exactly what the purpose of the script is.

 

I guess we are already on the same page, and just misunderstanding each other.

 

The "type" thingy you've mentioned will be available trough the script. How it works out in detail is up to the mapper. Regarding the location based crime evaluation thingy I've mentioned above I'll add a spawnarg, that allows the mapper to tell the script that ai of a specific team should go hostile, even if the targeted team (thus meaning the one the player is currently commiting a crime against) is just neutral to them. The mapper could then set this for the guard team or for builders or both, or I just put that as the default behaviour for those teams.

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 read back through, and I think the root of it is I'm thinking in terms of AI relations by team membership (which would be would setting up an info_location to apply to the whole class of guards or city watch, or at least ones you pick out), and as you said in a post above your system applies to AI individually designated, so there's no talk about classes or teams or anything...

 

Ah, now I think I understand the difference. You are doing the system almost exactly backwards from how I was thinking to code it. In my code, the system works at the "go hostile" code, to stop a naturally hostile AI going hostile when the condition (seeing a crime) isn't met. That is, the AI would want to go hostile (he's a city watch, it's his job), but then the system *stops* him (you're not responsible for this). In your system, it switches a neutral (and we're debating friendly) AI to *now* go hostile when he sees the crime. Before you're neutral; now you've seen a crime & you're hostile.

 

Uh, I'll just say for now that what I liked about how I did it is it seemed more logical IMO... You're capping a hostile AI, and seeing a crime lifts the cap, vs you have a neutral AI and seeing the crime triggers him to be hostile.

 

In practice, it might not make much difference. But we have things like the AI Relations system about setting who is naturally hostile (a city watch is always team 2 is always hostile, but this system stops him until it's lifted), and the way I was thinking about it is trying to work with this system, and you're system looks like it just puts individual AI on their own system (a city watch isn't on team 2 anymore). There's advantages to how you're doing it too... The mapper can just deal with AI individually however they want. I suspect what I was thinking may still play a role, but I'll be content to see how your system works in practice to see if it ever makes much difference practically.

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

you're system looks like it just puts individual AI on their own system (a city watch isn't on team 2 anymore)

Well, that's not exact. The script only sets the ai to be neutral to the player. The city watch in your example would still be in team 2, so the relations to other teams don't change.

In my code, the system works at the "go hostile" code, to stop a naturally hostile AI going hostile when the condition (seeing a crime) isn't met.

This sounds a bit unpractical.

The mapper can just deal with AI individually however they want.

The mapper could do that, although I guess they wont except in some special cases where it makes sense.

 

Anyways, as you said both approaches most certainly end up with the same results. But when continuing working on it I'll stick to my approach instead of trying to mess around with a new one.

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

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

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • 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.
      · 4 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
×
×
  • Create New...