search

TommyC81 / TPF2-LineManager

A mod for TPF2 (Transport Fever 2) to manage vehicle numbers on lines.
GNU General Public License v3.0
6 stars 2 forks source link

Figured out how to do buttons, but can't get them to actually do anything #6

Closed RusteyBucket closed 2 years ago

RusteyBucket commented 2 years ago

Maybe you can get them to actually do what they're supposed to do: setDebugLevel, setVerbosity and make (R) lines the default with the tag (R) applying the normal rules, haven't found an elegant way to do that yet...

TommyC81 commented 2 years ago

Will be busy today, will look later.

In the meanwhile, I found this mod on the workshop that seems to integrate some kind of UI similar to what we're looking for: https://steamcommunity.com/workshop/filedetails/?id=2692112427

You can see in the associated discussions I've already contacted the mod author to ask for source and permission. Something to investigate further and either use or get inspiration from (with appropriate attribution).

On Fri, Dec 31, 2021, 16:45 Rustey @.***> wrote:

Maybe you can get them to actually do what they're supposed to do: setDebugLevel, setVerbosity and make (R) lines the default with the tag (R) applying the normal rules, haven't found an elegant way to do that yet...

You can view, comment on, or merge this pull request online at:

https://github.com/TommyC81/TPF2-LineManager/pull/6 Commit Summary

File Changes

(3 files https://github.com/TommyC81/TPF2-LineManager/pull/6/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/TommyC81/TPF2-LineManager/pull/6, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOQ3XHPLVVVEIH5FY3VYDLUTWQWLANCNFSM5LBIB7PA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

RusteyBucket commented 2 years ago

Just thought to wish you a happy new year a little early where I am

TommyC81 commented 2 years ago

Thanks, and same to you - happy new year! We're already well into the new year... :-)

On Sat, Jan 1, 2022, 02:25 Rustey @.***> wrote:

Just thought to wish you a happy new year a little early where I am

— Reply to this email directly, view it on GitHub https://github.com/TommyC81/TPF2-LineManager/pull/6#issuecomment-1003459944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOQ3XD2RYIONNOJVFETUJDUTYUWTANCNFSM5LBIB7PA . You are receiving this because you commented.Message ID: @.***>

RusteyBucket commented 2 years ago

Improved the mode selector to include a default mode

TommyC81 commented 2 years ago

I've done some testing, running the same (big) game with default rules, rate rules and an additional "conservative" version of rate rules. The default rules come out on top every time (in terms of profit), mostly because it keeps usage closer to optimal and avoids self-oscillating addition/removal of vehicles (this increases expenses significantly!!!).

Without being too technical, rate rules increased revenue by 10-15% but also increased expenses by ~30+% (~20-25% with my "conservative" version of the rate rules) effectively reducing actual profit by 80-90%.

Rate rules will make sense for industry/goods, where the demand is mostly constant and rate has to be equal or better than the demand. Relatively easy stuff.

It's much more tricky with passengers as there will generally be more options on routes, and demand along a multi-station route is much more likely to be unbalanced, and demand between routes will fluctuate over time (a passenger can sometimes/often get to a destination via many different routes).

I'm curious to hear your thoughts on how a "peak" rule set could be implemented (for passengers). My guess is that the rate rules will probably most closely align with the expected outcome (potentially using the slightly more conservative version I've been testing, or some variation thereof).

TommyC81 commented 2 years ago

@RusteyBucket I've created an initial setup for creating a GUI, from here on it's just a matter of creating the appropriate interface (and callbacks etc.) for the settings that are available.

Keep it simple for now; just toggling debugging on/off, including verbosity level (only true/false for now).

Keep it simple enough so we can get this initial stuff over the line before expanding further (i.e. avoid feature creep). I'd like to merge this PR as soon as possible before further work on other functionality - one step at a time.

RusteyBucket commented 2 years ago

I've done some testing, running the same (big) game with default rules, rate rules and an additional "conservative" version of rate rules. The default rules come out on top every time (in terms of profit), mostly because it keeps usage closer to optimal and avoids self-oscillating addition/removal of vehicles (this increases expenses significantly!!!).

Without being too technical, rate rules increased revenue by 10-15% but also increased expenses by ~30+% (~20-25% with my "conservative" version of the rate rules) effectively reducing actual profit by 80-90%.

Rate rules will make sense for industry/goods, where the demand is mostly constant and rate has to be equal or better than the demand. Relatively easy stuff.

It's much more tricky with passengers as there will generally be more options on routes, and demand along a multi-station route is much more likely to be unbalanced, and demand between routes will fluctuate over time (a passenger can sometimes/often get to a destination via many different routes).

I'm curious to hear your thoughts on how a "peak" rule set could be implemented (for passengers). My guess is that the rate rules will probably most closely align with the expected outcome (potentially using the slightly more conservative version I've been testing, or some variation thereof).

About the additional rules: My personal play style has Pax kinda divided into two general line classes: feeder lines and profit lines. Feeder lines are the local services that connect as much of the population as possible, which I typically just upgrade to trams and run them at a frequency in the 50-60s range and profit lines connect towns, typically by electrified rail and ship for simplicity aiming for a frequency rounded to 3 min or a plane, bus or tram line... Overall, this usually results in my roads operating at a slight loss for capacity, so the big capacity earners with trains and ships more than make up for it. Thus I experimented with a rate mode that would operate my locals in a way to not get rising passenger numbers on roadside stations, giving my trains all the passengers they can get, which is why I put in a condition that if your line is running close to capacity, you need more vehicles and if the line isn't transporting all the demand, it's not working as intended either, and since this kind of locals typically make up around 80% of my pax lines and close to 100% of supported lines, I wanted an easy way to choose that as a default... But seeing that the (R) mode is pretty much suited for cargo operations, I thought, I'd suggest a peak demand mode that scales the line to have so many vehicles that no station ends up with more than one vehicle worth of waiting customers at a time, but again with quite a tolerance in terms of performance until a vehicle gets sold...

RusteyBucket commented 2 years ago

In short, the loss in profit is pretty much a designed side effect of scaling to a capacity that transports everyone

TommyC81 commented 2 years ago

Ah, I see what you're aiming for. From the top of my head, it should be possible to iterate through the stations of a "peak line" to determine if there's more than a vehicles worth of passengers waiting. This will be a bit more involved than just checking the general line stats to determine. I suspect that if rate exceeds demand, then there will possibly not be many passengers waiting anyway (effectively achieving the same, but with less complexity) - this seems like an interesting study case! :-)

How has your experience been using the "rate rules" so far?

A critical item will be to minimizes "oscillations" (ie frequent adding/removal of vehicles) as much as possible. This can potentially be done already by simply averaging out rate/demand to avoid reactions to temporary peaks/throughs - in fact, I might try this already now (specifically for "rate rule" lines, but possibly for all lines).

On Sun, Jan 2, 2022, 18:27 Rustey @.***> wrote:

In short, the loss in profit is pretty much a designed side effect of scaling to a capacity that transports everyone

— Reply to this email directly, view it on GitHub https://github.com/TommyC81/TPF2-LineManager/pull/6#issuecomment-1003724211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOQ3XCI3PQ7I46VMJMQTL3UUBOFLANCNFSM5LBIB7PA . You are receiving this because you commented.Message ID: @.***>

TommyC81 commented 2 years ago

Just a note to highlight that the GUI I've drafted up quickly doesn't work as expected yet. I left a comment in the code, let me know if you can figure it out. I'm out of time at the moment, but will hopefully have time to look further before the end of the week.

TommyC81 commented 2 years ago

I don't think I'll have time to finish my GUI attempts just yet, I might pull that code out and save it for later.

With regards to the built-in settings you've been working on, this repository might provide some hints on how to pull it off, check it out: https://github.com/MrWolfZ/transport-fever-2-natural-town-growth

RusteyBucket commented 2 years ago

Haven't gotten around to playing in the last couple of days, though my brief experience with the rate rules is that it's oscillating a darn lot, which is why I left the criteria of the (D) rules for selling vehicles for the most part, adjusting the thresholds down though...

TommyC81 commented 2 years ago

No doubt, that is the primary challenge when it comes to the rules - eliminating oscillations, or reduce them as far as practicable, whilst maintaining an appropriate level of efficiency. I've gone through many, many iterations of the rules to land at the current ones, including adjusting the number of samples etc. to use.

At least you have a good foundation for testing further, let me know if you discover anything interesting!

On Tue, Jan 4, 2022, 20:55 Rustey @.***> wrote:

Haven't gotten around to playing in the last couple of days, though my brief experience with the rate rules is that it's oscillating a darn lot, which is why I left the criteria of the (D) rules for selling vehicles for the most part, adjusting the thresholds down though...

— Reply to this email directly, view it on GitHub https://github.com/TommyC81/TPF2-LineManager/pull/6#issuecomment-1004995458, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOQ3XCNIUPKGRDTIJANKXLUUMQ6HANCNFSM5LBIB7PA . You are receiving this because you commented.Message ID: @.***>

RusteyBucket commented 2 years ago

Will do

TommyC81 commented 2 years ago

Figured out my error with regards to getting the in-game GUI to work (has to do with engine and GUI running in different threads, need to send scriptevents to communicate, duh!) I will clean things up and merge into main later today. I will close this PR then.

The in-game GUI will be much more flexible compared to the load time settings. Build on that going forward.

TommyC81 commented 2 years ago

I've now updated the main branch with an amalgation of the changes prepared here (rather than trying to clean up the commit history, I made a fresh/clean commit). I will close this PR, and suggest you restart a fresh one from the main branch (make sure to "Fetch and merge (from main)" on your fork here on Github. You may have to manually transpose code improvements you've been working on privately. Shouldn't be much of an issue.