2.0.1 alpha / 2.5 beta discussion

[Patchman]

Everything is handled automatically by the grfs because writing a GUI is too much work for me. This also means that currently the TTD default vehicles won't get autoreplaced either.

It is certainly possible, though not trivial, to write callbacks that override the default selection in some cases, however.

[krtaylor]

No, I understand it's too hard to have a GUI in the game. But could the Patch switch itself be expanded into four, or accept bit-switches to denote which vehicle types it should apply to?

[SHADOW-XIII]

I would prefer option to edit ttdpatch.cfg switches directly in TTDPatch even if the game would need to be restarted to apply them

[Patchman]

No, I understand it's too hard to have a GUI in the game. But could the Patch switch itself be expanded into four, or accept bit-switches to denote which vehicle types it should apply to?

There's really no need. If the sets handle the replacement scheme as I have done (by putting it in a separate .grf file), you can just turn it off if you don't want it.

[krtaylor]

Aha. Yep, that works. I'm not a big fan of lotsa little GRF files, but I see your point.

Wonder how that would work with George's Long Vehicles (where I'd want them the most), given that each vehicle is already in its own file. Maybe via the AI Manager GRF, which can see what else is there?

[Patchman]

I'll leave that to George to sort out. I have no desire to try and work it out for myself for this convoluted mess...

[George]

I'll leave that to George to sort out. I have no desire to try and work it out for myself for this convoluted mess...

Could you give a small example for autoreplace of truck with ID 20 to truck with ID 14?

[DaleStan]

Something like this, I believe:

Code: Select all

0*0 01 01 01 00
0*0 02 01 00 01 01 00 00 00 00
0*0 02 01 01 81 10 00 FF 01 14 FF 00 00 00 00
0*0 02 01 02 81 B6 00 FF 01 01 00 20 20 00 00
0*0 02 01 03 81 0C 00 FF 01 02 00 34 34 00 00
0*0 03 01 00 00 03 00

NFORenum doesn't currently approve of variable 10 there; I'll fix that soon.

[Patchman]

The source for the DBSetXL autoreplace scheme is at http://www.ttdpatch.net/src/newgrfdemo/dbsetxl_rep.nfo - have you looked at it yet?

It's generally not a good idea to specify only one vehicle for replacement, in case the given vehicle has too low reliability in the game (since it's random).

Basically, you want to define "upgrade lines" of IDs that are compatible with each other. For instance, you could have a coal line, in which you list all trucks that carry coal in order of best trucks first. Then you could branch simply based on the current cargo type and use the respective line.

You may want to wait for a64, though. I forgot to check the refittability in a63, so if you accidentally specify the wrong ID it'll carry the wrong cargo type. In a64 it'll be ignored if it's not refittable to the right cargo (for non-trains at least).

Anyway, when you define the list, you must absolutely make sure that you always include the current ID (that's being upgraded) in the right place, otherwise the patch may downgrade vehicles. This is because it considers all vehicles that are in the list before the current one to be better, and all vehicles after it to be worse. If the vehicle doesn't appear in the list, all vehicles would be better.

[George]

The source for the DBSetXL autoreplace scheme is at http://www.ttdpatch.net/src/newgrfdemo/dbsetxl_rep.nfo - have you looked at it yet?

No. I've asked a SMALL example to understand, how much efforts do I need to realise it and rank it in the to-do list.

It's generally not a good idea to specify only one vehicle for replacement, in case the given vehicle has too low reliability in the game (since it's random).
Basically, you want to define "upgrade lines" of IDs that are compatible with each other. For instance, you could have a coal line, in which you list all trucks that carry coal in order of best trucks first. Then you could branch simply based on the current cargo type and use the respective line.

For thr LVs set I have only 3 lines
- cargo trucks (refitable to everything)
- tourist buses (tourists)
- buses (passengers)

You may want to wait for a64, though. I forgot to check the refittability in a63, so if you accidentally specify the wrong ID it'll carry the wrong cargo type. In a64 it'll be ignored if it's not refittable to the right cargo (for non-trains at least).
Anyway, when you define the list, you must absolutely make sure that you always include the current ID (that's being upgraded) in the right place, otherwise the patch may downgrade vehicles. This is because it considers all vehicles that are in the list before the current one to be better, and all vehicles after it to be worse. If the vehicle doesn't appear in the list, all vehicles would be better.

Regardless the price or not? If the new model is cheaper, would it replace old one?

[Patchman]

The source for the DBSetXL autoreplace scheme is at http://www.ttdpatch.net/src/newgrfdemo/dbsetxl_rep.nfo - have you looked at it yet?

No. I've asked a SMALL example to understand, how much efforts do I need to realise it and rank it in the to-do list.

Well, a small example wouldn't really be useful, though. But what DaleStan posted should work.

For instance, you could have a coal line, in which you list all trucks that carry coal in order of best trucks first. Then you could branch simply based on the current cargo type and use the respective line.

For thr LVs set I have only 3 lines
- cargo trucks (refitable to everything)
- tourist buses (tourists)
- buses (passengers)

Every truck is refittable to everything else? Then it's almost trivial, actually. You need to make a list of all IDs in each line, sort them by what you think is better, and then essentially copy my DBSetXL scheme but replace it with your IDs.

This is because it considers all vehicles that are in the list before the current one to be better, and all vehicles after it to be worse. If the vehicle doesn't appear in the list, all vehicles would be better.

Regardless the price or not? If the new model is cheaper, would it replace old one?

It does not consider anything except (a) whether the vehicle is available and (b) whether the reliability is high enough. In a64 it will also make sure that (c) it is refittable to the current cargo.

All other considerations are up to you, because sometimes cheaper models can be better and more expensive models can be worse. Simply sorting by price and/or year would not be a good idea in general.

[satosphere]

I got a crash in a63.
In my very first train in dbsetxl , I tried to refit to grain. (Should it say grain(packaged) while refitting?).
It crashes then
savegame, cfg files, crash log file, screenie included in zip file)

[brutt01d]

alpha63

I have just had several problems today, including the same crash as zhe previouse poster. If I reload the savegame it persists.

It started when I loaded the savegame, built a new station alng the old coal mine station.

Problem 1: in which cases the "drive through station" order can appear in the train orders menu?? cause i could remve it from there only by destroying the station.

Problem 2: I bought a train and wanted to upgrade the iron ore self dischargers to the coal dischargers. When i pressed refit button, the PTTD crashed and exited to windows.

Problem 3: I had a similar crash by pressing the manage button after I bought 75% share f one of the AI's.

Problem 4: The program stopped saving the game! This is really bad at the moment. I have deleted most of the older savegamed, but still it doesn't work when I try to save manually. It just looks normal whil pressing the save button, but then the game doesn't really save anything. Can it be somehow helped?

A couple of other questions to developers:
It's all about the city behaviour.

a) A city wants to create a small road branch. It starts by making a small (half a tile) piece of branch. I for example, haven't liked it and bulldoze this piece of the brach away, so the initial road looks straight and clean. But after some time the city will anyway build this branch, often in a very stupid way. So would it be somehow possible to disallow the city to build a road in the place where a player at least once used the bulldozer? It would save us a lot of cursing while playing

b) Almost the opposite question. i noticed that citoes sometimes avoid building anything in the places (i do not understand yet this phenomenon) where a human player had dynamited a lot or had removed his station/city's housing. The mentioned places stay under grass for many years or probably never get used again anymore (although near the roads). Maybe the city desn't recheck if the place (tile) was freed? Can this be helped?

c) Also, is it somehow possible to stimulate a city to build smth. in a special place, rather than randomly as a city wants? And how many newbuildings exactly will be built if I fund the new buildings?

[DaleStan]

1) If (i) the station is a waypoint station, or (ii) nonstop on and the non-stop modifier has been applied to that order.

3) A crashlog might be helpful.

a) townbuildnoroads on
Of course, that'll aslo prevent the town from building roads were you haven't used the bulldozer. Alternatively, investigate townroadbranchprob.

b) Never experienced/noticed this.

[brutt01d]

If I relaunch the game, will townradbranchprob be applied to the savegames? I will try that with 33%.

4 crash logs are atached. The yre from one day, but I do not remember anymore, which one was a result of pressing the refit button and which one of the manage button. Sorry.

b) re:
the problem of cities, not building housing in previously used places.... I have encountered a topic on the microprose forums about the city growth fixes, stated by Martin. I think there was something like: "the problem that if you destroy a house still in the process of building and that the city doesn't recheck it's demolition (resulting in the wrong number of houses parameter) was fixed in TTD Patch." This is indeed so. But for me it seems that the city still doesn't recheck/consider the empty tiles (previously used by player/by completely built and destroyed houses) for futher construction of buildings/roads. I noticed this, because my cities are expanding quite fast, I'm using fund new buildings each 3 months, but the city prefers to build the small housing in suburbs, rather than the free grassed tile rite in the center, between the roads and stations! And this is noticeable almost in every city. It looks like the city, while expanding, is scanning the roads (starting from the center of course) for empty tiles to build a new house and finds the appropriate empty tiles only in suburbs. Because I think (as Martin cited the source) there is a 11/12 probability to build a house in the center on an empty tile (if the city is not blocked & expands) when the expansion counter gets to 0.

[brutt01d]

Another "manage button" crash.

Bought 75% shares and pressed the swear button The log is attached. Hmm, this bug is preety irritating...

P.S. and the stuff with my game not saving anymore resolved by itself somehow, it does save now

[brutt01d]

Is there any news about the patching? How soon can be the fix expected to come out?

Cause I need to remove that AI's train station on my way . But each time i want to buy his ass, the game crashes

[PikkaBird]

Hi!

Um, alpha 64 is up already.

Edit: Just don't try building any stations other than the default...

[brutt01d]

Oh! Well, OK, thanks for the fast patching, Patchman!

[goalie]

new stations are broken only the default graphics work