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
Moderator: TTDPatch Moderators
Go ahead...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
- Posts: 11597
- Joined: 15 Dec 2002 00:58
- Location: Sydney, Australia. Usually at work in the underground railway station...
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 .
- Transport Coordinator
- Posts: 339
- Joined: 18 Jan 2004 10:02
- Skype: dan.masek
- Location: Prague, Czech Republic
In 2.5b9, the "x" button for closing a window occasionally loses the "x". The button still works as intended.
Yes.Patchman wrote:That's a bit too vague to investigate. Can you provide more details?
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.
6. A picture is worth a 1000 words ... 2000 words below.
- An "x" came home.
- SCR15.png (86.25 KiB) Viewed 10347 times
- No "x" 's here
- SCR11.png (83.99 KiB) Viewed 10347 times
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...
 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
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.
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.
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).
> 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
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?
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.
Users browsing this forum: No registered users and 1 guest