 |
What if you defined an absence_location around the original spawn spot of the object, then bound the absence_location to the AI carrying the object? In theory, the absence_location would then follow the carrier around, and the absence checks would not fail until the player pickpocketed the item. |
|
|
What is "absence_boundary"? Do you mean "absence_bounds_tolerance"? |
 |
That was essentially the circumstance, but I simply used the AI as the location. absence_bounds_tolerance 99 absence_location AIname absence_noticeability 1 absence_noticeability_recheck_interval 0 Only by doing that can you cause the absence_marker to spawn when the player takes the object (otherwise it would spawn when the AI walks away). In either case, it spawns where the object was at map start, not where the object is when it is taken by the player. Edit: see forum thread for workaround via item possession objective that teleports an absence marker to proper location. |
|
|
Ah, what I wasn't hearing was that you used the carrier as the absence_location. In that case, yes, the marker doesn't spawn until the object leaves the absence_location. The code assumes nothing in the scenario is moving (not the object, not the absence_location, etc.), so it spawns the marker in the object's original location, when it was originally placed in the carrier's hands. So the trick is to understand the correct place to put the marker. The solution is a new spawnarg that tells the marker code to spawn the marker at the object's last known location, rather than at its original spawn location. Default is the original location, so as not to break existing maps. Since the absence check is done every 5s, the marker could be spawned a distance from the carrier equivalent to how far he traveled during the 5s since the last good check. Is this going to satisfy your goal? How does the carrier spot the marker, which may very well be spawned behind him? How does he spot it if the player snatches the object in dim lighting, where no AI is going to see a marker? It seems a far better approach would be to have a script check every few seconds to see if the carrier is still holding the object. That guarantees good results regardless of LOS or lighting. |
|
|
The five seconds would be a liability, path turns, movers reversing course, all would negate forecasting to spawn ahead, and behind would be moot. I would not introduce this feature if five seconds is a limit. The only solution I could see in that case would be the new spawnarg also increasing the check frequency sadly. In my opinion, the marker should not be spotted in inappropriate light, so the player may choose a more appropriate time to pick-pocket, just as currently they may choose to douse or shade lights, to increase game-play. I'd avoid introducing a new game mechanic (AI feeling pick pocketing), just allowing the existing one to be used (it's not apparent that it shouldn't be used in this way per documentation). I agree that an alternative approach (scripted) would be better if a designer wishes to simulate noticing pick-pocketing by other senses (feel, sound, aroma, etc.) |
|
|
Having an AI not react to having his pocket picked is a long-standing issue that I plan to address in 2.02. Since only the player controls where the marker would be dropped, by choosing when he steals the object, even reducing the absence check frequency doesn't guarantee that the AI will notice. In the case of static objects, it's up to the mapper to provide enough light to guarantee that AI will spot the marker. When we move control to the player, all bets are off, so I don't think using the absence marker system is a good way to solve this problem. Atm, the only planned reaction to having your pocket picked is to stop, perhaps turn around, and bark something appropriate. The barks are already in place. The picked pocket code is in place. It's just the reaction that's missing. Perhaps there's a way to have an AI react in a unique manner. I'll need to think about that, and probably post a thread where mappers can discuss the pros and cons. |
|
|
That sounds like a separate issue. In this case, there's an apparent functionality of an existing system that doesn't work. There's already appropriate reactions. The only missing element is having the alert in the right place. This can be worked around using the objective system and teleporting an alert in, but that is not apparent to mappers and is cumbersome. Perhaps the best solution is to change the documentation to indicate the absence system fails in this application? True, currently mappers choose the lighting conditions, but they also choose lighting conditions along the path of AI, or along the path of a mover. I don't see how that applies to having the absence marker arrive at the point of removal. Oh! Per the five second check, why would that matter? At the time of the check, presumably the marker would be placed bound to the mover or AI as the original item was, no prediction of movement or worry of it being behind. |
|
|
This isn't a failure of the absence marker system. It operates the way the wiki article describes it. There isn't anything on the wiki page that should lead one to assume that it handles moving objects. Having it also handle moving objects is an extension of its current capabilities, so this is more of a feature request than a bug report. The 5s check is relevant in that it has to have something to compare. In the case of a static object, the comparison is either between the original bounding box of the object (or the additional bounding boxes of a number of absence_locations, with or without an expansion applied) and the current bounding box of the object. Having determined that the object fails the check, where in the collection of places it's checking should it decide to place the marker? For the case of a static object, that place is its spawn location. For a moving object, we would extend the code to register the relative location inside the one absence_location we care about: the AI's bounding box. The marker is then placed, but now we encounter the issue of lighting and LOS. How does the AI establish LOS from its eyes to one of its hands? I don't think any AI's FOV extends down to its hands. And even if it did, there's no guarantee that there's enough light at that location for the AI to see the marker. The mapper can certainly light the crap out of the carrier's patrol path, but how do you handle the situation where the AI leaves that path to search, or to flee? It seems much simpler for the mapper to write what amounts to a few line of script to check for the presence of the object. Then all other concerns (LOS, lighting, chance, etc.) vanish. |
|
|
*nods, yup, hence listing it as a feature request. On my first released mission I used a scroll in an AI hand and it was noticed. I looked previously for a mention in the wiki limiting it's use to stationary objects and missed any. Quite the opposite there's talk of moving objects to other rooms in a different context (under player control rather than mover entity, but I'd fully expect to put an object on an elevator, like dumbwaiter and have it work based on that example--but it won't). Previously I was going to add such a limitation mention to the wiki, but since it can be used via the objective/teleport workaround, I'll add that instead if this feature suggestion isn't desired. There's no indication in Dark Radiant of such a restriction. Quite the opposite, there are spawnargs enabling it. Should lighting choices be selected by designers or dictated as not an option by code restrictions? What happens where the AI leaves path? Either the designer appreciates that result, or doesn't implement the feature, like any design choice. However currently designers don't get to choose, the apparent functionality is available, but doesn't work as expected, and there's no visible feedback that it's not working when mappers implement it. Once the physical marker bug is resolved, there won't even be invisible evidence that it's not functioning. It's entirely possible mappers have already used it and believe it to be functioning, as I have for the past two months. It wasn't until I bumped into the invisible physical marker, and realized what it was, I knew something was wrong. Many mappers are not coders, can't write any scripts, or would rather spend time designing rather than scripting. Thankfully you don't need to, being able to use the objective system to teleport a marker in, nothing extra needed. Although as the feature suggester I don't feel I should vote further whether it's implemented or not, the time saved future mappers who discover through testing it doesn't work as expected and go on to search out the workaround might not warrant spending time implementing this. The bigger question would be how many have already used it not realizing it doesn't work? How many in the future? If there's a cool new pick pocket response readily available like you suggested earlier, this might become a moot point as fewer would be apt to apply this to accomplish that, hopefully. |
 |
I'd like to add my opinion here on "moving" vs. "static". IMHO the absence marker not taking into acount moving objects is a bug, not just a missing feature. Wether you want to bind it to something, or put it on a moving platform, the code should acount for these situations automatically. Not doing so breaks expectations and violates consistency rules ("everything should work the same and there should be no hidden surprises"). Other entities (like trigger_touch) have the same limitations, while almost any other entities works as expected. So, I'd like to see this getting fixed. As for the technical solution: Why is it important that the spawned marker is spawned in the objects "map start" location instead of the location at the time the object is removed? Wouldn't the latter work automatically the same for all old maps? |
|
|
@Gman, can this be closed now seeings how Ai notice keys and purses when removed by the player. |
|
|
A moving AI was given as an example. No one's checked stealing an object off a mover. So it has to remain open until we decide we don't care or it gets fixed or it works ok. |
|
|
Ok, I will grab this and test. |
- Anonymous
