I'd like to help in the development of TDM if I'm needed. I'm near the end of a PhD in Computer Science and have a lot of time on my hands before I start a job. I've always wanted to create a stealth game, and this morning I checked out my game I was making a year ago (Unreal Engine) and it was a complete mess and made me sad and then I closed Unreal Engine.

Then I looked into writing my own engine - which would take way too long. Then I realised I can offer my skills to an open source project so why not this one!

Currently I've just downloaded the latest stable build and got 4 out of 5 building (not MayaImport), and I'm going to look through the code and try to understand the basic structure of it all.

Regarding my previous work my Portfolio, GitHub and Twitter are available. Though for the latter I haven't done any gamedev for a while so it's not as good as the other too.

Also if there are any books you'd recommend regarding the idTech Engine or just stuff that will help for learning the codebase, please suggest away

Since one objective in the mission is to find and steal "The Stone", why is it marked "inv_map_start" "1". That says the player has it in his inventory at mission start, which is obviously not the case.

And CShop::AddPersistentStartingEquipment() is called in a campaign for mission N to carry over persistent items from mission N-1.

Okay, I see that Volta and the Stoneis the first mission in a campaign.

So is the problematic definition defined in the second map in the campaign, which hasn't been released yet? And the second map is placing the stone in the player's inventory because he found it in the first mission?

For inventory items that aren't supposed to be droppable (like the compass and the lockpicks), they get this spawnarg:

"inv_droppable" "0"

The bug is that these types of items have an active Drop button in the Shop regardless. And if the player clicks on that button, it changes to Take, which means it's no longer in their inventory. But at mission start, it's there anyway.

I don't think anyone's ever come across this before because these non-droppable items are non-droppable for a purpose: they're most likely essential to the mission.

So w/o getting into the complications of a campaign, any item that's marked "inv_droppable/0" should have neither a Take nor a Drop button in the Shop Gui. The field should be left blank, and made unresponsive to the player keys.

Given that, you can test with any map that has a shop. Most missions have compasses and lockpicks in them, so you just have to start a few missions until you find one with a Shop.

I'm gonna play some missions and then look at another bug, because I think I've got as far as I can with this. Needs a better understanding of scripting etc to know where things are supposed to go (in def files or map files). But I've found a workaround and documented everything so hopefully it will help for a full fix if needed

In general, def files globally define entities, while map files define any deviations from these definitions. So, if it is only in a certain map that the item should not be dropped, it is defined in the map file (by the map author), if it should not be dropped in general, it should be defined in the def file.

Edit: At least this should be, where goes what. I have to admit that I don't have much experience, when it comes to the shop.

Edit 2: After taking another look at the Shop Wiki Page, it appears that the place of the definition depends on the method, the map author chose to add the item to the shop. If the item is placed in the map and given the spawnarg "inv_map_start" "1", it will apparently appear in the shop. Items added this way can be modified in the map file. Items that are added using the "shopitem_N_item" spawnarg in the shop entity use the definitions of the def files.

No, "inv_map_start" "1" is a spawnarg, i.e. a property that an item has (the values are set, as soon as the item is spawned, hence the name). If you place an item into your map and give it this property, it will add the item to the player's inventory on map start, which is why it also appears in the shop. This option is mostly improtant for items that the map author wanted to change in some way, and thus, deviate from the general definition. If the item is used "as is", it should be added to the shop entity via the spawnarg "shopitem_N_item". This omits the need for creating each item in the map and then adding it to the shop, but does not let you change any properties of these items.

Wrt issue 4499, I suggest starting a thread in the General Discussion -> The Dark Mod forum to discuss the requested change.

I agree that it's slightly disconcerting that the mission names are listed differently, but that's my opinion. Others might have a different opinion.

You need to suss out whether there's a consensus for listing missions as "A blah blah blah" or "Blah blah blah, A", then make the change in the code that doesn't use that form, to switch it to use the form that most people like.

Okay, so wrt "inv_droppable", if it's set to NO ("0") in the map, then the Shop code already takes care of NOT displaying the Drop/Take button?

If that's the case, then fixing the Volta map solve's Volta's problem, but it leaves the general case where un-droppable items like the Compass and lockpicks in other maps still get a Drop/Take button that lets the player drop the item but still have it when the mission starts.

As Grayman stated: the code checks if "inv_dropable" is defined in the map file. If it is not defined, (according to Grayman) it should set it to "0" by default. However, this appears to be not recognised by the code for the shop, as items not added with "inv_map_start" appear to be droppable in the shop (even though they are not in the map). At least, this is how I currently understand it.

Edit: double post because I couldn't figure out how to quote two users in the same post

Whenever you hit the "quote" button, it adds the respective post to position of the cursor in your Reply field. This means, you can simply hit several "Quote" buttons and have all the quotes in your reply field.

Okay, so wrt "inv_droppable", if it's set to NO ("0") in the map, then the Shop code already takes care of NOT displaying the Drop/Take button?

If that's the case, then fixing the Volta map solve's Volta's problem, but it leaves the general case where un-droppable items like the Compass and lockpicks in other maps still get a Drop/Take button that lets the player drop the item but still have it when the mission starts.

First sentence = Yes

Second point, you are correct, I can't see a fix for the general case without a fundamental change of the behaviour of the reading of the files - I think it would be better just to hardcode the fixes, since they are in-built items and people can still control custom items.The hardcode fix will be something like:

CanDrop?() {
If Name In { "Compass", "Lockpick", "Blackjack", ... }
Return False
Behave As Normal From Here On
}