In the version of the experimental SDL build (downloaded today)…
I picked up two bear traps from a trap nest, and when I went (a)ctivated them to place them, they went onto the ground but did not get removed from my inventory. Thus I could place as many bear traps as I wanted. I tried dropping the bear trap and picking it back up, but the behavior remained.
same thing with other traps like caltrops and nail boards. ITS A TRAP!, INFINTE TRAPS
Sorry, I just had to:
Thanks for reporting, I have a fix for this, which actually ended up being an extensive rework of the 'a’ctivate method. It’s just waiting on review and merge.
I think there is no need to create another thread then.
You sometimes have to select the item with which you should do your action twice. Like when I want to throw a hammer into a spider i go ‘i’ → ‘F’ (letter for hammer) → ‘t’ and it instead of sending me directly to aiming mode sends me back to inventory to select which item would I like to throw. Same goes for ‘a’ and ‘d’ sometimes, didn’t yet try other builds. So far it worked on 0.8-1803 (if I am not mistaken, already removed it) and 1806 builds (throwing seems to work, but dropping and action still buggy).
Probably will be fixed soon anyway, but maybe it’ll help.
Burgerpro: As an alternative you can just 'T’hrow then select your weapon. I rarely if ever use the keys from inside the item’s description.
I know but that’s still a bug.
I am assuming this has already been found as well, but just in case;
This bug seems to be occurring as well with firearms and item modifications. I can modify a gun and the modification remains in my inventory. Just throwing it out there in case it’s helpful.
Thanks, I pretty much took a hatchet to ALL the code that was involved, so it should sort that out too.
well I’ve reported this bug with traps and mods some days ago but there was no reply 
If for whatever reason anyone is interested what is the reason of item not destroying itself after use, it is because of iuse::%whatever% returns it->type->charges_to_use() and for tools like roadmap, beartrap, extra battery mod, etc, this value is exactly zero in json. So, it never gets destroyed in player::use because in this code
int charges_used = tool->use.call(g, this, used, false);
if ( charges_used >= 1 ) {
if( tool->charges_per_use > 0 ) {
used->charges -= std::min(used->charges, charges_used);
} else {
// An item that doesn't normally expend charges is destroyed instead.
i_rem(let);
}
}
charges_used is zero.
This has already been fixed in the current experimental.
For extra battery mod and roadmap it isn’t, I’ve just checked it by spawning items with debug menu and by viewing the code. The compiled version is 0.8-2188-g4b95fcd.
Thanks for clarifying, I hate doppelganger bugs
Last I checked, you still can’t actually deploy fur rollmats either.
It throws an error message and eats the rollmat, but places nothing on the ground.
I wish I had some idea why it was doing so, but it worked just fine when I added fur rollmats in, and only started doing this weird error post-merge.
[quote=“Rivet, post:15, topic:3597”]Last I checked, you still can’t actually deploy fur rollmats either.
It throws an error message and eats the rollmat, but places nothing on the ground.
I wish I had some idea why it was doing so, but it worked just fine when I added fur rollmats in, and only started doing this weird error post-merge.
Git issue report.[/quote]
Because in iuse::set_trap() there are cot and rollmat, and no sign of fur_rollmat. Double check your PR code (I haven’t found your PR, sorry, so, couldn’t check it myself) and hope it was just a bad merge.
if(it->type->id == "cot"){
message << _("You unfold the cot and place it on the ground.");
type = tr_cot;
practice = 0;
} else if(it->type->id == "rollmat"){
message << _("You unroll the mat and lay it on the ground.");
type = tr_rollmat;
practice = 0;
You are 100% correct!
I just check the iuse function for it and sure enough, it wasn’t there at all.
I’m gonna blame this on a bad merge.
HEY! that’s… probably what happened <_<
Well I know that it worked fine when I originally PR’ed it. I’m guessing that file didn’t get pushed across like it was supposed to, or else something ate it during the merge process itself.