Moderator: OpenTTD Developers
The major change is the (nearly) complete replacement of the Docommand variable strings (tile, p1, p2, flags, CMD_xx) to the already available CommandContainer struct, which I have expanded to include variables used in all the DoCommand functions, and increased p1 and p2 to range from p1 to p12 (the highest count of bitstuffed parameters I've seen so far at a signal function).
Only a few p1 and p2 parameters have been changed in timetable functions, the rest are still the original bitstuffed ones. I'll only modify those that I need to for the realtime implementation for now, or for the extra features I add.
Major change is I switched function calls of DoCommand so that the call with variables gets translated to the CommandContainer, and the main function is being supplied that one instead of the other way around. This way I won't have to replace all function calls in the code while still getting the benefit of dynamic way to increase parameters when they're needed. Wish I had thought of that before I replaced all calls in the JGR branch, but then I'd want to replace those anyway in the end. There's also a good chance I'll simply start with clean code again and manually modify it from the diff file like I did before to sort of clean up the cruft that has been building up.
The patch looked savegame compatible when I only patched the saveload files and the variables, but after patching the rest of the code the intro game no longer loaded. Threw in some debug lines but so far all I can see is something's not matching up during the loading of the settings chunk. I can't tell which setting triggers it until I find out where exactly the sequence of loading settings is done (doesn't seem to follow the sequence of arrays in the file) and if and where I can squeeze in a line to check per setting. Otherwise maybe I'll try splitting the whole chunk in smaller pieces to narrow the search.
The DoCommand functions are switched around and an extra method added to run Cmd functions with either variables or the container. Existing functions wont have to be modified unless there's a need for extra variables or refactoring to make the code more readable. An example of that is in the timetable functions where 64 bit time is implemented and a few processes have been simplified for clarity (removed all bit stuffed elements).
I'm going to use the same method for the next JGR patch, which was the experimental basis for the nice method now used in the vanilla patch.
As an extra feature, enabled timetable arrival and departure times permanently. Why not display them when the order times are filled in anyway?
With this it's slowly becoming bug hunting time, especially to find out why loading settings from older games goes tits up.
So, the vanilla TTD patch is now savegame compatible.
The patch seems savegame compatible now and fully functional, apart from one bug.
Using ctrl to link stations crashes the game because the struct with the data is lost at the OnClick function call. I haven't found the cause yet and a test change in calling the station function prevented placing road stations all together. Other stations can still be placed so I think I'll begin with unifying station placement code as much as possible to find out where the differences lie.
Workaround is to temporarily place rail station tiles to where the linked station is to be placed, then removing them again.
Haven't found other bugs during my latest test game, so it seems the whole code conversion to CommandContainers is a success. Increasing the number of any objects or flags should be easy now.
The prototype; 4 axle, 50 t load, maximum speed 120km/h, based of off the 35t stake wagon. The wood train suddenly looks so much better (no, no idea why this image isn't set inline). Made the graphics fit with direction, matched wheel style with the locomotives. The empty version is complete but I still have to draw the diagonal sprites with cargo.
I might modify the other stake wagons when I'm done with this one since the cargo label for metal needs correction anyway. Adding other cargo sprites like crates is an option.
Couldn't refrain from trying a few more things and ended up adding two more colour variations to the coil wagon, a crate variation of the large stake wagon, and tweaked the wheels on the Eass and tankers wagons. Also activated the brown version to the random livery of the Eass.
Looking at the last screenshot, I realised a lot more tweaking is needed to fit the wagons correctly to the locomotives. Buffers don't match, length is incorrect, and I wonder if the wagons can be changed without things getting real ugly.
Modified wagon length properties (causing a possible crash warning in OpenTTD but no problems so far), and redid the sideviews while keeping to the original design as much as possible.
Made a tiny multi-purpose locomotive which can refit to any cargo, including passengers. It'll come in handy when I'm experimenting. Named it Mier (Ant) because it can do anything, and a network with lots of these crawling around will look like an ant hill.
Tweaked more wagons, added an extra large livestock wagon for 50 cattle, and replaced the second green livery of the Takkis compost wagon with the orangy VAM potgrond livery. There's also a green striped one which I might add later.
Added food and non-food tanker copies of the existing ones, which will prevent refitting between chemical cargo and food cargo, and doubled capacity of the largest one to 50000 liters. Have some ideas for liveries for these, which will likely take some effort to draw.
Made one new livery for a new tanker, which should be obvious as to what cargo it carries.
A preview: For the curious, here's the grf; Remember, not all tilesets are completely done, but it should give an idea of what I have in mind. When loading a game that already has the Dutch trainset in use, the warnings can be resolved by replacing the coil, VAM, and Eass wagons, but I noticed sometimes a wagon isn't available in my test game. A new game will show all as it's supposed to.
Unless I see other interesting wagons or need a different version of an existing one, I'll only be finishing the rest of the images later, maybe adding one or two liveries to wagons that have only one to make a long train look more interesting.
Now how come images here are sometimes inline, and sometimes only available as download?
- (238.37 KiB) Not downloaded yet
Inline images have a maximum with of 800 pixels and a maximum height of 600 pixels. If it is larger than that in either direction then it's not available inline.
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | RoadTypes?
Ahh, indeed, two were larger. Thanks!kamnet wrote: ↑09 Dec 2019 08:25Inline images have a maximum with of 800 pixels and a maximum height of 600 pixels. If it is larger than that in either direction then it's not available inline.
Maybe it was in the previous version, but I thought I had uploaded a larger one before which showed up fine. I'll have to scale as well next time then.
These are the sizes which will correctly display a one pixel gap between rail objects at the diagonal and front/rear view. It clearly shows the smallest size has such a short diagonal view, it's practically useless. I redid my Mier diesel unit at 20 pixel length to make it fit, and created a six axle Big Ant version. Changed specs to maximum axle load for respectively class A and D as well, giving them a load capacity of 33 and 84 tonnes. .
Pondering about what configurations to make for each wagon type before I recreate new sets with existing specs and fictional ones from light to heavy. A heavy eight axle raw mineral wagon with a load of 135 tonnes (including wagon) for class D might be something. It'll take a few locs to pull a line of these things away from a mine.
The five templates files if anyone wants to use them:
Squid Ate FISH (ships) (Released) | CHIPS Has Improved Players' Stations (Finished)
Iron Horse (trains, released) | Termite (tracks for Iron Horse, released) | Busy Bee (game script, released)
Road Hog (road vehicles, released)
More/better risk of losing money would add another need to keep an eye on the game and thus interesting, just like disasters do. There is a yearly cost for vehicles, but there is no cost of fuel. A plane going from one airport to the other would still generate income with a single passenger, while in reality there should be a cost based on distance and fuel consumption of the plane. Maybe I can add something based on the weight of the vehicle and force the need to have at least half the vehicle filled to break even.
A rule to cargodist to choose transport method depending on how much a passenger would have to pay would be nice. Few choose the expensive plane, most take the cheaper and slower train.
Another thing I thought about recently was fluctuating production. According to the game mechanics documentation, the chance of a change in production is only 4.5% each month. Raising that to a lot more, even up to 100%, means it's another thing to keep up with (cargo overflow at a station with rating decline, losses due to transport overcapacity). Hmm, another thing to twiddle in my patch and see what happens.
Users browsing this forum: No registered users and 3 guests