dfhack/plugins/buildingplan-lib.cpp

#include "buildingplan-lib.h"

#include <cstdarg>
#include "Core.h"

using namespace DFHack;

bool show_debugging = false;

void debug(const char *fmt, ...)
{
    if (!show_debugging)
        return;

    color_ostream_proxy out(Core::getInstance().getConsole());
    out.print("DEBUG(buildingplan): ");
    va_list args;
    va_start(args, fmt);
    out.vprint(fmt, args);
    va_end(args);
    out.print("\n");
}
Initial work on fortplan plugin, including separating out code that needs to be shared with buildingplan 2014-12-23 14:56:15 -07:00			`#include "buildingplan-lib.h"`

prep buildingplan for core algorithm changes Lots of refactoring and reorganizing, with only cosmetic player-visible changes. - show quickfort mode hotlkey label regardless of whether the current building type has buildingplan enabled. before, it was only shown after the user enabled buildingplan for the current building. this eliminates the extra step when enabling quickfort mode, which force-enables all building types. - changed signature of lua-exported isPlannableBuilding to take subtype and custom type in addition to building type. this is only used by quickfort, and it already sends all three params in preparation for this change - added lua-exported scheduleCycle(), which is like doCycle(), but only takes effect on the next non-paused frame. this lets quickfort run only one buildingplan cycle regardless of how many #build blueprints were run - declared a few dfhack library methods and params const so buildingplan could call them from const methods - converted buildingplan internal debug logging fn to have a printf api - reshaped buildingplan-planner API and refactored implementation in preparation for upcoming core algorithm changes for supporing all building types (no externally-visible functionality changes) - changed df::building_type params to type, subtype, custom tuple keys - introduced capability to return multiple filters per building type (though the current buildings all only have one filter per) - split monolith hook functions in buildingplan.cpp into one per scope. this significantly cleans up the code and preps the hooks to handle iterating through multiple item filters. - got rid of send_key function and replaced with better reporting of whether keys have been handled 2020-10-16 14:52:23 -06:00			`#include <cstdarg>`
reorganize buildingplan code - no logic changes - no API or logic changes, just moving code around - split buildingplan-lib into planner and rooms files - move business logic from .h files to .cpp files 2020-09-08 01:17:56 -06:00			`#include "Core.h"`
Initial work on fortplan plugin, including separating out code that needs to be shared with buildingplan 2014-12-23 14:56:15 -07:00
reorganize buildingplan code - no logic changes - no API or logic changes, just moving code around - split buildingplan-lib into planner and rooms files - move business logic from .h files to .cpp files 2020-09-08 01:17:56 -06:00			`using namespace DFHack;`
Fix whitespace issues 2015-02-14 20:53:06 -07:00
reorganize buildingplan code - no logic changes - no API or logic changes, just moving code around - split buildingplan-lib into planner and rooms files - move business logic from .h files to .cpp files 2020-09-08 01:17:56 -06:00			`bool show_debugging = false;`
Initial work on fortplan plugin, including separating out code that needs to be shared with buildingplan 2014-12-23 14:56:15 -07:00
prep buildingplan for core algorithm changes Lots of refactoring and reorganizing, with only cosmetic player-visible changes. - show quickfort mode hotlkey label regardless of whether the current building type has buildingplan enabled. before, it was only shown after the user enabled buildingplan for the current building. this eliminates the extra step when enabling quickfort mode, which force-enables all building types. - changed signature of lua-exported isPlannableBuilding to take subtype and custom type in addition to building type. this is only used by quickfort, and it already sends all three params in preparation for this change - added lua-exported scheduleCycle(), which is like doCycle(), but only takes effect on the next non-paused frame. this lets quickfort run only one buildingplan cycle regardless of how many #build blueprints were run - declared a few dfhack library methods and params const so buildingplan could call them from const methods - converted buildingplan internal debug logging fn to have a printf api - reshaped buildingplan-planner API and refactored implementation in preparation for upcoming core algorithm changes for supporing all building types (no externally-visible functionality changes) - changed df::building_type params to type, subtype, custom tuple keys - introduced capability to return multiple filters per building type (though the current buildings all only have one filter per) - split monolith hook functions in buildingplan.cpp into one per scope. this significantly cleans up the code and preps the hooks to handle iterating through multiple item filters. - got rid of send_key function and replaced with better reporting of whether keys have been handled 2020-10-16 14:52:23 -06:00			`void debug(const char *fmt, ...)`
Initial work on fortplan plugin, including separating out code that needs to be shared with buildingplan 2014-12-23 14:56:15 -07:00			`{`
reorganize buildingplan code - no logic changes - no API or logic changes, just moving code around - split buildingplan-lib into planner and rooms files - move business logic from .h files to .cpp files 2020-09-08 01:17:56 -06:00			`if (!show_debugging)`
Fix whitespace issues 2015-02-14 20:53:06 -07:00			`return;`

reorganize buildingplan code - no logic changes - no API or logic changes, just moving code around - split buildingplan-lib into planner and rooms files - move business logic from .h files to .cpp files 2020-09-08 01:17:56 -06:00			`color_ostream_proxy out(Core::getInstance().getConsole());`
prep buildingplan for core algorithm changes Lots of refactoring and reorganizing, with only cosmetic player-visible changes. - show quickfort mode hotlkey label regardless of whether the current building type has buildingplan enabled. before, it was only shown after the user enabled buildingplan for the current building. this eliminates the extra step when enabling quickfort mode, which force-enables all building types. - changed signature of lua-exported isPlannableBuilding to take subtype and custom type in addition to building type. this is only used by quickfort, and it already sends all three params in preparation for this change - added lua-exported scheduleCycle(), which is like doCycle(), but only takes effect on the next non-paused frame. this lets quickfort run only one buildingplan cycle regardless of how many #build blueprints were run - declared a few dfhack library methods and params const so buildingplan could call them from const methods - converted buildingplan internal debug logging fn to have a printf api - reshaped buildingplan-planner API and refactored implementation in preparation for upcoming core algorithm changes for supporing all building types (no externally-visible functionality changes) - changed df::building_type params to type, subtype, custom tuple keys - introduced capability to return multiple filters per building type (though the current buildings all only have one filter per) - split monolith hook functions in buildingplan.cpp into one per scope. this significantly cleans up the code and preps the hooks to handle iterating through multiple item filters. - got rid of send_key function and replaced with better reporting of whether keys have been handled 2020-10-16 14:52:23 -06:00			`out.print("DEBUG(buildingplan): ");`
			`va_list args;`
			`va_start(args, fmt);`
			`out.vprint(fmt, args);`
			`va_end(args);`
			`out.print("\n");`
buildingplan: Don't assume building and item type names match There are a few building types (e.g. hatch covers) where this is not the case. Fixes #604 2015-07-27 12:05:26 -06:00			`}`