Started by DrSuperGood, July 06, 2014, 01:41:01 AM
0 Members and 1 Guest are viewing this topic.
QuoteThis is a very interesting suggestion, but may I ask: how had you envisaged detecting whether industries are connected? Do you mean connected by transport here, or connected in the sense of being suppliers and consumers of each other?
Quote from: DrSuperGood on July 13, 2014, 04:02:39 AM1. Fixed points are used without a type indicating that the number stored is in fixed point form. This leads to a lot of potential for errors and certainly makes the class unreadable (it took me hours to understand all the fixed point variables and what fractional size they were). I am trying to introduce named types that are just renamed normal integers so that programmers knows what type each value is stored as and what operations are needed to change it between types. This is not a long term solution, a special fixed point class should be used to decouple the fixed point arithmetic operations from the class implementation but that is not of high priority.
Quote from: DrSuperGood on July 13, 2014, 04:02:39 AM2. Many constants that should be in the header file were randomly in the implementation file. Some are being moved as nameless enums to the header for consistency and convenience.
QuoteWhile a good idea, I think it will be even more confusing when there is a fixed point type, but lots of the code (everything but fabrik_t) do fixed point arithmetic without it. Introducing a fixed point data type should also rather be a separate patch. I think that makes it easier to review, althought that's mostly prissi's problem.
QuoteThere are several fixed point "types" in Simutrans, many of which are scaled decimally rather than binarily.
QuoteI like enums to have names, so you know what they are for. If they are unrelated constrants, #define will do, or even better, a C++ const (global, perhaps static, or in the class, depending on it's scope).
QuoteIncidentally, how do you envisage this working differently to the current Simutrans-Experimental system?
Quote from: DrSuperGood on July 13, 2014, 01:18:12 PMYou compute max in transit based on real line metrics (which are totally rubbish atm... see my complaint thread about in transit times) giving a limit to the amount that can exist at any given time. The suggested approach has no such limit but instead just applies a limit on good generation (well goods being sent from suppliers) so that they are generated constantly instead of in bursts.
QuoteI see; and how would this differ in practice once the bug to which you refer has been fixed?
Quote from: DrSuperGood on July 13, 2014, 01:18:12 PMNameless enums are useful for defining constants as they are compiler inlined and produce more exact errors with some compilers. The "#define" macro should never ever be used for constants in c++ as it is not really type checked (it literally is just a textual copy and paste algorithm, many IDEs will fail to pickup a type mismatch with them and errors they generate at compile time can not be obvious, also they have certain problems relating to scopes and things), nameless enums achieve the same result as define for such constants are considerably safer and easier to use (they represent a value of a certain type, unlike define which just represents a piece of code). The use of constant global/statics is actually inefficient unless you need to take the address of the constant for some reason since it allocates memory for the constant and reads that instead of in-lining the constant into instructions. That said constants should optimize out with a properly set compiler and are certainly a lot better than define but still nameless enums have the advantage that they do not explicitly define a storage space for the value.
QuoteEnums are for creating data types that can only have specific values
QuoteYes, it is easier to work with a system in which there is notionally infinite warehouse storage at every consumer industry, but less realistic.
QuoteBasically, the "pipe" where you as the player had to choose the right thickness before would be given by the game. Doesn't that take away part of the challange?
Quote from: Leartin on July 14, 2014, 12:31:51 AMIf there is some consumer on your map which wants to have a good a factory somewhere else produces, but the consumer is too small to have the budget to ensure a steady stream, you just shouldn't connect them.
Quote from: Ters on July 14, 2014, 07:10:42 AMThat would easily become a boring "game" of doing nothing, then. At least as far as goods is concerned.
Quoteyou may still build a route that's balanced in a way that there is always the max in-transit used. It might not be enough to let the consumer run on 100 percent, but so what?
Quote from: Ters on July 14, 2014, 02:30:25 PMI dropped what you call the context, because it is irrelevant to me. I'm not bothered by how the consumer operates, but by the number of crowded station messages I get when the supplier suddenly starts dumping its accumulated storage.
QuoteWhy would I be forced to install bottlenecks?
QuoteThe only overcrowded stations are those next to the supplier, and I don't care for these.*
QuoteSome people like to play small maps, where the problems you have can't possibly come up, since in-transit and storage is always big enough.
QuoteI kick out all waiting vehicles but one - there you go, route optimized.
QuoteAlso, the amount of goods in-transit does matter, if you want to be realistic (and you used realism as a point) - companies have a budget. This is what max in-transit represents - If there is some consumer on your map which wants to have a good a factory somewhere else produces, but the consumer is too small to have the budget to ensure a steady stream, you just shouldn't connect them. That's realistic: The consumer just can't afford so many goods to be in transit. And even so, you may still build a route that's balanced in a way that there is always the max in-transit used. It might not be enough to let the consumer run on 100 percent, but so what? It's effectively the same as the consumer just having a lower productivity, it does not matter to a transportation agency (especially with end consumers like the bookshop)
Quote*) the overcrowding of a station with goods produced from the factory right next to it is a really stupid thing, since the goods could just be stored in the internal storage of the factory in many cases, and the "station is overcrowded" message gives the wrong impression that the player is supposed to transport everything away the factory produces, which is obviously not true. Thus, making it so a factory won't ever overcrowd the station, only fill it, would be welcomed.
QuoteI strongly suspect that must be pakset dependant then. I just made a test route over 2000x2000 tiles at 65 km/h, and it worked just fine. Sure, that was because the storage of the consumer was big enough, but why wouldn't you allow for a big storage/in-transit? If every industry in a given pakset has so low limits that the game becomes boring, maybe it's the paksets fault?
QuoteThe 'other solution' ("raise the maximum storage based on average distance from consumer to supplier") seems much more promising to me, and the change of speeds over time is already reflected in the table for speedbonuses which could be reused to change the maximum in_transit over time, thus not being too generous later on.
QuoteIf you don't want to balance it, just don't play with "just_in_time". The gameplay is the same as the proposed model: Transport away everything an industry produces. If any station overcrowds at any time, add vehicles to the route transporting stuff away from it. The only difference is that the proposed system lowers the productivity of intermediate industry, thus less stuff to carry around.
QuoteI hope now it's more understandable why I prefer the current method, and why I don't want to lose it. You all may now continue to discuss and later implement something else, but please don't get rid of the current behaviour.
Quote from: DrSuperGood on July 14, 2014, 06:09:56 PMI thought this was meant to be a transport simulator, not a supply/demand logistics simulator. The industries are meant to place their orders, and you just have to deal with the shipping, not also manage their entire supply chain including how much to send them.
QuoteThis is what the suggestion addresses. Now the goods will remain in the factory storage with only as much leaving it as the consumer requires.
QuoteStandard is meant to be easy to use and not have many complicated game mechanics. If you want complicated you should try experimental
QuoteI understand it is important to you which is why I am trying to implement it around the existing code for now. It could be given a new name like "Just in Time v2".
Quote from: Ters on July 15, 2014, 04:34:50 AMThe curse of Simutrans. Everyone sees a different game in it.
QuoteThe small values for the market was set deliberately to avoid supplying it by trains and rahter sue traucks from a central station.
QuoteI am not sure how to get a central storage facility right with you system, but I still have to playtest it (I am on a conference until Sunday).
Quote from: prissi on July 17, 2014, 10:50:34 PMThe small values for the market was set deliberately to avoid supplying it by trains and rahter sue traucks from a central station.
QuoteHow was that supposed to work?