Posted: 30 Oct 2006 17:13
GRRRRRRRR! that was a great feature that never got immplementedpatchman wrote:remove miscmods.loaduntilgreen, it was never actually implemented
why dont we re-implement it 
why dont we re-implement it Transport Tycoon Forums
The place to talk about Transport Tycoon
https://www.tt-forums.net/
2.0.1 alpha / 2.5 beta discussion
Page 81 of 83
why dont we re-implement it Posted: 30 Oct 2006 19:22
Go ahead...m3henry wrote:GRRRRRRRR! that was a great feature that never got immplementedpatchman wrote:remove miscmods.loaduntilgreen, it was never actually implemented
Posted: 31 Oct 2006 07:29
Please do, I really liked the idea (hell, as it was my idea, I should've).m3henry wrote:GRRRRRRRR! that was a great feature that never got immplementedpatchman wrote:remove miscmods.loaduntilgreen, it was never actually implemented
Also, in Josefs defence, he did try to do it, and it didn't work. Thats more than I could ask of him, considering all the unpaidness of it and whatnot.
But, with no sarcasm, if you want to put it in ttdpatch, please do, I still think it was a good suggestion
.Posted: 01 Nov 2006 08:29
Just noticed that I can plant LOTS of trees, and I mean LOTS of trees with a few clicks - something I haven't noticed before! Anyway, it somehow solves my tree aggrevations!
Thank you!
Thank you!
Posted: 02 Nov 2006 00:33
I've noticed that the tooltips in the company window are still off by one in beta 9, as well as the nightlies. However the corresponding tracker ticket has already been closed, claiming the problem is fixed.
minime
minime
Posted: 04 Nov 2006 22:58
Cosmetic issue ... maybe
In 2.5b9, the "x" button for closing a window occasionally loses the "x". The button still works as intended.
In 2.5b9, the "x" button for closing a window occasionally loses the "x". The button still works as intended.
Posted: 05 Nov 2006 06:10
That's a bit too vague to investigate. Can you provide more details?
Posted: 05 Nov 2006 11:53
Yes.Patchman wrote:That's a bit too vague to investigate. Can you provide more details?
Oh! Ok!
1. Seems to only occur with Locomotion style menu.
2. Seems to only occur with Station tab.
3. Moving the cursor affects it.
4. The button still works even without the "x"
5.// `locomotiongui' (-U) enable the new locomotion style gui.
locomotiongui.usenewgui on
locomotiongui.defaultnewgui off
locomotiongui.defaultstation on
6. A picture is worth a 1000 words ... 2000 words below.
Posted: 05 Nov 2006 22:39
(I'm posting this here because I don't really have time to debug it myself)
Something broke with the UTF-8 handling somewhere between beta 8 and beta 9. Now, in the title of the game window and the taskbar button, every accented character becomes a question mark, even those that should be present in the current code page. Maybe I'll have some time to debug it later, but I'll post here anyway before I forget about it...
[edit] OK, I was just curious and investigated the problem a little further. It seems that TTDPatch feeds incorrect input to MultiByteToWideChar in texthandler_ACP. The character 'á' (E1) becomes EE 83 A1 instead of the correct C3 A1. Similarly, 'é' (E9) becomes EE 83 A9 instead of C3 A9. Interestingly, 'ő' (151) and 'ű' (171) seem to be unaffected - they have the correct encoding. The game itself keeps showing the texts fine, so I doubt it's a problem in my GRF.
I hope this is enough info to get Patchman started on finding the bug
Something broke with the UTF-8 handling somewhere between beta 8 and beta 9. Now, in the title of the game window and the taskbar button, every accented character becomes a question mark, even those that should be present in the current code page. Maybe I'll have some time to debug it later, but I'll post here anyway before I forget about it...
[edit] OK, I was just curious and investigated the problem a little further. It seems that TTDPatch feeds incorrect input to MultiByteToWideChar in texthandler_ACP. The character 'á' (E1) becomes EE 83 A1 instead of the correct C3 A1. Similarly, 'é' (E9) becomes EE 83 A9 instead of C3 A9. Interestingly, 'ő' (151) and 'ű' (171) seem to be unaffected - they have the correct encoding. The game itself keeps showing the texts fine, so I doubt it's a problem in my GRF.
I hope this is enough info to get Patchman started on finding the bug
Posted: 06 Nov 2006 16:18
Update on the accent problem: it seems that r1143 is the culprit. In this code:
Patchman assumes that everything in the range 9E..FF is special and needs to be prefixed with E0. This is not true, however, since only 9E..BD is special.
I'd have fixed it myself, but then I noticed that the code doesn't work as I thought it should. For example, the spec says that C2 82 should bring up the character in slot 82, but the code does this instead: it decodes the sequence to 82, then jumps to .gotchar that treats 82 as a special char. I can't figure out how it's supposed to work, so I'd rather not touch it.
@Patchman: I'll be on IRC tonight, we can discuss the problem further there if you like.
Code: Select all
cmp eax,0x100
jae .unicode
mov ah,0xe0
jmp short .store // E0 is ignored in non-utf8 mode
.unicode: I'd have fixed it myself, but then I noticed that the code doesn't work as I thought it should. For example, the spec says that C2 82 should bring up the character in slot 82, but the code does this instead: it decodes the sequence to 82, then jumps to .gotchar that treats 82 as a special char. I can't figure out how it's supposed to work, so I'd rather not touch it.
@Patchman: I'll be on IRC tonight, we can discuss the problem further there if you like.
Posted: 27 Nov 2006 22:43
Train Stations and Animation
Although implemented several patches ago, I've yet to see it work. I don't want to call it a bug yet, but I'd like to know whether I missed something.
First we have the station properties 16, 17 and 18. The patch seems to accept them, at least it complains if property size is incorrect.
Then, there are the 3 callbacks 140, 141 and 142; if they are called at all, the result is simply ignored and yes, I do have bits 2 and 3 set in station property 0B. I cannot even make the game crash by supplying a non-existent frame number or any other silly values.
My understanding is that the frame number is added to the sprite number, so that the correct animation sprite can be displayed.
However, I would have expected to set a bit in the sprite number (station property 09), so that the patch knows which sprites are part of an animation sequence. Working in a similar way to company colour determination. If that is not the case, the whole thing looks a bit silly. Property 16 specifies the number of frames for a particular station, so every sprite will be treated the same way; e.g. :
We have an animated station tile, consisting of 1 rear platform, 1 front platform, 1 fence to the rear and 1 to the front plus the 8 sprites making the animation sequence. That will cost me 12 sprites. But with only having property 16 to say that the tile has an 8 frame animation sequence, I would have to supply the first 4 sprites 8 times as well although they will always be the same costing me 40 sprites in total; what a waste. Don't say I could put everything on the one sprite; in that case I would need a sprite with no fences, 1 fence to the rear only, 1 fence to front only and fenced either side, costing me 32 sprites to start with. This is a very easy set up, but most station tiles are far more complex with roofs, benches, lights, crosswalks, gates, stairs, subways, etc, to accommodate all possible combinations would cost me thousands of sprites. On the other hand, using the Lego System, I can easily configure a station tile. On average I have about 16 configurations of each station tile (by station ID), easy ones a few less, more complex ones a few more.
The absolute minimum required for station animation is :
. set property 16 to, say, 4 frames.
. set property 17 to, say, 6 (animation speed about 2 seconds)
Right ? All the rest including callbacks is for customisation of the whole process.
Doing that, nothing happens !
Now, the question that remains is, how does station tile animation really work ?
And while we are on the subject of station coding, it's one of the features that suffers from a real lack of information (station variables that is).
Why does an industry tile has access to a vast amount of information about its surroundings, but a station tile has almost nothing. Could it just be possible to copy the 'GetTileInfo' to the station feature. I would be quite happy to only have access to ss (slope data) of variable 60. Maybe while you are at it the owner of the tile in question too; i.e. although, I can find out whether on an adjacent non-station tile there is track, but I do not know whether it is my company that owns that track or someone else has decided to build a piece of track immediately next to my station.
This has already been suggested, in a slightly different form, but using the same set up as for industry tiles makes more sense.
Another very important piece of information lacking, is the station ID and tile type of adjacent station tiles. The only thing I know is whether there is another station tile that belongs to another station ID (using a combination of var 40, 41 and 45), but I don't know the station ID and/or the real tile type (the one I have assigned) or even whether the station tile belongs to another station set, in which case I'm not interested.
Any help would be highly appreciated, thank you.
Although implemented several patches ago, I've yet to see it work. I don't want to call it a bug yet, but I'd like to know whether I missed something.
First we have the station properties 16, 17 and 18. The patch seems to accept them, at least it complains if property size is incorrect.
Then, there are the 3 callbacks 140, 141 and 142; if they are called at all, the result is simply ignored and yes, I do have bits 2 and 3 set in station property 0B. I cannot even make the game crash by supplying a non-existent frame number or any other silly values.
My understanding is that the frame number is added to the sprite number, so that the correct animation sprite can be displayed.
However, I would have expected to set a bit in the sprite number (station property 09), so that the patch knows which sprites are part of an animation sequence. Working in a similar way to company colour determination. If that is not the case, the whole thing looks a bit silly. Property 16 specifies the number of frames for a particular station, so every sprite will be treated the same way; e.g. :
We have an animated station tile, consisting of 1 rear platform, 1 front platform, 1 fence to the rear and 1 to the front plus the 8 sprites making the animation sequence. That will cost me 12 sprites. But with only having property 16 to say that the tile has an 8 frame animation sequence, I would have to supply the first 4 sprites 8 times as well although they will always be the same costing me 40 sprites in total; what a waste. Don't say I could put everything on the one sprite; in that case I would need a sprite with no fences, 1 fence to the rear only, 1 fence to front only and fenced either side, costing me 32 sprites to start with. This is a very easy set up, but most station tiles are far more complex with roofs, benches, lights, crosswalks, gates, stairs, subways, etc, to accommodate all possible combinations would cost me thousands of sprites. On the other hand, using the Lego System, I can easily configure a station tile. On average I have about 16 configurations of each station tile (by station ID), easy ones a few less, more complex ones a few more.
The absolute minimum required for station animation is :
. set property 16 to, say, 4 frames.
. set property 17 to, say, 6 (animation speed about 2 seconds)
Right ? All the rest including callbacks is for customisation of the whole process.
Doing that, nothing happens !
Now, the question that remains is, how does station tile animation really work ?
And while we are on the subject of station coding, it's one of the features that suffers from a real lack of information (station variables that is).
Why does an industry tile has access to a vast amount of information about its surroundings, but a station tile has almost nothing. Could it just be possible to copy the 'GetTileInfo' to the station feature. I would be quite happy to only have access to ss (slope data) of variable 60. Maybe while you are at it the owner of the tile in question too; i.e. although, I can find out whether on an adjacent non-station tile there is track, but I do not know whether it is my company that owns that track or someone else has decided to build a piece of track immediately next to my station.
This has already been suggested, in a slightly different form, but using the same set up as for industry tiles makes more sense.
Another very important piece of information lacking, is the station ID and tile type of adjacent station tiles. The only thing I know is whether there is another station tile that belongs to another station ID (using a combination of var 40, 41 and 45), but I don't know the station ID and/or the real tile type (the one I have assigned) or even whether the station tile belongs to another station set, in which case I'm not interested.
Any help would be highly appreciated, thank you.
Posted: 28 Nov 2006 01:58
Got a grf file that demonstrates the problem?
Posted: 28 Nov 2006 08:09
It works for me. Even my very first animated station .grf using CBs 140, 141, 142 and dating back from may 16th does work, both under beta9 and 2.6 nightlies.Csaboka wrote:Well, I clearly remember implementing it, so if it doesn't work, it's a bug, and please report it.animation for stations has not been implemented yet (as of 2.5 beta 9) although the wiki says otherwise (i.e. since 2.5 beta 5).
@OzTransLtd
> I'd like to know whether I missed something.
I attach a code snippet for your convenience.
Code: Select all
// station action 0
[...]
// animation info
16 15 01
// animation speed
17 03
// animation triggers: train enters/leaves
18 18 00
[sprite layout block]
[...]
// assemble animation frames
-1 * 94 02 04 01 81 4A 00 FF 15
04 FF 01 01
...
04 FF 15 15
02 FF
// animation control - check var.18 low byte
-1 * 18 02 04 03 81 18 00 FF 02
FE 80 03 03 // start: train enters
FF 80 04 04 // stop: train leaves
FD 80 // do nothing
[...]
// callbacks
-1 * 23 02 04 21 85 0C 00 FF FF 02
01 00 14 00 14 00 // tile type
03 00 40 01 40 01 // animation control
04 00
-1 * 16 03 04 01 00 03
FF 0D 00
02 21 00
FE 21 00
21 00
regards
Michael
Posted: 29 Nov 2006 00:45
Thanks, I'll check that out ...
Posted: 12 Dec 2006 15:46
I just copied 2.9 to my ttd directory. But when i excute it, i get CMD saying everything is OK press enter continue. And then CMD window closes and nothing happens. 2.8 worked, and still works fine.
Am i doing something wrong?
Am i doing something wrong?
Posted: 12 Dec 2006 16:13
I presume you mean 2.5 beta 9 and 8 respecively, instead of 2.9/2.8 which won't be out for years.
Download beta 8 again from http://www.ttdpatch.net/src/old/ and see if it still works. If it doesn't work either, something is broken in your TTD installation.
Are you getting crash log files?
Download beta 8 again from http://www.ttdpatch.net/src/old/ and see if it still works. If it doesn't work either, something is broken in your TTD installation.
Are you getting crash log files?
Posted: 27 Jan 2007 09:41
Is 2.5 beta still in development, or is everyone using 2.6 alpha/nightlies?
Posted: 27 Jan 2007 10:32
its still in development to remove the bugs and so we can have a more recent stable. but lots of people are using the nightlies.
Posted: 22 Feb 2007 20:24
Are there serious issues left with 2.5 itself? I have an inklink there's some graphics sets awaiting release of the stable 2.5. Not that I'm trying to rush anyone, of course - don't get me wrong.
Posted: 23 Feb 2007 09:39
2.5 Beta 9 is basically stable, it's just Patchman doesn't want to release it as a stable until he's entirely sure that all bugs are removed.