Recent Posts

Pages: [1] 2 3 4 ... 10
Indeed much progress was lost. However I have already put much effort after this.
Tracking such an error is very difficult. Something must be unsafely using a pointer. The reason it is hard to reproduce is it will only crash during a save/load cycle if it has sufficiently corrupted the heap memory management structures. If it corrupts an object it will not cause a crash. This might even explain the out of sync errors, as such corruption will cause an out of sync if it overwrites certain object state instead of the heap memory management structures.

Applying memory safe guards to catch what is responsible might not even be viable due to the complexity of the server game, the overhead might be too much for it.
Most of last nights progress was lost. If not even the day before... And it saved like a dozen times during then. Like 15 lines I set up were removed.

Here (link may be removed in the future) is a save from the server yesterday, which is significantly more progressed than the current one.
I still seem to be getting this heap corruption occasionally (it occurs locally as well as on the server), although I am unable to reproduce it reliably enough even to begin trying to find a fix for it. It always seems to occur in the same place in the code, however. Oddly, it seems to happen several times in a row with the same saved game, but then, when I specifically go to try to reproduce it, it never seems to happen again.
I have just run a general CPU performance test on the server (albeit this may not be as accurate as it might be on account of the server running Simutrans-Extended in the background whilst this test was performed).

I get the following results:

Code: [Select]

Maximum prime number checked in CPU test: 20000

Test execution summary:
    total time:                          26.2488s
    total number of events:              10000
    total time taken by event execution: 26.2445
    per-request statistics:
         min:                                  2.48ms
         avg:                                  2.62ms
         max:                                 11.43ms
         approx.  95 percentile:               3.17ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   26.2445/0.00
Thank you for the report. Can I ask whether this affects only the display or does it actually affect how the convoy behaves?
Excellent, that is very helpful, thank you.
Thank you for your work on this. I am in the process of reviewing this now. I have merged this and pushed it to the journey-time-measurement-2 branch of my Github repository.

I had to change the saving/loading code as I had incremented the minor save version number for other purposes to 1 already, so this needed to be set to 2. Also, I had to amend the code to take account of the fact that the minor save number is reset to 0 whenever the major number is incremented, which requires checking that the version is either exactly 13 and with a revision of exactly or greater than 2, or the version is exactly or greater than 14. I should be grateful if you could bear this in mind when writing any future code.

I also notice that we have some new .cc files added, but they do not appear in the makefile: it is important that references to these files are added to the makefile, or else compilation using GCC and MinGW32 will fail. I should be grateful if you could add these to the makefile.

Further, I notice that there are some additional translation texts: these will need a .dat file in order to be added to Simutranslator to allow people to translate these new texts into various languages. On the topic of the text, I suspect that "unidirectional" would be a clearer opposite to "bidirectional" than "normal direction".

Additionally, I notice that you changed:

Code: [Select]


Code: [Select]

and similarly

Code: [Select]


Code: [Select]

May I ask what the intention of this change was?

One issue that I notice is that, when one is looking at another player's convoy, the timing history button is not greyed out, but clicking it has no effect. This ought to be greyed out, I think.

Onto some more positive points: the performance profiler shows that there is no noticeable performance impact from this patch, which is very good. Also, the feature seems to be very useful, and also very usable: this is definitely an improvement on the first attempt. I daresay that this will significantly enhance people's abilities to plan their networks - this is a very useful feature.

If you are able to fix the issues that I describe above, I shall be happy to incorporate this.
Ves - would you be able to look into this? That would be very helpful so that I can focus on other issues. Thank you in advance.
Pages: [1] 2 3 4 ... 10