GRRRRRRRR! that was a great feature that never got immplemented why dont we re-implement itpatchman wrote:remove miscmods.loaduntilgreen, it was never actually implemented
2.0.1 alpha / 2.5 beta discussion
Moderator: TTDPatch Moderators
- Raichase
- Moderizzle
- Posts: 11509
- Joined: 15 Dec 2002 00:58
- Location: Sydney, Australia. Usually at work in the underground railway station...
- Contact:
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 immplemented why dont we re-implement itpatchman 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 by Raichase. Visit my Flickr! Gallery, Blog (get a feed of everyone at once at Planet TT-Forums).
Raichase - Perfect timing, all the time: [13:37] * Now talking in #tycoon
Official TT-Dave Worley Fan Club
Official TT-Andel-in-a-pink-hat Fan Club
Raichase - Perfect timing, all the time: [13:37] * Now talking in #tycoon
Official TT-Dave Worley Fan Club
Official TT-Andel-in-a-pink-hat Fan Club
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!
Simuscape - Chose Your Destination;
Simuscape | Visual Studio | INFRA Diary
INFRA Downloads - Chose Your Destination;
Simuscape | INFRA - A World of its own
Simuscape | Visual Studio | INFRA Diary
INFRA Downloads - Chose Your Destination;
Simuscape | INFRA - A World of its own
- minime
- Transport Coordinator
- Posts: 339
- Joined: 18 Jan 2004 10:02
- Skype: dan.masek
- Location: Prague, Czech Republic
- Contact:
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
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.
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
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.
- Attachments
-
- An "x" came home.
- SCR15.png (86.25 KiB) Viewed 22582 times
-
- No "x" 's here
- SCR11.png (83.99 KiB) Viewed 22582 times
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
(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
Reality is that which, when you stop believing in it, doesn't go away.—Philip K. Dick
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.
Reality is that which, when you stop believing in it, doesn't go away.—Philip K. Dick
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.
Got a grf file that demonstrates the problem?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
-
- Tycoon
- Posts: 5950
- Joined: 27 Apr 2005 07:09
- Contact:
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
-
- Engineer
- Posts: 3
- Joined: 17 Mar 2006 17:16
- Location: Netherlands
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?
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.
Formerly known as r0b0t_b0y2003, robotboy, roboboy and beclawat. The best place to get the most recent nightly builds of TTDPatch is: http://roboboy.users.tt-forums.net/TTDPatch/nightlies/
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.
Posted by Pookey...
For Information on TTD Patch Click Here
For Information on Building a Network (FAST) Click Here
For Information on Building a Network as a Challenge (SLOW) Click Here
For Help on the Different Signalling Types Click Here
Before Asking a Question, Please use the Forums Search Function Here and if you do Ask a Question, Please Provide as much Detail as Possible.
If you do not get a Crash Log when TTDPatch Crashes, Follow the Olly Debug Instructions Here and Post the Resulting Screenshot with your Problem.
For Information on TTD Patch Click Here
For Information on Building a Network (FAST) Click Here
For Information on Building a Network as a Challenge (SLOW) Click Here
For Help on the Different Signalling Types Click Here
Before Asking a Question, Please use the Forums Search Function Here and if you do Ask a Question, Please Provide as much Detail as Possible.
If you do not get a Crash Log when TTDPatch Crashes, Follow the Olly Debug Instructions Here and Post the Resulting Screenshot with your Problem.
Who is online
Users browsing this forum: No registered users and 3 guests