2.0.1 alpha / 2.5 beta discussion

squishycube · Post by **squishycube** » 13 Mar 2006 12:33

No problem, stevenH

In the meantime, I started a new game and I has some PBS train chrashes.
I don't have a savegame for you, so its probably not possible to go looking for a bug.
This post is more to let you know that there are apparently still bugs in PBS.

(Note: some of the crashes were my own fault; removing signals messing up the pbs block and trains crashing, but I also had one crash when I was working on a totally different location and I hadn't changed anything about the location where the crash occured for years.)

Another thing, for some reason, my TTDX installation at home stopped displaying reserved routes in PBS blocks. Although I actually prefer that, I am not sure how it happened.

Raichase · Post by **Raichase** » 14 Mar 2006 07:41

squishycube wrote:Another thing, for some reason, my TTDX installation at home stopped displaying reserved routes in PBS blocks. Although I actually prefer that, I am not sure how it happened.

Have a look in the manual, under PBS. There are bit switches that show how much track is darkened by the reserving.

I can't remember the name of the switch this second, but it's right on the main PBS page

.

kvtb · Post by **kvtb** » 19 Mar 2006 13:14

did something changed w signalwaittimes in beta 1?
I have a problem where trains constantly keep reversing within a terminus station if they do not get a PBS path immediately. The wait time for twowaysignals is set to 15 days.
The result is starvation/livelock: each time a path becomes available, the train just reversed and another train will take its path instead.

Anyone else experiencing the same behaviour?

BTW: setting signal2waittime to 255 works, but I cannot prove no deadlock will occur with this setting.

Rob · Post by **Rob** » 19 Mar 2006 13:19

It's a know bug.
See : http://www.tt-forums.net/viewtopic.php?p=412075#412075

kvtb · Post by **kvtb** » 19 Mar 2006 13:22

When may we expect presignals for depots? That would solve lots of problems with station entrances with depots.

Sometimes, if all platforms are occupied, a train gets a PBS path to a depot (instead of just wait in front of a red presignal) and will then try to enter the station from the depot, blocking all tracks...

Rob · Post by **Rob** » 19 Mar 2006 13:30

Well that's in the todonow.txt, and it's marked "rather urgent".
So it's being worked on.

TODONOW.txt wrote:Include depots "usefully" in a pre-signal block.
Idea: when depot checks whether block is clear, count pre, exit & combos
if (pre&exit) or combo present, depot "signal" acts like pre-signal
then placing combo-signal in front of depot makes depot act like
a sponge; otherwise it's not interfering with the regular station
operation

The Irish · Post by **The Irish** » 19 Mar 2006 16:19

For some strange reason, I don't have this problem. The train never goes automatically to the depot if all tracks are blocked. Only when I create a new train in the depot, then this can happen.

tijnttd · Post by **tijnttd** » 06 Apr 2006 08:24

I have installed the latest beta right now, and some new graphics needed. I updated newgrfw.cfg, ttdpatch.cfg and so.

But now I get an error when starting a new game, with loading the graphics. The error is in loading the newcargo set, code 24/5, invalid sprite.

The question is: what did I do wrong? (has to be something

)

stevenh · Post by **stevenh** » 06 Apr 2006 08:30

tijnttd wrote:I have installed the latest beta right now, and some new graphics needed. I updated newgrfw.cfg, ttdpatch.cfg and so.

But now I get an error when starting a new game, with loading the graphics. The error is in loading the newcargo set, code 24/5, invalid sprite.

The question is: what did I do wrong? (has to be something )

please edit your config and edit or add:

Code: Select all

experimentalfeatures.mandatorygrm off

tijnttd · Post by **tijnttd** » 06 Apr 2006 08:44

thanks a lot, that worked!!!!

hovering teacup · Post by **hovering teacup** » 23 Apr 2006 08:31

i tried in the callback for industry production with a code like following:

Code: Select all

61 * 117	00 0a 0b 01 0a 08 00 09 00 10 01 08 11 05 1b ff ff 12 00 13 00 17 06 18 02 20 88 88 88 88 21 04 0a 02 4f 00 00 00 00 00 03 00 01 04 00 02 04 01 00 03 01 01 00 01 02 02 02 00 00 02 01 02 02 02 04 00 80 00 00 64 00 01 65 00 02 66 00 03 67 01 00 68 01 01 69 01 02 6a 01 03 6b 02 00 6c 02 01 6d 02 02 6e 02 03 6f 03 00 70 03 01 71 03 02 72 03 03 73 00 80

-1 * 15	02 0a 00 00 00 00 00 00 00 00 03 00 00 00 01
-1 * 15	02 0a 01 00 00 00 00 00 00 00 00 00 00 00 01
-1 * 15	02 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
-1 * 23	02 0a 03 85 18 08 ff 00 02 00 00 00 00 00 00 01 00 01 00 01 00 02 00 

-1 * 15	02 0a 04 00 00 00 00 00 00 00 00 00 03 00 01
-1 * 15	02 0a 05 00 00 00 00 00 00 00 00 00 00 00 01
-1 * 15	02 0a 06 00 00 00 00 00 00 00 00 00 00 00 00
-1 * 23	02 0a 07 85 18 08 ff 00 02 04 00 00 00 00 00 05 00 01 00 01 00 06 00

-1 * 18	02 0a 08 85 60 00 00 ff ff 01 03 00 03 ff 03 ff 07 00

-1 * 7	03 0a 01 0a 00 08 00

in above lines input cargos are all zero. now, with one of them (anyone in any line actually called) set to other than zero the game carshes. crash log is below.

another point, it seems that production callback's lines can use only real values. isn't it handier if they were sprite ? as this would allow to send to another line that performs a calculation for input and output (or use real value with the highest bit set). sorry if this is just a "i know i know it would be already that way if it were possible" kind of stuff.
[EDIT] even handier if the return value can specify the cargo type, just like in the production callback for town buildings.

Patchman · Post by **Patchman** » 23 Apr 2006 16:08

I've fixed the crash for beta 4. About the other issues I'll have to let Csaba look at them.

hovering teacup · Post by **hovering teacup** » 24 Apr 2006 14:44

Csaboka · Post by **Csaboka** » 25 Apr 2006 15:03

hovering teacup wrote:another point, it seems that production callback's lines can use only real values. isn't it handier if they were sprite ? as this would allow to send to another line that performs a calculation for input and output (or use real value with the highest bit set). sorry if this is just a "i know i know it would be already that way if it were possible" kind of stuff.
[EDIT] even handier if the return value can specify the cargo type, just like in the production callback for town buildings.

The problem with this idea is that 15 bits just aren't enough to contain all that. That's why the industry production callback had to be this way instead of a regular callback.

If you can give me a better way it should work, I could code it for you, but I can't do anything without a specification of how it should work.

DaleStan · Post by **DaleStan** » 25 Apr 2006 17:25

What comes to mind is:

For the production callback, the action 2 data looks as follows:
Code: Select all
<Sprite-number> * <Length> 02 0A <set-id> <version> <subtract-in-1> <subtract-in-2> <subtract-in-3> <add-out-1> <add-out-2> <again>
If <version> is 00, <insert remainder of current wiki page here>

If <version> is 01, <subtract-in-?>, <add-out-?>, and <again> are all variable width, in the following format:
Code: Select all
<type> <variable> <var-adjust> [<operator> <variable> <varadjust>]...
where <type>, <variable>, <var-adjust>, and <operator> function as for (advanced) variational 2s. The result is zero-extended or masked down, if/as necessary, to create a value of the appropriate width.

That's probably horribly overpowered, but it's simple in theory. Execution may be a substantially different matter.

Flamelord · Post by **Flamelord** » 25 Apr 2006 23:16

One quick question:

The topic is still titled with Beta 1. Is this intentional?

DaleStan · Post by **DaleStan** » 26 Apr 2006 04:07

I also came up with something that is more powerful, but (IMO) seems less horribly over-powered:

<yadda, yadda, yadda> <if version is 00> <yadda, yadda, yadda>

If <version> is 01, <subtract-in-?>, <add-out-?>, and <again> are all <set-id>s or callback results, as in variational2s.
All six of the chains are followed until they either fail (a return of zero? fail the entire production callback?) or return a standard callback result. The five chains starting at <subtract-in-?> and <add-out-?> accept 15-bit results, and the chain starting at <again> accepts an 8-bit result.

This permits use of the full power of varactions, rather than just the <variable> <varadjust> ... part.
OTOH, convincing the Action2 to branch like this may be interesting, and it limits the values for <subtract-in-?> and <add-out-?> to slightly under fifteen bits, rather than the full sixteen.
OTGH, there are at most 32767 units of any type waiting anywhere at any one time, and the production callback may be called several times, so only having 14.98868... bits should not be a major issue.

/me hopes that Csaba won't beat him up too badly.

Csaboka · Post by **Csaboka** » 26 Apr 2006 08:22

I like your second idea, DaleStan, but I'm not sure how difficult it would be to implement it (I'm not at my own computer now, so can't check the source code of action2 handling). It would basically allow two levels of decision: first, you use a usual action2 chain to select one of the production instructions, then the selected instruction can use its own chain to decide the actual amounts.

Looking at some of George's more complicated production schemes, we'd probably benefit from something this powerful

George · Post by **George** » 26 Apr 2006 09:20

Csaboka wrote:Looking at some of George's more complicated production schemes, we'd probably benefit from something this powerful

I specify possible rations with several production callbacks, and then run them several time by checking var 18. Befor that happens, I use a system of actions 2, which define, how many times and what ratios (production callbacks) should be used.

Csaboka · Post by **Csaboka** » 26 Apr 2006 10:02

Yes, but wouldn't that be easier with the new system proposed?

Transport Tycoon Forums

2.0.1 alpha / 2.5 beta discussion

Who is online