ezee wrote:But before , lets look to your doc :
Factories work like this:
A factory has a number of production options.
There should not be too many because the factory collects and stores resources that it needs for production.
A factory is calculating the supplies it needs to buy from the market by taking the max over the required inputs for each production options respectively. A factory will calculate the price it is willing to pay by taking what it will get for selling its output, discounting it by the profit rate, and distributing the money over all resources in proportion to the current market value of the resources. Now a buy order can be placed on the market if there is enough money. If there isn't enough money, divide up the remaining money to place buy orders.
Upon receiving new supplies the factories reserve is check whether any production option may be executed fully or partially. Of the executable options, the one with the highest absolute profit is chosen and executed.
I am sorry. I do not recognise this text. Which doc is this? Nevermind. I have grep... doc/factory_masterplan.txt
I am doubly sorry. I believe this is an artifact from redadders' code. At first, I have gotten it to work with cmake, after which i started to check out how it actually worked, I have implemented pretty much a complete redesign. The factory and other components we are working with is way more accurately described in 'plan2.md'. Obviously, I should've paid more attention to the contents of this directory, as the factory_masterplan factory does not exist in my code. I shall try my best to clearify the situation.
Should you want to implement the factory_masterplan.txt's factory now using the market code, a 'base' would be the appropriate structure to represent the masterplan factory. The bases' cargoStore would be where the resources would be stored (with addCargo/deleteCargo).
What the masterplan calls a productionoption is split up into two parts in market, the Factory, and ProductionOption. the ProductionOption represents the possibility to do different types of production (for example, create only a few, or a lot of whatever resource you can make). The difference is that the masterplan run do multiple production options simultaniously, whilst only one ProductionOption per Factory can in a tick. Bases can have multiple Factores, which is how one can accomodate that functionality.
This document also talks about buy orders, worker pay, profit rates, discounts and whatnot. As you may have discovered this is very much not implemented in the current code. Most of these also do not seem to have an ability to have much impact on vegastrike in its current state, as to start, the whole concept of people is nonexistent. I will inspect this directory better this weekend and see to remove outdated and incorrect information. For now I apologise for this misunderstanding.
[snip]
bool ProductionOption::canProduce(const Cargo &cargoStore) const {
return cargoStore.contains(this->consumes);
}
Now , what is " this->consumes " ?
A pointer to Cargo .
If you want to be pedantic about it, it is a proper Cargo, but you probably don't mean that with this question.
A ProductionOption is the ability of a factory to create something out of something else. It has a 'consumes' Cargo variable, which is subtracted from the cargoStore that is passed during the Produce function. the produces Cargo is subsequently added to the same cargoStore. canProduce is a test whether the cargoStore actually contains what it needs to be producting. If there are not sufficient resources to take everything that is in consumes, no production will take place at all.
We are here:
Because a CargoType is insufficient input for a ProductionOption. A ProductionOption takes a Cargo(Container), and turns it into another Cargo(container).
Why a container is needed here ? Because of the std::map that contains all types of cargos available ?
Your system seem to be based in a " one time declaration " , i propose to push into the CargoContainer used
by the factory that is :
/** Cargo consumed by production. */
Cargo consumes;
The ProductionOption needs it because the Factory can choose to use either of the ProductionOptions available to it. For example, you can create a ProductionOption which turns one foo into one bar, one that turns two foos into three bars, and one that turns five foos into ten bars. Depending on the amount of foos you have, you (or the as of now nonexistent governer) may not be able to create a complete ten bars in a single turn, but may still want to create at least one.
Alternatively, you can create a Factory which can create all types of aircraft, This one factory will be able to create any aircraft, but only one per turn, so a militairy base may want to have more then one of those Factories.
What the factory consumes is dependant on which ProductionOption is used, so it is not able to store this information independent from its ProductionOptions. Similarly, the stored resources mentioned in masterplan are more accurately modelled as the Base's cargoStore.
A fonction like :
bool ProductionOption::addOption(CargoType &type)
{
// you take your iterator
// you find the type inside your consumer map
// you increment the second value if type exists ?
// return true if it's done , else false .
}
That is my proposition .
[/quote]
Unless defined during initiation, the consumer map is empty. Following your pseudocode, this function would do exactly nothing with default ProductionOptions, and can possibly increase the quantity of a certain CargoType by one when it is present in that map.
Running the addOption function essentially increases the amount of a certain resource needed for production by exactly one. Personally I do not see the much benefit of such an option (remember the amount it outputs doesn't grow with it) and as such i do not really understand why it would be called addOption. I guess this construct had to do with some confusion caused by the factory masterplan document, for which i again apologise.
I hope this has created a better picture of what is actually going on. If you have questions/comments regarding this i would be happy to hear so. The factory_masterplan.txt and deviously misnamed market_documentation.txt have little to no accurate information about the current state of the project.
reqdoc.txt is a document made by myself trying to map out what requirements there would be for this code to work.
plan2.md describes the current and future classes i have planned to implement. PriceList and Governer are not implemented and may possibly change before implementation starts.