Recent Posts

Pages: [1] 2 3 4 ... 10
If nothing else, at least it allows me to type in what I want, rather than having to adjust the number by clicking umpteen times. And by starting from speed, it could remove the doubt as to which is correct when multiple percentages give the same speed.
Extension Requests / Change how Speedbonus is displayed in Goods Window.
« Last post by Leartin on Today at 06:24:00 AM »
This was already mentioned once in this thread:
It also comes up in the German forums, so let's make a proper request:

I don't think speedbonus needs to be displayed as a percentage in the game. It should not matter to the player whether they can reach 100%, only whether they can make profit with their vehicles. As such, it would make sense if you would not choose the bonus or malus, but a vehicle type and it's speed to see how much you can earn with each good. I made a bad mockup with paint of what that could look like.

Internally, the logic stays exactly the same. Choosing vehicle and speed would be exactly the same as if you adjust the percentage in the current version until that speed is shown for that vehicle type.
Extension Requests / Re: Server password reset in game time not real time
« Last post by prissi on Today at 03:43:54 AM »
No, it is not. Even more, a finance check can be done without changing to the player in question.
Splendid, thank you.
Simutrans Extended Discussion / Re: Fare Prices
« Last post by HarrierST on Today at 12:28:38 AM »
Generally faster modes of transport will cost more to run so only be suitable for higher paying passengers.

The Concord might only carry Very High passengers to make a profit.

Just a little anecdote.

During the first year of flights BA were only charging about £3000 per ticket and were losing millions of pounds. They were seriously thinking of scrapping it. So they appointed a senior pilot (who had bombarded the board with suggestions during the first year)  to do a review as to why they were losing money. He had a year to turn it around.

He hired a marketing company to speak to passengers about the flights and what they thought it cost.

Suprisingly most people thought it cost between £15,000 and £25,000. They never booked the tickets - their companies did.

The marketing companies solution - "advertise how little (relatively)  it actually costs". To get more passengers.

The senior pilots solution - ignore  the marketing companies solution and charge them what they think it costs.

Within a year Concorde was in profit.
Can you recommend any good resources for learning about this more generally?
There really is not much to learn...

For optimum performance all memory reads should be aligned to an address that is a multiple of the read size. For example a 32bit (4 byte) value will be aligned to a 4 byte address (effectively ignoring the 2 least significant bits of the address number). To assure this applies to structs/classes which can be turned into an array, the alignment of a struct/class is the biggest alignment requirement of any of its members.

Compilers generally order struct/class members in the order they are declared. If one declares a smaller field, eg 1 byte, followed by a larger field, eg 4 bytes, then to fulfill the 4 byte alignment requirement 3 bytes of padding are added between the 1 byte and 4 byte member.

As a general rule of thumb try to order members from largest alignment requirement to smallest alignment requirement as this avoids the use of padding. Also due to the alignment requirement of a struct/class it might be impossible to avoid padding, eg a 8 byte and 1 byte member struct will always allocate 16 bytes no matter the order of the members as either 7 bytes of padding will be between the members or at the end of the struct.
I should note that the server is temporarily offline for a memory upgrade.
The unresolved external symbol errors suggest that you do not have the correct bzip libraries specified; can you check whether you have changed the settings for these in the "Debug (open GL)" 64-bit configuration to point to the correct (64-bit) bzip libraries, too?
Splendid, thank you for confirming.
You know swapping waiting_time_shift and spacing_shift might save as much as 1 byte currently right? There is an implicit 1 byte of padding between them to keep spacing_shift 16bit aligned. If this effects overall struct size I do not know, that padding might just be deferred to the end to satisfy other alignment requirements.

Interesting - thank you. I have not really looked much into data member alignment/padding, so I am not entirely sure how this works. I have made this alteration on the master branch, so it should be implemented in the next nightly build.

Can you recommend any good resources for learning about this more generally?

I personally would recommend getting the existing scheduling system stable before looking into extending it. If one cannot even get convoys leaving at a regular rate reliably what hope is there that convoy recombination will work?

Is this in reference to the specific bug that you reported this morning? I had been considering the scheduling in detail before this had been reported this issue, and thought it preferable to complete the outline design process for this specific aspect without interruption with different Simutrans-Extended tasks that were non-trivial in complexity which might affect my ability to remember what I had considered so far.

One should not need to explicitly define a depot for a convoy to be serviced. If none is defined then it should automatically seek out one when required. This is mostly for road vehicles where there might be a depot in every city (think of it as a normal garrage) so one really does not care which it ends up using.

This is intended to be a thread considering very precisely how the implementation is to work. At present, as discussed, a schedule entry is primarily defined by its location, and whether or not it is an entry for a depot can be inferred from (and only from) that location. The change that you suggest would require a fundamental change to the way in which this scheduling system works, but you do not give any indication as to precisely how such a change should be implemented, which is what is needed in a discussion of this nature. Do you have any idea how such a system would actually work at algorithm level?

The idea is with the system described here that it should be possible to specify several different depots on a vehicle's schedule: the vehicle would only call at any of those depots if some conditions (not specified in the schedule itself) were satisfied, so the functionality to which you refer should be able to be achieved within the system described in any event.

I still fail to see why servicing and overhaul is a critical balance feature. Much of the costs involved can be averaged out to monthly/running costs. This is more adding of complexity for something fundamentally simple. Many people will agree how annoying it is sending convoys to depots all the time from OpenTTD. It is impossible enough to maintain regular services ATM, let alone when suddenly all your convoys decide to go to a depot, or go in pairs due to some bug... It probably is a nice feature in the long run but critical?

This is really not the thread on which to discuss that. This has been discussed in detail in this thread from April last year, on which I note that you have not participated.

Now that 64bit builds are used the memory usage is not that important. What is important is how regularly the memory is used. One could have 30 bytes of stuff per entry that is only occasionally used under rare conditions and it will not really effect performance. For mutually exclusive fields one can use a union to share the storage space which potentially saves memory.

Schedules are accessed fairly frequently, I think - but perhaps memory parsimony is not the most important issue for this specific aspect. One still needs to be reasonably efficient, however.
Pages: [1] 2 3 4 ... 10