{"action":"created","issue":{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/14416","labels_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/14416/labels{/name}","comments_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/14416/comments","events_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/14416/events","html_url":"https://github.com/CleverRaven/Cataclysm-DDA/pull/14416","id":121909026,"number":14416,"title":"Craft in the dark [WIP][CR]","user":{"login":"sparr","id":121299,"avatar_url":"https://avatars.githubusercontent.com/u/121299?v=3","gravatar_id":"","url":"https://api.github.com/users/sparr","html_url":"https://github.com/sparr","followers_url":"https://api.github.com/users/sparr/followers","following_url":"https://api.github.com/users/sparr/following{/other_user}","gists_url":"https://api.github.com/users/sparr/gists{/gist_id}","starred_url":"https://api.github.com/users/sparr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sparr/subscriptions","organizations_url":"https://api.github.com/users/sparr/orgs","repos_url":"https://api.github.com/users/sparr/repos","events_url":"https://api.github.com/users/sparr/events{/privacy}","received_events_url":"https://api.github.com/users/sparr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-12-13T09:10:54Z","updated_at":"2015-12-14T14:30:41Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/pulls/14416","html_url":"https://github.com/CleverRaven/Cataclysm-DDA/pull/14416","diff_url":"https://github.com/CleverRaven/Cataclysm-DDA/pull/14416.diff","patch_url":"https://github.com/CleverRaven/Cataclysm-DDA/pull/14416.patch"},"body":"I added the ability to have flags in recipes. Since there are so few, it's just a `std::set` for now. If we start having a lot of them, they can get refactored like all the other entity flags have.\r\n\r\nI added two new flags to recipes, `BLIND_EASY` and `BLIND_HARD`. Either indicates that it is possible to craft an item in the dark (or blind). Both require a skill level of difficulty+2. The latter indicates a slowdown in crafting speed, from 100% speed at just-light-enough to 33% speed in pitch black. The same applies to disassembly.\r\n\r\nI added the flags to many recipes. I tried to make sensible decisions about things that seemed like to be trivial or slow to do in the dark.\r\n\r\nI modified the crafting gui so that the \"can craft?\" indicator in the top right redraws as you select different recipes, so some will say \"too dark\" and some \"yes\". There's also a new \"slow\" indicator for `BLIND_HARD` recipes in low light. Also the middle column of the gui has a \"Dark crafting?\" row with options \"Easy\" \"Hard\" \"Impossible\".\r\n\r\nI modified a number of crafting and disassembly checks that previously used `fine_detail_vision_mod()` so they now use `lighting_craft_speed_multiplier()`, which should directly mimic their craftability.\r\n\r\nI modified fine_detail_vision_mod() to return a wider range. The previous behavior was not as useful, mis-documented, and malformed. I do not believe any existing uses of this function will be impacted by this change.\r\n\r\nI changed a few crafting functions to refer to specific recipes, due to the above changes' reliance on the skill/difficulty of each recipe.\r\n\r\nI've tried to test this in as many ways as I can, but some quirks in the crafting interface and recipe dictionary make it slow going without being able to use the debug menu to learn recipes. Further playtesting is required before this patch can be merged.\r\n\r\ncloses #14285 \r\ncloses #14287 "},"comment":{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/comments/164451607","html_url":"https://github.com/CleverRaven/Cataclysm-DDA/pull/14416#issuecomment-164451607","issue_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/14416","id":164451607,"user":{"login":"BevapDin","id":5095435,"avatar_url":"https://avatars.githubusercontent.com/u/5095435?v=3","gravatar_id":"","url":"https://api.github.com/users/BevapDin","html_url":"https://github.com/BevapDin","followers_url":"https://api.github.com/users/BevapDin/followers","following_url":"https://api.github.com/users/BevapDin/following{/other_user}","gists_url":"https://api.github.com/users/BevapDin/gists{/gist_id}","starred_url":"https://api.github.com/users/BevapDin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BevapDin/subscriptions","organizations_url":"https://api.github.com/users/BevapDin/orgs","repos_url":"https://api.github.com/users/BevapDin/repos","events_url":"https://api.github.com/users/BevapDin/events{/privacy}","received_events_url":"https://api.github.com/users/BevapDin/received_events","type":"User","site_admin":false},"created_at":"2015-12-14T14:30:41Z","updated_at":"2015-12-14T14:30:41Z","body":"There seems to be a slight confusion: I'm not against flags, I'm against implementing them as big old chunk of `std::set<std::string>` when it's not *necessary* at all.\r\n\r\nWhat exactly do you gain by storing them as set of strings instead of dedicated bool members? Using members has advantages:\r\n\r\n- avoids name conflicts: somebody may add a flag that is already (unknown to them) used somewhere.\r\n- spellchecking at compile time (and auto completion by IDE),\r\n- faster code,\r\n- easier usage: `foo.flag` vs `foo.has_flag(\"flag\")`\r\n- overview of used flags directly in the class,\r\n- documentation of all available flags, perhaps via Doxygen.\r\n\r\nFor example: somebody may implement a new item type feature and may choose to use the flag \"CHARGE\" to trigger this feature. But that flag is already used by the charger gun, so charger guns automatically have the new feature and all items with the new feature are automatically chargers guns. With generic flag sets, the conflict can only be detected at run time by carefully testing the item. With bool members, one would get this at compile time, or even earlier while adding the new member.\r\n\r\n----\r\n\r\nI'm also not opposed to loading this from a JSON array (and not from several JSON members), in fact this might even be better as it allows checking of the provided flags:\r\n```C++\r\nfor( auto &f : jobj.get_flags( \"flags\" ) ) {\r\n\tif( f == \"a\" ) {\r\n\t\tobj.a = true;\r\n\t} else if( f == \"b\" ) {\r\n\t\t...\r\n\t} else {\r\n\t\tjobj.throw_error( \"unknown flag: \" + f );\r\n\t}\r\n}\r\n```\r\nAdding new flags only requires adding two new lines here:\r\n```C++\r\n\t} else if( f == \"new_flag\" ) {\r\n\t\tobj.new_flag = true;\r\n```\r\nand a declaration in the class.\r\n\r\n----\r\n\r\nNeither this PR, nor the linked one requires a generic `std::set` to store the flags, both can do just fine with bool members. Adding a new flag usually requires one to add code anyway, so adding another member and loading it shouldn't be to much overhead.\r\n\r\n----\r\n\r\nBtw. and totally unrelated: you need to document the new flags and their meaning in doc/JSON_INFO.md.\r\n"}}