Transport Tycoon Forums

Posted: **21 Apr 2007 11:43**

Tenderwheels wrote:
wallyweb wrote:
Tenderwheels wrote:Listening to all this, I must say I can't build any industries anywhere even though I should, according to my setup. Message is always: 'Can't construct this industry type here, site unsuitable'.(Food processing plant)
I tried every were else, with no luck ...I could prospect for a mine, and a diamond mine turned up.....
Is there anything else that you can tell us about or show us?
Which climate are you playing in?
Which version of the patch are you using?
Could you attach your patch configuration file?
Which grf's are you using?
Could you attach your newgrf configuration file?
Is this a new game or a saved game or a scenario?
Unfortunately "according to my setup" tells us absolutely nothing as we are unable to tunnel into your computer at this time.
What is your setup?
Wallyweb: I'm using the Temperate climate.
TTDPatch 2.6 0 r1486(windows)
Have tried TTDPatch 2.5 beta 9 (oct 29, 2006).
Using SAC's INFRA-Region (2006,10,13) Senario.
Just found out this is for TTDLX game play, If this is the problem I apologise.
I have lost industries due to lack of use so I'm pretty sure this is not the limitation causing the problem. Using PB_UKRSI.GRF and PB_UKRS.GRF with CARGOSETW.GRF.
Thanks for your time. Sandy (Tenderwheels)

In your newgrf.cfg
Try changing newgrf/ARCTICSETW.GRF to
#disabled#newgrf/ARCTICSETW.GRF
In your ttdpatch.cfg
try setting miscmods.nonewspritesorter=off

Posted: **22 Apr 2007 15:35**

Tenderwheels: In the UKRSI, most secondary industries can only be built close to towns in the game (they can be built anywhere in the scenario editor).

The requirements for each industry will be made clearer in future versions of the grf.

Posted: **22 Apr 2007 22:36**

WallyWeb and PikkaBird: Thankyou for your posts, will try these suggestions and get back. Cheers. Tenderwheels.

Posted: **26 Apr 2007 01:19**

(moved from http://www.tt-forums.net/viewtopic.php?t=31618 to here, cause it's not actually a problem any more.)

JGR wrote: Carlo Ghega: An experimental, partially untested fix for this was committed and will be available in the next nightly. You have the dubious honour of testing it with the max of 32 cargos...

r1521, JGR: Preliminary, Experimental, Bug-Fixing Code.
Use Oskar's drop-down code instead of TTD default to allow up to 32 cargos in trace restrict cargo selection list, instead of up to 19. (Previously caused crash when more than 19 cargos present). Not tested under DOS.

Just wanted to let you know, that cargo-restriction seems to work perfectly now (Windows XP) with 32 cargos in game.

On the picture you see Beaujolais railway station:

1 Station, 8 Platforms, 12 cargos. Every Platform restrictet to from 2 to 5 cargos - works very well up to now.

Will change to newer nightly next time, to get your update of Oskar's drop-down GUI code too. And let you know in case I get related problems.

Best regards

CG

Posted: **01 May 2007 21:15**

Bug assumed in PBS using r1533 concerning to trains not entering stations where two-way signals are not positioned immediately after the exits of the station. (Like on the picture below).

As far as tested, Rob seems to be right, when pointing out that it appears only if difficulty setting is put on "reverse at end of line and at stations".

Details, ttdpatch.cfg and savegame can be found here (sorry for relinking, first was not sure if it wasn't just a handling error): http://www.tt-forums.net/viewtopic.php?p=580901

newgrf.cfg is here.

Thank you very much for your efforts, (hope I get not annoying).

Best regards,

CG

p.s.:Seems to touch also beta 9, will post another beta-savegame in that thread too.

Posted: **04 May 2007 12:16**

Certain vehicles in the grf I'm working on have started crashing TTDP when I have experimentalfeatures.extradetails turned on and I click the "information" button. I can provide the grf for testing if requested.

Edit: a crash log courtesy of my laptop.

Posted: **04 May 2007 19:07**

Dalestan:

Please check your 1501 merge, it crashes on getplayerinfo.gotwindow
eax is broken there...

Surely my code for the extra details is not perfect but accessing window structures in the vehicle code is wrong.

Please don't try to find a Window somewhere in vehicle callbacks, trying access the gui in a callback is surely not the right way and can fast break apart. To be honest I would even say accessing the gui is always forbidden.

PS: While my next commit will help solves the problem by using the real vehicle consist as data source, still I had it once crashed again at that function while I had two detail window open and had a year change...

Posted: **05 May 2007 05:06**

eis_os wrote:PS: While my next commit will help solves the problem by using the real vehicle consist as data source, still I had it once crashed again

And you're not feeding me a crashlog because...?
(Actually, I'd really be happier with 64 dwords of stack, not just the 32 you get out of a crashlog.)

The only two named memory locations I know to check in the preceding code are [human1] and [curplayer]. [human1] is obviously Wrong, which leaves [curplayer]. And believe me, if [curplayer] was reliable when generating variable 43 in the purchase window, I would have used it. Gladly. Or, more accurately, I would have left well enough *ALONE*. But I made those changes because [curplayer] *wasn't* reliable. [curplayer] is correct only if the game is paused. If the game is not paused, [curplayer] is always 7, regardless of which player's purchase window is open.

Since you obviously have no desire to share the appropriate solution with us mere mortals, feel free to fix the code yourself.

Posted: **05 May 2007 07:45**

Because it again crashed on the same function where eax is broken. I don't know when, where or why your code get called. As I said, I didn't solve any code, I only changed it so it isn't used anymore like with the new vehicle available message, but passes the vehicle structure. This solves problems with wrong info with callback 36 changes

Neither did I say I have a solution, because I haven't written your code piece! (If you see my commit, you can see exactly what I change)

I can only do guess work, as it still happens in year change, my psychic debug powers tell me that your code aswell doesn't work correctly when the new vehicle available message is displayed. (As I said I used this way of calling before the change - the same way as the new vehicle available message would do it). So If you debug it, grab pb_nars (better ask Pikkabird who actually discovered the bug), it will crash aswell. undo my change in code and use the detail info for better debugging.
I can only fix something a) I have written it myself, b) know what it does and is fixable. Again. I still consinder my old or new code to be working correctly. And it seems it has more or less before you did change the relevant code piece I mentioned...

It may be a bug in grf codeing by Pikkabird still TTDPatch shouldn't crash.. atleast it didn't before...

Posted: **05 May 2007 15:02**

eis_os wrote:Neither did I say I have a solution, because I haven't written your code piece!

At vehsprit.asm:1617, al must contain the player number, or FF if there isn't a player. I don't care how you do it, just so long as you don't use [curplayer] or [human1], for reasons I've already covered. And you can't use a vehicle structure, of course, because there isn't one.

eis_os wrote:I can only do guess work, as it still happens in year change, my psychic debug powers tell me that your code aswell doesn't work correctly when the new vehicle available message is displayed.

Well, your psychic debug powers are so great that my computer refuses to crash on a year change (with two vehicle detail windows open, both set to information). It seems my computer is afraid you'll watch it crash and figure out what's wrong. (r1545. I don't care what it may or may not have done in r1544. If it doesn't misbehave in HEAD, it's not broken.)

eis_os wrote:Again. I still consinder my old or new code to be working correctly. And it seems it has more or less before you did change the relevant code piece I mentioned...

It did not work correctly. So I fixed it in 1479. And again in 1497 and 1505.

Code: Select all

< DaleStan> Pikka: [curplayer] isn't containing what I thought it did. I think if you test in [r1405 through r1478], you'll find that in the purchase list, nn of var 43 always contains 0.

Posted: **05 May 2007 17:07**

If it doesn't crash anymore then all is fine... I will keep an eye on it... still the problem isn't resolved internally but simply not triggered anymore... I tested now again 2 hours of new vehicle news messages with nars, I don't get a crash...

Posted: **05 May 2007 21:20**

Well - I get this for alooong time now.

Why are resizable depot window/train list etc so unbearably slow? Is there a possible fix for this?

I mean - it can produce a performance hit on 2GHz computer...

Posted: **05 May 2007 21:29**

You're going to have to be more specific with version numbers, test results, config file, etc.

I run (a deplorably slow) 1.6GHz P4 machine, and can detect no major performance hit from using these two features. (Actually unpausing the game brings CPU usage to 100% at reduced framerate).

Note that if your morevehicles setting is excessively high, performance hits such as these may be encountered.

JGR

Posted: **06 May 2007 16:55**

Well the version would be "it is like this for ages" ie - my current build is based on [EDIT]Nightly[/EDIT]148x and it is still there.

Basically - whenever I open train depot window or train list the game starts to get choppy. The effect is the same on 1.5GHz CeleronM, 1466mhz AthlonXP and 2GHz opteron.

The bigger is the window - the bigger the slowdown. Ill post my cfg asap (once I get it from my home computer)

Posted: **06 May 2007 17:07**

The alphas have never even hit triple digits, much less quadruple. You might want to check your version numbering again.

Posted: **06 May 2007 17:12**

Are you always this picky? I meant nightly 148x

Posted: **06 May 2007 17:22**

uzurpator wrote:Well the version would be "it is like this for ages" ie - my current build is based on [EDIT]Nightly[/EDIT]148x and it is still there.

What's the earliest build the problem appears in? If your current build is "based" on a nightly, does that mean you've modified it, and if so could it be your own code that's slowing it down?

Posted: **06 May 2007 18:09**

It is there as long as I remember - which dates all the way back to when the feature was introduced. I have just always forgotten to report it.

Posted: **06 May 2007 20:03**

uzurpator wrote:It is there as long as I remember - which dates all the way back to when the feature was introduced. I have just always forgotten to report it.

I have encountered this "problem" too, also first when it was introduced (for me, that was when I changed from 2.0r1 to 2.5b). The bigger the window, the more "bucking"[*] the application is. But as this is also the case when I have many vehicles visible on-screen, and / or many vehicle info windows open, I explained it to myself with the high numbers of vehicles in the enlargened train window (they are all animated).

I assume that the code which generates and animates the trains inside the train window hasn't changed by the implementation of the feature to resize the window, and it's just a scaling problem.

So if it's too annoying, reduce the window size a little (or close a few other animated windows).

[*] I don't know the correct translation for the German "ruckelig" - it's when an application is taking so much cpu time that the mouse pointer is not moving fluently any more, but stopping shortly every few tenths of a seconds or so.

Posted: **07 May 2007 10:19**

aahz77 wrote:bucking

is sticking the word you were looking for?

Transport Tycoon Forums

2.6 nightly/alpha discussion