MB> In the .html scheme I posted initially
Does not fit in. It does not define alternatives, it only says that
they are possible. As you can see in my post, I had to add additional
IDs to cement and lime
MB>
http://www.ttdpatch.de/cargo_scheme.html ) there are already slot IDs
MB> and cargo bits flags.
I used it as a base. The problem is to define alternative schemas and
show them on the global schema. I plan to do it as soon as we plan at
least one schema. It is possible to divide it into parts too.
>> Then to combine all the efforts into one grf, that provides
>> cargo (petrol should be moved to that file too).
MB> Well. No. I donґt like this approach both from technical and legal
MB> reasons.
Well, then we have to spend many efforts on collaboration. Technically
yes, it is possible, because we can read parameters of the other GRFs.
MB> Iґll provide a NewCargo .grf which will include all *my* cargoes
*CARGOS* ARE *NOT* *YOURS*. GRAPHICS DOES. "Let's divide flies from
meat" as we say here. We can code and draw parts of the schema and
call it "my part". But the general schema should be common and public.
Then, what should we do, if I provide Glass works and glass, while
your brewery accepts glass?
Michael, It is Ok to have copyrights for graphics, but I'm strongly
against copyrighting the concept. In our case it is possible to have
the following solutions:
A) common schema based schema
- Cargos are common, no one or the TTD community the holds copyright.
So called main GRF. If you want I can draw icons and code this GRF,
I think Wile will help me. Alternative variants of cargo chains are
also defined here and are chosen by a parameter
- Cargos on vehicles (with vehicles) belong to the vehicles set
authors (but we can exchange cargos graphics with permissions of
cause as we did already) (as many GRFs as we want). The chosen
variant is of cargo schema is defined via access to the main GRF
parameter
- New industries with default (TTDs) graphics are common, no one or
the TTD community holds the copyright. I can also code it in the
main GRF
- Industries with new graphics belong to their authors (as many GRFs
as we want)
We can code it that way, that the main GRF tests for GRFs with new
industries graphics and disable its' part for this new industries
from thew new GRFs. The new GRFs test for main GRF and reports a
error if it is not available
B) parts based schema
- artists select their part of the schema and draw and code it
then we should work on collaboration (as for the example of glass).
You GRF with brewery will test for my GRF with glass (and report error
if not represented). Some additional collaboration would be required.
Example: Wile part redefines oil refinery to produce rubber instead of
goods. It checks for my set is loaded after his set, his set generates
error. If my set is loaded before his set, his set does nothing. If my
set is not loaded, his set defines rubber as oil refinery's output. My
set should check for his set is loaded after my set and defines oil
refinery output as petrol and rubber.
Both solutions are technically possible.
I think solution A) is technically easier an B) is easier for
copyrights issues.
MB> and industries. For reasons of flexibility and because the number of
MB> industries on a typical TTD map will be limited, Iґll provide a switch
MB> mechanisms (by parameters) to activate or de-activate single cargo
MB> chains, i.e. "fishing" (fish, fishing grounds and food processing) or
MB> "brewery" (beer, brewery, beer acceptance in towns) etc.
bad idea. disabling fish should not disable food plant if (for
example "my") livestock is defined.
MB> In this way, industries and cargoes are separated already and it would
MB> be easy to add even more industries and cargoes by additional .grfs.
How do you see their collaboration? For example, how to specify the
collaboration of sets if rubber part is alternative to chemicals? In
this case we need collaboration of not two but three and even more
sets. I think it is rather boring to add a test for all the other sets
in each set. It would be much easier to specify cargo vectors variant
in main GRF and test selected vector in each GRF (The GRF will disable
itself if unacceptable vector is selected).
I think solution A) is easier to maintain.
MB> We donґt need to have one large single NewCargo .grf, but o/c we need a
MB> consistent scheme of cargo slot IDs and cargo bit masks.
Yes, it would be easier to do it with solution A)
["chemical products"]
>> And what do they accept?
MB> In reality chemical industries accept quite a big number of preliminary
MB> products in rigid, liquid and gaseous form from diverse sources.
I mean in game
MB> The only problem I see is to find one "generic" name for the preliminary
MB> product delivered from refineries to chemical plants rather than to have
MB> one of those many real product names. In my scheme Iґm using the term
MB> "refined products".
Were are they produced?
MB> Other two inputs for the chemical plant could be "sulphur" and "potash",
MB> these are the preliminary products to produce "fertilizer". O/c one of
MB> them would suffice, hence "sulphur" being a "private cargo", possibly.
Potash is ok because it is raw material (mined in mines) while
sulphur is not, because it moves chemicals plant to the third level.
BTW. What chemical product is used to produce textile? What is it
produced from?
MB> In any case, iґll have "potash" in my scheme.
In COMMON schema.
Should it be produced in open pit? We have enough industry slots (7)
to add a new one. While we have only 2 cargo slots.
MB> This is a very important product/industry in Germany (and thus for
MB> the DB Set) and a potash mine would fit nicely in TTDs class of
MB> "mining industry" (coal, iron ore, potash; copper and gold for
MB> climates other than temperate).
you forgot open pit for sand and lime
>> Sulphur from power plant is good here. But!
>> The problem is the cargo vector. If we use Sulphur to produce
>> chemicals, we can't send chemicals anywhere except automobile industry
>> and printing works, because otherwise we get 5 levels of
>> transportations, while we wanted to have 4 max.
MB> Well. I donґt understand your persistency w. regard to "levels".
Because of the map size and the amount of industries I find 4 levels
of transportation as a much. 5 levels are too much for TTD maps. If
you plan to make a reduced part of a scheme, than 5 levels is
extremely huge amount of levels. If you'll count 2 inputs on every
level, you get 30!!! cargos only for this vector. While 32 is the max
we can have. Sorry, Michael, but I'm STRONGLY against 5 levels of
transportations.
There is a possible solution (dyes) below to fit in with 4 levels
with chemicals plant on the third level.
>> So, if we want to send chemicals to textile mill or others, we need
>> to make chemicals plant to accept raw materials.
MB> "Potash" would be a raw material.
That vector is ok
MB> "Sulphur" would be *kind of* another raw material.
No. It is produced from other cargo. So, it is a 1 level product! If
Sulphur is produced in mines and chemical plant accepts oil directly,
then everything is Ok. But coal-sulphur-chemical-textile-cars vector
is too long. No.
MB> "Refined products" (from the oil refinery) would be a
MB> product by itself. IMO, that doesnґt matter much because nobody
MB> would have to care about from which preliminary product exactly
MB> one of the two products of an industry is produced, i.e. a "raw
MB> material" or an "intermediate product".
But to build the whole vector the player should use all the levels. I
made many networks
and can say, that even 3 cargos is long enough.
4 will take the whole map. 5 is too long for 255x255 map.
If you really want chemical plant to be the 3-d level industry, then
we should remove textile from automobile plant and unite paper mill
and printing works (and remove paper). Then sulphur would be Ok.
>> So, what to do with chemicals? I really want to have something of
>> that style at textile mill.
MB> Yes. IMO, textile mills should have two inputs rather than only one:
MB> Wool (or cotton in tropic) and "chemical products" (which would be e.g.
MB> dyes or solvents in reality).
:shocked: but there are three of them in the schema - chemicals, wool
and agricultural products. Did you read it before posting the answer?
>>> - "chemicals" shouldnґt be sent to "chemical industries/chem. plants"
>>> (whatsoever its name) but are (and should be) the *product* of those.
>> And what are they made from?
MB> In TTD? Well, "refined products" (from refinery), "potash" (from potash
MB> mine), "sulphur" (from power plant (in temperate)). We do not have more
MB> inputs in our current scheme.
what (except chemicals plant) will accept "refined products"?
MB> In reality, chemical plants would accept nearly everything both organic
MB> and inorganic materials.
What about organic materials? May be to add something?
MB> Products would be mainly other "chemical products", "pharmaceuticals",
MB> plastics, dyes, solvents, gases, etc. pp.
GOOD! we can remove textile from automobile plant, introduce dyes and
send it to automobile plant and printing works. Can we use refined
products to produce paper from wood products instead of chemicals?
everything will fit good then into 4 levels.
["waste", "garbage"]
>>> I really donґt like that idea.
>> I don't like this idea too.
MB> OK. Then letґs skip it *officially*.
OK
["wood products"]
MB> ATM, Iґm working on the "building materials" cargo chain. I.e. Iґve put
MB> together a "brick works" which produces "bricks" which are sent to a
MB> "building center" which would be situated near towns.
MB> Although the "building center" itself doesnґt produce any new cargo from
MB> its input (I skipped the new cargo "building materials" being
MB> superfluous) it accepts two more input cargoes, namely "timber" from the
MB> saw mill and "steel" from the steel mill (this could/would be changed to
MB> "cement" whenever the "cement works" would be available. However, we
MB> could only have three input cargoes)).
Good idea. I'll try to fit in.
MB> In addition, we could make a special type of "factory" which accepts
MB> "wood products" e.g. for producing "furniture". This factory could be a
MB> "parallel" one or a .grf specific.
I don't see place for it now.
MB> From my opinion, there are still more questions around "factories". Iґve
MB> discussed this with various other people involved and there are good
MB> reasons to keep the original (generic) type if "goods" as well.
What are they? I don't see any now
MB> FYI, Iґve posted this reply to the NewCargo discussion thread in
MB> tt-forums as well.
Ok, I'll do the same
), who don't want to understand a complex .grf system, they just want to play the game with as little fuss as possible.
.
