Started by neroden, May 27, 2013, 03:32:08 PM
0 Members and 1 Guest are viewing this topic.
Quote from: jamespetts on May 27, 2013, 09:28:40 PMIn the current system, the actual movement speed of vehicles on the screen in real time is constant, but the relationship between real time and game time varies. This has been implemented with great care,
Quoteand the relationships have been set up precisely to ensure that physics, timings, reported distances, revenues, costs, and the generation of passengers and freight are constant in their relationship with in-game time and distance.
QuoteThe only effect of altering the meters per tile would be to make the speed at which vehicles appear to move around in the game window variable rather than fixed, which I do not think would be a happy side-effect.
Quote from: jamespetts on May 28, 2013, 01:01:47 AMIt's always always good when people get passionate about Simutrans - it's such a lovely hobby
QuotePerhaps we could start with a list of the known bugs that are due to this feature and would not occur if things were done differently?
QuoteI am not aware of any such bugs at present (Bernd integrated the meters per tile setting into his physics code some time ago, which works fine so far as my tests show). All of the things to which you refer in your first post are indeed adjusted for meters per tile.
QuoteCan you elaborate a little on how the default milliseconds per tick thing would work, especially in a network game?
QuoteHow would this be different to the faster and slower keys (which are intentionally disabled in network mode)?
QuoteWould this potentially affect the computational intensity of the game run at a higher meters per tile setting to take it beyond what can work effectively on a large map in a network game?
Quote from: Carl on May 28, 2013, 06:49:02 AMI'm having a hard time seeing what's supposed to be "broken" here, beyond flat-out assertions that the feature has to change. Acceleration, calculation of journey times, etc, are not broken in recent versions, despite your assertions. In fact, they're working impressively well.
QuoteIf there are errors in calculation, they are insignificant enough not to matter.
QuoteSo why "fix" them?
QuoteI don't know why anyone would ever implement it by rotating the world. It makes it impossible to rotate network games.
Quote from: neroden on May 28, 2013, 05:14:34 PMI'm still finding lots of breakage in recorded journey/waiting times, but it's very hard to pin down because it's subtle breakage. The "fastest route" algorithm is not routinely sending passengers on the fastest route, but tracking down exactly why is very hard. It's made much harder by the unreadability of the journey time calculations, which is because they're all doctored with the meters_per_tile nonsense.
Quote from: jamespetts on May 29, 2013, 12:12:35 AMLacking time to respond fully at present, but a brief response is better than nothing: this seems rather the crux of things - if there really are bugs, how best to deal with the matter would be a considerably higher priority.
QuoteAdding variability to the vehicle movement speed does not seem in principle to make this any simpler:
QuoteIf the suggestion is that this is implemented in a different place in the code, does it not follow that it is possible to use that different implementation to retain the current fixed speed of vehicle movement by automatically pegging that movement speed against the distance per tile setting?
QuoteIn other words, is a conceptual change of the relationship between meters per tile and timing really needed here,
Quoteor will an implementation change suffice?
QuoteIs the current system different in principle to your proposed system with the single modification that there is a fixed relationship between meters per tile and the movement speed?
QuoteWhat is the nature of the behaviour that you have observed that gives you to think that there might be bugs?
QuoteYou're asking a big effort and to throw away something that (at least) seems to work and that have cost a lot of time to develop. It's natural that people involved in it want to be very sure that it is worth the change.
QuoteThe confusion between distance and time makes it impossible to implement "once and only once" here.
Quote from: jamespetts on May 31, 2013, 06:01:27 PMIncidentally, if this is to be done, then it had better be done after the release of 11.0, as it would not, I do not think, be sensible to have such a major change implemented so soon before a release: I hope to release 11.0 after I have fixed the Linux server bug, the performance issue and the remaining reported bugs with freight station coverage.
QuoteIn terms of the benefits, am I correct in understanding that the reason that this is proposed is to improve the maintainability and readability of the code, not because there are any known bugs associated with the feature itself?
QuoteCan you elaborate a little on how the current system has hampered you tracking down the bugs in very long distance transport? If the numbers that you are getting out of variables are not meaningful in themselves, could you not just set up some temporary code, as I do in that situation, to translate the values into something readable so that they make sense in a debugger
Quoteperhaps this does not reflect well on my coding ability (I am, after all, somebody with no professional coding background, and learned C++ specifically for Experimental back in 2009), but I have not noticed that the meters per tile feature is unusual in this respect:
QuoteWhat sort of rebalancing of a pakset that has so far been balanced to use the existing system would be needed were your suggested change implemented?
QuoteIf there is to be less computational intensity by using larger numbers rather than computing more often, does this mean that vehicle movement will become less smooth at higher (lower?) meters per tile settings?
Quote from: neroden on April 01, 2023, 07:54:51 AMHey. This is still a very, very good idea, and it's still viable. It also looks like it hasn't been fixed yet. Unfortunately health problems struck and meant I was unable to work on Simutrans for 10 years, and am still unable to work on it this year. Maybe next year, if you're willing to have it fixed.(To answer your other question, no, eliminating all instances of times not adjusted by meters_per_tile would be much, much worse, and would involve the same amount of work.)
Quote from: neroden on April 24, 2023, 03:46:28 PMAll right. It's going to take me a long time to get to this anyway, since I have *massive* real-life obligations right now which will continue for more than a year. I'm only working on little features in the corners right now in my not-extensive free time.Mathematically, the new system should be almost completely transparent to the pakset writers and for balancing purposes. There would be a couple of top-level flag switches to handle the transition (swapping "real_meters_per_tile" into the simuconf.tab instead of "meters_per_tile") and then the idea is that it all works the same from the point of view of the pakset creator and player.There will be internal computational differences, which means you'd want to stop a server running "meters_per_tile" and restart it running "real_meters_per_tile" to do the update -- but they should amount to variations in roundoff error. They shouldn't have *any* impact on pak balancing or gameplay.The process might, however, uncover latent pre-existing bugs which would be fixed, which *would* have an impact on pak balancing and gameplay.