Cargo Destinations.

[JGR]

Ah yes, my apologies, I forgot about that switches.xml file. I'll have a look at it shortly.

Edit: I have never actually generated or seen this file

Seeing as you are one of the few with an interest in its structure, have you any suggestions as to format changes to accommodate the new type? (On that line, is there a spec document somewhere, as I haven't found one so far).

[AndersI]

have you any suggestions as to format changes to accommodate the new type? (On that line, is there a spec document somewhere, as I haven't found one so far).

I believe there's already a format that almost, but not quite covers this situation, http://www.tt-forums.net/viewtopic.php?p=473984#p473984, perhaps we should continue in that thread? The remaining problem is the fact that you're using quaternary numbers, something that neither the SWITCHES.XML nor TTDPC are prepared to handle today...

I think that thread is the only specification available, but a search for SWITCHES.XML might prove otherwise (beware of the long thread discussing TTDXC vs. TTDPC though, that's not very inspiring reading).

[JGR]

OK, as of the next nightly, the XML output should be in a sensible format. Sorry for breaking things .

[AndersI]

No need to blush! You're pushing the TTD envelope, it's really exciting running with cargo destinations (and smart signals and <whatever more you've created>).

Edit: Aaargh! The value 33333333333 goes outside the 'integer' range used in TTDPC. I'll have to rewrite TTDPC to use Int64 instead, else we'll have to invent something new...

Edit again: I think the best solution would be to have an optional 'base=x' in the xml, to signify the number base that should be used for visualizing a switch.

<range name="cdstcargoclassgentype" min="0" max="4194303" default="4194303" base=4 cmdline="" defstate="off" manpage="" desc="..."/>

In this case base=4 would imply that only the digits 0123 are valid, it would still not be an error to include the 'validdigits="0123"'

No 'base' given would mean base ten (or two if the number begins with '#'), so we only need to modify anything for this one switch (for the moment). I haven't the faintest idea how the xml is produced, so I don't know how difficult such a change would be.

YAE (yet another edit, it seems I'm talking to myself): I took a look at your changes (svn checkout of the source) and, as far as I understand it, it will not work, unfortunately. The validdigits by itself does not signify number base, only which digits are valid to use. See for example

<range name="curves" min="0" max="3333" default="120" cmdline="-c" defstate="on" validdigits="0123" manpage="..." desc="..."/>

where the range is described as a decimal range, while only digits 0123 are allowed in the number (I think this qualifies as a 'hack' by PatchMan).

Adding the base descriptor, as above, would solve our problems, I think.

[JGR]

TTDP reads it as a quaternary input, so it fits into 32 bits. (2 bits per digit -> 24 bits).

Such a change would not be difficult, it's just one function which would need to be changed. However it could result in the breaking of existing applications expecting a switch in decimal perhaps with the validdigits parameter.
Also manipulation of unusual bases tends to be a bit of a pain on the client (ie. your) end (there aren't really standard c functions for outputing strings from numbers in an arbitrary base).

[AndersI]

Such a change would not be difficult, it's just one function which would need to be changed. However it could result in the breaking of existing applications expecting a switch in decimal perhaps with the validdigits parameter.

The breaking has already been done, now we're trying to find a solution

An application that doesn't know about the "base=x" directive would read the 33333333333 as a decimal just like it would today, because it is defined as a range and doesn't have any special character in front of it, ergo: decimal. The validdigits is, as I said, a kind of hack, or the range value in curves is a hack.

The benefit of introducing base would be that we keep all information about the switch in the XML file (ie. it is still a 32bit number, but is displayed/stored in another format) which, IMO, is the whole point of this file. For TTDPC it would also mean a minor adjustment instead of a whole-sale change of data type (Int64 instead of Integer). To be honest, I only know of two programs using SWITCHES.XML - TTDPC and TTDXC.

Also manipulation of unusual bases tends to be a bit of a pain on the client (ie. your) end (there aren't really standard c functions for outputing strings from numbers in an arbitrary base).

Not a problem for me, at least. My Delphi (Pascal) snippets collection already has functions for this, in both directions.

[JGR]

OK, the next nightly should contain the next revision of the XML format, hopefully this will work for you...

[fonso]

Congratiulations, you have entered the top 10 of my personal list of craziest hacks ever. Cargo destinations in assembler to be patched into the TTD binary deserves a place somewhere near the brainfuck IDE.

[AndersI]

OK, the next nightly should contain the next revision of the XML format, hopefully this will work for you...

A new version of TTDPC has been uploaded to the TTDPC thread

[copperpen]

Anders1

Thankyou for the update to TTDPC. Used it to set the cargodest switches.

JGR

I have continued to run cargodest and I like the way it is working. I set up a new game with an Island map. I am also using the day length switch. Having slowly expanded my reach through the islands I started looking at who was travelling where and was pleasantly surprised to find a carriage full of people on one island who had come from another island. The only link between islands is by air.

[Pookey]

Excellent feature JGR

[michael blunck]

Jonathan, is there a reason why there´s no patch flag available/accessible for the cargodest feature, rather than it (still) being experimental?

regards
Michael

[JGR]

Jonathan, is there a reason why there´s no patch flag available/accessible for the cargodest feature, rather than it (still) being experimental?

regards
Michael

I didn't think it was necessary, as it should not affect graphical/GRF aspects of the game.
If you can explain why there should be one, I can see about adding it...
(Bearing in mind that the flag mapping is close to full and if I understand the GRF spec some semblance of cross-game compatibility is preferable).

EDIT: I stumbled across this http://wiki.ttdpatch.net/tiki-index.php ... hVariables when perusing the wiki. Do you mean this instead/will that do?

[wallyweb]

I have a problem that seems to be related to the cargo class type setting. I may be wrong, and it might be something else altogether.

My setting is cdstcargoclassgentype 222222222211 with my intention of having Cargo Destinations for passengers and mail but not for other cargoes.

Using coal as an example, I have a series of trucks collecting cargo at the mine and delivering to a central transfer station for loading on a series of trains that all go to the same destination.

What happens is this: A train is waiting for a full load. When the last hopper attains its maximum load from a truck, often the truck's load is not fully accommodated and a portion remains at the station for the following train. With Cargo Destinations set to off, this works quite well with little or no penalty. However, with Cargo Destinations set to on, it seems that the remaining portion is not collected by the following train but rather waits around for that first train to return. This results in a penalty and income earned by that train becomes progressively lower with each trip.

Am i misinterpreting the meaning of "2: all cargo is unrouted (old behaviour)"?
Is there another way to be more selective as to the cargo classes to be accommodated with the destination feature?
How can I avoid that penalty?

Here are my cargodest settings:

Code: Select all

// `cargodest' (-ZG) enables cargo destinations
cargodest on

// `cdstcargoclassgentype' (No command line switch) controls cargo generation for the cargodest switch for each cargo class. One digit per cargo class: 0 for the rightmost up to 10 for the leftmost. Digit value: 0: all cargo is by preferance routed, 1: all cargo is routed (or dropped at source), 2: all cargo is unrouted (old behaviour), 3: mix of routed and unrouted cargo generated. See: http://wiki.ttdpatch.net/tiki-index.php?page=Action0Cargos#Cargo_classes_16_ for list of cargo classes. Where a cargo is in multiple classes the bitwise OR of specified values is used. Range 0..33333333333. Default 33333333333.
cdstcargoclassgentype 222222222211

// `cdstcargopacketttl' (No command line switch) sets the ttl (time to live) for newly created cargo packets, each hop decrements this value, even if the packet stays on the vehicle. Any packets which run out of life will be exterminated without payment. This is to prevent any errant packets from circling the network indefinitely. Range 0..255.  Default 100.
cdstcargopacketttl 100

// `cdstnegdaysfactor' (No command line switch) cargo generation destination selector: factor to multiply minimum cost in days by before subtracting from score for routed cargo. Range 0..1000.  Default 3.
cdstnegdaysfactor 3

// `cdstnegdistfactor' (No command line switch) cargo generation destination selector: factor to multiply manhattan distance by before subtracting from score for routed cargo. Range 0..1000.  Default 2.
cdstnegdistfactor 2

// `cdstroutedinitscore' (No command line switch) cargo generation destination selector: initial score for routed cargo before target station activity is added and distance and day costs are subtracted, note negative scores result in exclusion. Range 0..2147418112.  Default 1500.
cdstroutedinitscore 1500

// `cdstrtcmpfactor' (No command line switch) sets route comparison threshold for cargodest switch. Route cost threshold (in days) at a node is equal to minimum found cost * this value / 65536. Set to 65536 to only ever allow one route to any destination. Set to an enormous value to disable any semblence of intelligent routing. The (per route) lesser of this and the cdstrtdiffmax switch applies. Range 65536 (100%)..2147483647 (3276800%).  Default 91750 (about 140%).
cdstrtcmpfactor 91750

// `cdstrtdiffmax' (No command line switch) sets route comparison threshold for cargodest switch. Route cost threshold (in days) at a node is equal to minimum found cost + this value. Set to 0 to only ever allow one route to any destination. Set to an enormous value to disable any semblence of intelligent routing. The (per route) lesser of this and the cdstrtcmpfactor switch applies. Range 0..30000.  Default 60.
cdstrtdiffmax 60

// `cdstrtexprthrshld' (No command line switch) sets the time in days after which an unused single hop route expires. Range 0..3653.  Default 100.
cdstrtexprthrshld 200

// `cdstunroutedscore' (No command line switch) cargo generation destination selector: unrouted cargo score. Range 0..2147483647.  Default 500.
cdstunroutedscore 500

[michael blunck]

Am i misinterpreting the meaning of "2: all cargo is unrouted (old behaviour)"?
Is there another way to be more selective as to the cargo classes to be accommodated
with the destination feature?
How can I avoid that penalty?

Am I right in suggesting that it´s time to prepare a manual entry for this great new feature?

Unfortunately, I´ve only recently started a first game and thus I don´t feel the right person to write a comprehensible text.

Is there someone else to take the lead? Wally? Jonathan? copperpen? ...?

regards
Michael

[wallyweb]

Is there someone else to take the lead? Wally? Jonathan? copperpen? ...?

JGR ?

[JGR]

Is there someone else to take the lead? Wally? Jonathan? copperpen? ...?

JGR ?

JGR == Jonathan, just to clarify dear...

I would be willing to contribute/write a section in the manual, however, I am currently somewhat busy with uni work and general life, (recent developments are somewhat drawing my attention away from heavy deving and work ). Also my usual time sinks (weekends) will most likely be eaten up by... plans potentially for the whole duration of term.

As for the full loading bug, try a cht: resetfifo signcheat and see if the problem reappears...
(I had a similar issue at one station, but dong that seemed to get rid of it). I may well have a scan of the code later though...

The feature is still not completely finalised as there are a number of instances where it does not work and/or is suboptimal/unfinished...

[michael blunck]

Well, yes. At least for the sublties, this would be needed. OTOH, he should spare his time for bug hunting (?) and firther improvements. So, .. , how about a certain Wally?

BTW, the right place for the article would be the TTDPatch manual, chapter "basics" or chapter "economy and finances" (?), IMO.

regards
Michael

[wallyweb]

So, .. , how about a certain Wally?

A certain Wally would consider the undertaking except for the fact that he does not sufficiently understand it in order to provide some text that would be somewhat more intelligible than "@#%@##^&$!* breakfast is late".

@JGR ... I will definitely try the cht: resetfifo signcheat and see if the problem reappears.

As for your uni work, perhaps they might allow you to change your major to Cargo Destinations and this project could be your doctoral thesis.

[wallyweb]

As for the full loading bug, try a cht: resetfifo signcheat and see if the problem reappears...
(I had a similar issue at one station, but dong that seemed to get rid of it). I may well have a scan of the code later though...

The feature is still not completely finalised as there are a number of instances where it does not work and/or is suboptimal/unfinished...

I tried the cht: resetfifo and it worked for the current train, but the issue reappeared pending the arrival of the next train. I suppose one could do the cheat for each train arrival, but that might be a bit hard on my fingers and my mouse.