Realtime 3.1-maybe-beta (12.2 base)

[eekee]

Thought I'd mention I just saw a cargodist- and time-related oddity while not using any time stretching. (JGR.PP, no time options selected.) I linked two existing hub stations with a new line. The train on that line didn't carry any passengers for 20-22 months. Just saying cargodist can turn up surprises. (When passengers finally showed up for that route, there were so many that 1 run paid off the train's lifetime running costs!)

I bought books on C and C++ many years ago when I began working in IT but unfortunately I never had a use for it other than to understand it. I do like C though for it's relatively simplicity (I prefer the UNIX method of thinking compared to the Microsoft one for example). In a way it's a shame I didn't stumble upon OpenTTD much sooner.

I like simplicity. I'm learning Forth; there's tons of advice on how to keep the code simple. Factor out this, factor out that, factor out if/else... I used Plan 9 from Bell Labs for years, that's a fascinating system with a lot of design tricks which keep the code relatively simple. Its C code is still a bit too much for me, but then most things are.

[SciFurz]

Thought I'd mention I just saw a cargodist- and time-related oddity while not using any time stretching. (JGR.PP, no time options selected.) I linked two existing hub stations with a new line. The train on that line didn't carry any passengers for 20-22 months. Just saying cargodist can turn up surprises. (When passengers finally showed up for that route, there were so many that 1 run paid off the train's lifetime running costs!)

That's indeed possible. I had trouble and regressions with triggering the linkgraph functions correctly but with the new process of timing I should get it to trigger normally and independent of the time factor, and probably right away.

I like simplicity. I'm learning Forth; there's tons of advice on how to keep the code simple. Factor out this, factor out that, factor out if/else... I used Plan 9 from Bell Labs for years, that's a fascinating system with a lot of design tricks which keep the code relatively simple. Its C code is still a bit too much for me, but then most things are.

I've heard about Forth and Plan 9 but never really had the time to look further into it though. As an alternative I've heard Ada is a good one and used in secure systems but also had no time to look into it.

[SciFurz]

Redid the patch with the slightly alternative method for timekeeping and added a clock to the status bar. This will be automatically disabled at the lowest time factors since it has no use at those game speeds. I only noticed it's faster at the highest time factor and I'll have to fix that later.
Production is non-lineary scaled with 1-15 times a day at each time factor step for simplicity.
Part of timetabling is modified but since there's a lot of bit functions in use I need to check it further for correct variable sizes, especially when I enable hours and minutes for the arrival and departure time..

[SciFurz]

I need to duplicate the command functions to handle 64 bit variables, but so far wrong error messages are some of the results when it comes to dispatch and thus the new patch for verion 0.31.2 will take some time.
Maybe I'll just rewrite the dispatch thing instead and bypass the whole command mess instead. I'll have to replace the add schedule through 14 bits in a vehicle integer anyway. Why was that set up in the first place?

[SciFurz]

Converted the command functions to handle 64 bit numbers but during the recoding of the timetable functions other weird behavior popped up.
Need to find out why the code loses the ability to calculate inside a string format function all of a sudden for one clock definition while the statusbar clock works fine, and just how the -expletive omitted- that string formatting output stuff works.

[SciFurz]

I did get a clock string to appear in the timetable but the time is off by several hours. I suspect it might be the way the time difference is calculated since I've seen it switch from red to black text while the truck was still lagging behind during a test. I'll write down an alternative way to calculate (individual) arrival and departure times for comparison and see if that does give me the expected results when I put it to code.
Arrival and departure in hours and minutes:

Garfingway Transport, 2066-06-23.png

(434.4 KiB) Not downloaded yet

[SciFurz]

An update for the latest JGR branch, version realtime-JGR-1.3.
Scheduled dispatch is screwed up although the standard timetabling seems to work, so I'm still figuring out why times are set to current ones as start time and why I can't add schedules. :-/ Might have to overhaul the whole thing to find out what it does exactly.
I don't think I'll need to modify variables any longer so saved games would be preserved, no guarantees though. I've tentavely begun a new test track on a 2048x1024 map again myself. Luckily, city distances of a 1000 tiles does mean racking in the cash. :-p

Beta-99, 2066-01-06.png

(610.76 KiB) Not downloaded yet

[SciFurz]

Made the same changes to the JGR patch as I did for the TTD patch and began work on the dispatch part but it's a real mess and I'll have to redo the whole thing because the commands through the callback functions simply ceased working for no apparent reason. Might as well increase the amount of parameters that can be passed through the commands since I increased one to int64 and had to modify all derived function definitions. No more bitshifting and cramming numbers into a 32 and a 64 bit integer. I thought about using the availab;e string argument in a similar way by populating and extracting it with hex values through converter functions, but that would still be just as error prone and unclear as bitshifting.

Been simply running the game for a few dys without intention to tackle the complex parts but still tweaked bits here and there, among which;
- I set loading order to no unload and no load by default and swapped the two buttons so they actually match the order text sequence (first unload, then load).
- Clicking on the buttons switches between no load/unload and load/unload by type.
- The default for all cargos button in the type list is set to no loading/no unloading. (I'll have to see if I can make it clickable as well to set all cargos with a single click, and set the list to no load/unload by default at order creation)
- Set the ISO save naming option to include the time. It saves me needing to add a character to the file name when I save more than once in a game day (which happens when running at factor 14400).

The slightly modified order list:

Beta-99, 2066_03_28-01_04.png

(691.71 KiB) Not downloaded yet

[JGR]

Made the same changes to the JGR patch as I did for the TTD patch and began work on the dispatch part but it's a real mess and I'll have to redo the whole thing because the commands through the callback functions simply ceased working for no apparent reason.

It may be useful to some of the scaling within the command handler instead of before it. This may reduce the need for overly wide command fields.
If you are not already familiar with the various internal debugging tools (debug levels, etc.), I would suggest using them as they would likely save you a lot of time trying to work out what the issue is.

Might as well increase the amount of parameters that can be passed through the commands since I increased one to int64 and had to modify all derived function definitions

The patches in the first post still appear to send uint32 values over the network.

I thought about using the availab;e string argument in a similar way by populating and extracting it with hex values through converter functions, but that would still be just as error prone and unclear as bitshifting.

There is a already binary data mode for the "text" argument, which you could use if need be.

I need to duplicate the command functions to handle 64 bit variables, but so far wrong error messages are some of the results when it comes to dispatch and thus the new patch for verion 0.31.2 will take some time.
Maybe I'll just rewrite the dispatch thing instead and bypass the whole command mess instead. I'll have to replace the add schedule through 14 bits in a vehicle integer anyway. Why was that set up in the first place?

It's 30 bits of date + 14 bits of date fract. You could just make that a 44 bit field if you're not doing date fracts.

[SciFurz]

Made the same changes to the JGR patch as I did for the TTD patch and began work on the dispatch part but it's a real mess and I'll have to redo the whole thing because the commands through the callback functions simply ceased working for no apparent reason.

It may be useful to some of the scaling within the command handler instead of before it. This may reduce the need for overly wide command fields.
If you are not already familiar with the various internal debugging tools (debug levels, etc.), I would suggest using them as they would likely save you a lot of time trying to work out what the issue is.

The basics of the modification hasn't become scaling up from the original DAY_TICK but a new maximum day length in ticks that's scaled down to speed things up. I found it easier to work from the opposite direction since it preserves tick precision for the higher time factors. Additional scaling inside functions is mostly avoided since the scaling is done by increasing time with smaller or larger steps, so it's not a thing about where the scaling takes place.
I went with an increased amount of parameters to avoid unclear bitstuffing and running out of bits with just p1 and p2 available.

Most troubles had to do with solving compiler errors so I haven't yet done much with debugging. The thing with dispatch is likely the roundabout way it works and I'm looking into cutting the redundant functions that timetabling already posesses, like setting the start time, and I'll probably begin adding debug strings to the timetabling code to see what's going on.

Might as well increase the amount of parameters that can be passed through the commands since I increased one to int64 and had to modify all derived function definitions

The patches in the first post still appear to send uint32 values over the network.

I hadn't yet gone over all the Command calls for that patch and only modified the minimum, so that should be the cause.

I thought about using the availab;e string argument in a similar way by populating and extracting it with hex values through converter functions, but that would still be just as error prone and unclear as bitshifting.

There is a already binary data mode for the "text" argument, which you could use if need be.

That's the reason why I pondered using the text string, but then I'd still have to extract various parameters from it, and possibly a real text string, and seeing as I'd have to convert int->hex->string->hex->int, it would just add more steps and it would still be as unclear as stuffing bits in one integer.

I need to duplicate the command functions to handle 64 bit variables, but so far wrong error messages are some of the results when it comes to dispatch and thus the new patch for verion 0.31.2 will take some time.
Maybe I'll just rewrite the dispatch thing instead and bypass the whole command mess instead. I'll have to replace the add schedule through 14 bits in a vehicle integer anyway. Why was that set up in the first place?

It's 30 bits of date + 14 bits of date fract. You could just make that a 44 bit field if you're not doing date fracts.

That would be possible, but all in all it would again be a patch of one part of all the code while all other time variables would still need to be changed to at least 44 bit. I just bit the bullet and went for clean and simple int64 everywhere without worrying about different bit widths and definitions all over the place.
Same with he command structure, it was some work to expand from 2 to 8 parameters all over the code, but now I can see about adding a few smaller features that I've been thinking of (which need more flags and thus more bits).

All in all I'd like to see all the complexity in the code reduced to make it easier to modify it, even if it's just bit by bit. (pun intended :-p)

[SciFurz]

For the curiously inclined, I uploaded the patch has the code I'm currently running and working on, and has plenty of junk in it from quick tests of smaller features I'd like to add, and comments at original TTD code that seems incomplete or wrong.

Biggest change is the extended command structure, and the few timetable functions that I changed from bit stuffed parameters to seperate ones so far.

[Hezkore]

So I have this server that I'd like to keep on 24/7.
At the end of the week I'll announce a winner and reset the game.
And I'd like the time in the game to move a lot slower.
Otherwise you'll be at like years 2060 after only a day.

How would I get this setup with my Linux server?
And would each client need this special version of OpenTTD as well?

[SimYouLater]

So I have this server that I'd like to keep on 24/7.
At the end of the week I'll announce a winner and reset the game.
And I'd like the time in the game to move a lot slower.
Otherwise you'll be at like years 2060 after only a day.

How would I get this setup with my Linux server?
And would each client need this special version of OpenTTD as well?

Do you have the JGR Patch Pack? If so, check the settings for "Day Length Factor" and increase it to 125. That's about 24 hours per year.

[Hezkore]

No I don't.
I've only used vanilla and I'm not familiar with patches and packs.
Does it run on the latest OpenTTD version, and does it have a terminal Debian version?

[SimYouLater]

No I don't.
I've only used vanilla and I'm not familiar with patches and packs.
Does it run on the latest OpenTTD version, and does it have a terminal Debian version?

Patch Packs are much easier than they sound. A patch is complex to apply, a pack of patches is hard to make, but getting a patch pack is basically just downloading a special version of the game compiled by someone else.

In this case, JGR's latest Patch Pack can be found HERE. Download this one first, and extract the contents to your OpenTTD install folder (the folders inside need to match up, so make sure you are overwriting existing files. If it spits out an error, try using this version for 32-bit processors before asking for help.

Once you've extracted the files, just open the game and you'll be using the JGR Patch Pack. JGR updates his Patch Pack regularly, so keep an eye on this topic for updates.

EDIT: Didn't realise you were on Debian. Try compiling the source from HERE, but other than that I can't really give any more advice.

[SciFurz]

No I don't.
I've only used vanilla and I'm not familiar with patches and packs.
Does it run on the latest OpenTTD version, and does it have a terminal Debian version?

There's no other official Debian package than the vanilla version, but if you're a little familiar with working in the termina I could type up some quick instructions on how to compile the JGR version.
Unfortunately my mobile connection is too unstable for me to upload a complete compiled version.

[Hezkore]

But would each player need this custom version as well?
In that case I'd have to compile for both Linux and Windows.
And I'd like the latest vanilla version with this patch.

[rowdog]

But would each player need this custom version as well?
In that case I'd have to compile for both Linux and Windows.
And I'd like the latest vanilla version with this patch.

Yes, the clients all need to run the same code as the server, so custom clients all around. To get vanilla + this patch, you need to get the source and apply the patch. It's rather easy as long as the patch applies cleanly. I'd suggest starting with Linux because the build is very straightforward.
https://wiki.openttd.org/Compiling_on_( ... x_and_*BSD
I don't do windows so I can only recommend reading the docs.
https://wiki.openttd.org/Category:Compiling_OpenTTD

[SciFurz]

But would each player need this custom version as well?
In that case I'd have to compile for both Linux and Windows.
And I'd like the latest vanilla version with this patch.

Everyone does need the same version, yes. It's not possible to mix versions because of different features in each version.
The Windows version is available in JGR's thread for download (see SimYouLater's links) so you only need to compile the Linux version.
JGR's patch pack is extensive so it's not quite the same as vanilla version with a patch, I believe some things from the latest vanilla version haven't been imported in the patch pack of the stable version because it needs more modifications to make it work, but I wouldn't worry about that, just go with the patch pack because it has way more interesting features than vanilla.
(if you mean my realtime patch, then it does need compiling for Windows but I don't recommend running this because it still not completely finished)

[SciFurz]

Finished replacing all DoCommand call variables to the CommandContainer struct and next is doing the same for all the undefined linker errors thrown by the compiler, mostly all the callback functions.
Next patch update will take a while as I change a few files a day, but after this there should no longer be a limit on flags or other bit limited variables. Well, as long as they're grouped in int64 space anyway.

Made some notes in the code where I found unused or largely useless functions and made one to replace all the seperate playsound functions with a single one. I hadn't expected to see so much redundant code.