11 réponses à ce sujet

[nametab]

I'm using the gb_ambient_ud and gb_ambient_sp scripts for ambient behavior on my NPC's (commoners). The thing actually works but... only in an interior area. I've assigned the two scripts and imported the appropriate variables (alc_observer) for two commoners in the interior area and two commoners in an exterior area. Everything is exactly the same: same scripts, same variables for the commoners, same waypoints named "wp_observe" etc. The two commoners located in the interior area do everything correctly - they randomly choose one of the "wp_observe" waypoints, approach it, wait a few heartbeats and choose another waypoint to go to. But in the exterior area, the NPC's  just choose one waypoint after spawning (also randomly) but once they get to it they stay there and refuse to move unless I start chasing them with an axe.

Of course I immediately started comparing the waypoints and NPCs from both areas but everything is exactly the same and I just can't seem to find the reason for this mess. Is there a bug that doesn't allow the script to work properly in an exterior area or am I missing something here? 

[Morbane]

Try using unique waypoint tags.

[nametab]

The script looks for all the waypoints named "wp_observe" and then chooses one randomly. Giving the waypoints unique tags just makes the NPC remain in his original position and the script does not work.



The two areas are connected via a door, but I don't suppose this can be the cause of this problem, because the script works fine inside the house and the NPCs there don't look for waypoints outside of their own area.

[Shallina]

You need to name your waypoint differently or to specify the area where you are searching.

When you search for an object, you don't search inside the area by default but inside the whole module.

You 'll get the first WP with the name you searched, so always the same. What happens in your case is :: it works in the first area and not in the second. Beceause the script used in the second bring the first wp of the name you want that is in the first area.

[nametab]

The commoners outside actually manage to find the first waypoint in their own area and move towrd it, so it's not as if they're looking for the interior waypoints from the start. However I'll try to make a copy of the script and change the tag of the waypoint(s) it's looking for and then I'll change the tags on the exterior wps.

...and it did not help, unfortunately. I changed the tags of the exterior waypoints to "wp_observe_ext" and made the proper adjustments to the script's copy. Still, the commoners just choose one waypoint and stick to it forever. The script uses PickRandomTagInArea so the NPC is looking for the waypoints only in his own area and the interior area's waypoints can't be causing any glitches.

Modifié par nametab, 01 septembre 2010 - 02:37 .

[Kaldor Silverwand]

I don't think the tag names are the problem. The script should be checking for only the ones in the area.



Have you placed the waypoints in locations that are in the walkmesh and reachable by the NPC's?



Regards

[nametab]

Kaldor Silverwand wrote...
Have you placed the waypoints in locations that are in the walkmesh and reachable by the NPC's?

Yes, both areas are properly baked and the waypoints are reachable for the NPCs.

[Orion7486]

Looking into this, I see that the als_observer variable sets POI to 10, shopping to 0. In the ALC_DetermineAction part of the UD script, it checks int iRand. iRand is random number plus 1, with maximum of poi + shopping. Thus the max of iRand will be 11. It then checks value of iRand. If it's less than or equal to poi value(10), then it moves to random wp.



If iRand gets to maximum of 11, it looks like it defaults to a commented out speakstring. Thus the npc wouldn't do anything that heartbeat. Is there a problem with Random function where it gets locked in at the same value(10) rather than changing each heartbeat?



Other things might be occurring that are interrupting the npc's in the exterior. In the interior, are the 2 npc's the only creatures in that area? Maybe in the exterior, there are other npc's that are causing a conflict with the ambient script?

Have you checked the npc's in the exterior do not have very low AI? In the UD script, the script won't run for npc's with very low AI.

I have no idea if any of this will help.

[Orion7486]

Double post

Modifié par Orion7486, 02 septembre 2010 - 01:01 .

[nametab]

1. I'm not sure if I fully understand. The random function seems to work just fine with the "interior" commoners and I don't know what could be disrupting it in the exterior area.

2. Yes, there are other NPCs in the exterior area, but they have different tags and scripts. I've put some additional NPCs in the interior area, gave them different tags, scripts etc. and they don't seem to be interrupting the random walk process there, so I don't think this is the case in the exterior area.

3. How do I check an NPC's AI? I'm pretty sure it's the same for both the interior and exterior NPCs, because they were all taken straight from the palette. However, I'd check that if I knew how, just in case.

[Orion7486]

Then don't worry about the AI. I believe by default it's set at low, not very low.

Have you tried setting up a test mod with an exterior area, with only the one npc in it, running this stuff? At least that's a way to see if it's been set up wrong or if something in your area is hindering it.

[nametab]

Orion7486 wrote...
Have you tried setting up a test mod with an exterior area, with only the one npc in it, running this stuff? At least that's a way to see if it's been set up wrong or if something in your area is hindering it.

I've followed your advice, created a new test module with just one exterior area and the script works there... so there's got to be something wrong with just that one area in my original module. But I have no idea what the problem is... I don't have any variables or scripts assigned to the area (yet), everything is properly baked, I don't see how the other NPCs could interfere with the script.