Store Page
Left 4 Dead 2
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews

Left 4 Dead 2

Store Page
Left 4 Dead 2 >  Workshop > smilzo's Workshop > Left 4 Bots 2 > Discussions
Left 4 Bots 2
Description Discussions99 Comments1654 Change Notes
M'aiqLuvsSkooma Apr 17 @ 4:47pm
Suggestion for new option: Left 4 Dead 1 styled Item Scavenging and Suggestions To Improve Looting Code
Let me just start off by saying, because of this addon I am able to fine tune and customize the bots almost exactly how I want. Buuut I feel there is one tiny thing missing, and preferably it should be an option in the settings file, that allows them to seek out loot like L4D1 bots.

What I mean by this is while L4B's looting code is actually really good, bots can only loot what they can see. In L4D1 bots could see items through walls and will actively go to grab said item if they detected it. So what I am requesting is an option in the settings that lets them detect through the wall and allowing them to go actively loot like the first game.

One more suggestion I have that would benefit the existing code and this requested new looting feature, would be for them to cancel looting or put it on hold when danger is around. In L4D1 if they saw enemies nearby or a teammate was in a fight, they would put looting on hold. L4B could benefit from this addition if it's possible to implement, so they don't do silly things like barrel through a horde for pills or grab ammo in a Tank's face.

If any of what I suggested is remotely possible, I think it would be awesome if these were implemented. <3
< >
Showing 1-8 of 8 comments
smilzo  [developer] Apr 19 @ 5:13am 
I added the visibility check for scavenging items to try to prevent the bots from going for items that are whithin the range but the path to reach them is actually too long or they are not reachable at all. The scavenging code could be improved a lot if the devs made available the vscript call for the function to calculate the nav path from point A to point B for a survivor.

For the second suggestion i was already thinking of turning the items scavenging code into an order with its own priority so the orders pause logics would take care of that.
Last edited by smilzo; Apr 19 @ 5:13am
#1
4512369781  [developer] Apr 19 @ 7:30am 
Originally posted by smilzo:
The scavenging code could be improved a lot if the devs made available the vscript call for the function to calculate the nav path from point A to point B for a survivor.
There is a function called NavAreaTravelDistance, and you have used it in l4b2.
#2
smilzo  [developer] Apr 19 @ 8:17am 
Originally posted by 4512369781:
Originally posted by smilzo:
The scavenging code could be improved a lot if the devs made available the vscript call for the function to calculate the nav path from point A to point B for a survivor.
There is a function called NavAreaTravelDistance, and you have used it in l4b2.
Yes but unfortunately that function is generic and doesn't check if the survivors can really take that path. You can see for example in c1m3 upper at the beginning of the corridor with the one way barricade, once you are in the corridor and you cannot go back but the function still thinks you can.
#3
4512369781  [developer] Apr 19 @ 9:28am 
Originally posted by smilzo:
Yes but unfortunately that function is generic and doesn't check if the survivors can really take that path. You can see for example in c1m3 upper at the beginning of the corridor with the one way barricade, once you are in the corridor and you cannot go back but the function still thinks you can.
That's true, but it's still more reliable than the line distance, and it should be fine if it's only used for scavenge, I think.
#4
smilzo  [developer] Apr 19 @ 9:59am 
Originally posted by 4512369781:
Originally posted by smilzo:
Yes but unfortunately that function is generic and doesn't check if the survivors can really take that path. You can see for example in c1m3 upper at the beginning of the corridor with the one way barricade, once you are in the corridor and you cannot go back but the function still thinks you can.
That's true, but it's still more reliable than the line distance, and it should be fine if it's only used for scavenge, I think.
The only problem would be when the item is not reachable, it will make the bot stuck trying to go there or teleport.
#5
4512369781  [developer] Apr 19 @ 10:12am 
Originally posted by smilzo:
The only problem would be when the item is not reachable, it will make the bot stuck trying to go there or teleport.
At this point, the line distance has the same problem.
But on the other hand, the current method is stable enough that there is no need to change it unless the gascan falls off a cliff.
#6
smilzo  [developer] Apr 20 @ 12:39am 
Originally posted by 4512369781:
Originally posted by smilzo:
The only problem would be when the item is not reachable, it will make the bot stuck trying to go there or teleport.
At this point, the line distance has the same problem.
But on the other hand, the current method is stable enough that there is no need to change it unless the gascan falls off a cliff.
Yes it has the same problem, this is why i added the visibility check, because if the item is very close and visible it is more likely that it is also reachable. The point is that in order to remove the visibility check we need a more reliable way to determine if the bot can reach the item and how long it will take.
Last edited by smilzo; Apr 20 @ 12:39am
#7
M'aiqLuvsSkooma May 10 @ 4:00pm 
I just had a small idea for a new suggestion, and I wonder if this will be more plausible. Wouldn't it be possible to make it were if a player looks at an item and uses "SmartLook" and calls out, for example, "Pills here!" and now the bot can see it and path to it? Like keep the current looting but allow me to call out items instead of just waiting for them to see it?
#8
< >
Showing 1-8 of 8 comments
Per page: 1530 50