Transport Tycoon Forums

sidew wrote:

quba wrote:I found a small bug, in normal OTTD you can use dbset-xl in subarctic climate when combined with alpinew.grf, in this mini, it seems to work good except for food carriages. It is simply impossible to reffit them.
I didn't have time to read whole topic, so if it is know sory for disturbing.

I have the same issue using US Set with tropic climate: I can't refit the tankler carriage to water carriage.

Using normal trunk there no problem refitting them.

It seems this is my fault. This bug was introduced with my Livery Refit/Cargo Subtypes patch. Thanks for reporting it. Here is a MiniIN patch that corrects the error.

Just compiled the revision 5450,
loaded a savegame from revision 5402 and...

I did not change the values in my savegame.
When I start the game and open the economy config
the years appear as they are supposed to.

Another thing is when I first loaded the savegame
the station spread was set to 1 (40 before)

klogg

klogg,

It'd probably help if you posted the savegame as well. Speed things up a little.

-Hazelrah

Of course.

I started this game with revision 5402 + powerful industry patch.
Now I saved it with revision 5450 + pip.
The error is still there.

klogg

klogg wrote:Of course.

I started this game with revision 5402 + powerful industry patch.
Now I saved it with revision 5450 + pip.
The error is still there.

klogg

Powerful Industry patch is *not* supported (yet), because it affects the savegame format... which is your problem I believe... the data boundaries have got mixed up, and unpredictable dates have resulted.

By creating your own compiled version, it is very unlikely we can replicate your error. But since, PIP is not yet in MiniIN... its not my problem (for once!!).

gigajum wrote:So here is the fix SirkoZ requested.
I also fixed the wrong set brackets from RichK to reenable "max vehicles at station"
I also removed som unused language lines.

Thank you very much - I realise now I might have been bit a bit on an alert side , but I really like that "service at" order to have system in order.
I also like your percentile patch. Good work!

I have finished modifying my queue patch to work with the MiniIN. The queue patch for MiniIN can be found
here.

The original patch for the trunk is on the first post of that thread.

There is a small bug in the convertion from normal rail to monorail. Only the engine will be replaced, the waggons stay the same.

So if i want to clone such a train this isn't possible.

gigajum wrote:There is a small bug in the convertion from normal rail to monorail. Only the engine will be replaced, the waggons stay the same.

So if i want to clone such a train this isn't possible.

I think its a lack-of-feature, rather than a bug - the original patch cannot do this either. Hopefully the patch author can update the patch with this extra function.

richk67 wrote:

gigajum wrote:There is a small bug in the convertion from normal rail to monorail. Only the engine will be replaced, the waggons stay the same.

So if i want to clone such a train this isn't possible.

I think its a lack-of-feature, rather than a bug - the original patch cannot do this either. Hopefully the patch author can update the patch with this extra function.

Maybe he can also enable converting normal rail waggons to mono (and maglev) waggons, too. Now i sit here and can't continue my MiniIN test game over 170 years, without sending all tains to depot and replace the damn waggons myself or do anything other with them.

something that is bugging the hell out of me (see attachment).

you can't use resoultions above 2048x1200, doing so just cuts it all off, and leaves either black, or jargon.

see link, this is r3863 with max resolution changed to 3200x1600.
http://www.tt-forums.net/viewtopic.php?t=23957

there is a hardcoded limit of 2048x1200, but i do not see any reason why this can't be incresed.

see download link
http://www.tt-forums.net/download.php?id=45146

this apeared to work fine.

my sugestion, either change the variables:
MAX_SCREEN_WIDTH = 2048
MAX_SCREEN_HEIGHT = 1200
in openttd.h to something more "Modern", or make it some kind of value read from openttd.cfg. as you can see in the screenshots in that thread, modern screen resolutions can go as high as 2560x1600 per panel(a regular VGA or DVI port can do 2048x1536, which is higher than what OTTD currently allows. i can run my screen at that resolution, just not in OTTD, which is probably the only place i would use the res because the feature makes use of a movable 1600x1200 window.), and can be used either way up, and duel screening is also very popular now. you can even buy screens with 2 to 6 panels in them.

my sugestion is make them a line somewhere in openttd.cfg, however a default of something higher, like atleast 3200x1600. this allows sideways twinscreening of 1600x1200 screens(which i have) aswell as using them in portrait mode, instead of landscape.

here is a little patch for daylength, it does not correct bugs, but it adds a configure patches option: daylength affect economy

if active, the incomes for all vehicles/trains etc are divided by the daylength multiplier, so in a year you should earn the same money you can earn if you don't use the daylength (set it to 1x)

richk67 wrote:

gigajum wrote:There is a small bug in the convertion from normal rail to monorail. Only the engine will be replaced, the waggons stay the same.

So if i want to clone such a train this isn't possible.

I think its a lack-of-feature, rather than a bug - the original patch cannot do this either. Hopefully the patch author can update the patch with this extra function.

I'll see what I can do... what do you envision ? (a) something similar to the engine-replacement, e.g. selecting a normal coal waggon on the left and a monorail one on the right ? Or (b) automated replacement, e.g. if a engine with coal waggons is to be converted to monorail, a monorail-coal-waggon-type is automatically selected for replacement ? Waggons that can't be converted have to be dropped anyway...

Haukinger wrote: I'll see what I can do... what do you envision ? (a) something similar to the engine-replacement, e.g. selecting a normal coal waggon on the left and a monorail one on the right ? Or (b) automated replacement, e.g. if a engine with coal waggons is to be converted to monorail, a monorail-coal-waggon-type is automatically selected for replacement ? Waggons that can't be converted have to be dropped anyway...

both

I think that it should integrate into the ordinary wagon autoreplace, so that you pick a normal wagon then a monorail wagon.

I think you should also make it so that it won't convert any part of the train (engine / wagon) unless all of the engines and wagons in that train are going to be auto-replaced to run on the same track type. That way you could autoreplace all coal trains to monorail by setting up an autoreplace on the engine and on the coal wagon, and you wouldn't have a load of other trains in the depot with a monorail engine and rail wagons.

richk67 wrote:

klogg wrote:Of course.

I started this game with revision 5402 + powerful industry patch.
Now I saved it with revision 5450 + pip.
The error is still there.

klogg

Powerful Industry patch is *not* supported (yet), because it affects the savegame format... which is your problem I believe... the data boundaries have got mixed up, and unpredictable dates have resulted.

By creating your own compiled version, it is very unlikely we can replicate your error. But since, PIP is not yet in MiniIN... its not my problem (for once!!).

Hmmmm... 5402 is the old version. It uses a uint16 production_rate. The new version (5450) leaves it unchanged (byte). These both are completely incompatible, 5450 does a savegame-bump to introduce the new economy_mode variable, but I had no problems loading pre-pip savegames while testing. To me, it looks compatible to the previous savegame-numbers.
Which data boundaries are mixed up ? Have I missed something (again ) ?

Haukinger wrote:[...] but I had no problems loading pre-pip savegames while testing. To me, it looks compatible to the previous savegame-numbers.
Which data boundaries are mixed up ? Have I missed something (again ) ?

The savegame runs smoothly without problems.
These numbers are obviously wrong but that does not seem to affect the game.
So maybe you just missed the bug when you loaded your savegame...

klogg

Haukinger wrote:Hmmmm... 5402 is the old version. It uses a uint16 production_rate. The new version (5450) leaves it unchanged (byte). These both are completely incompatible, 5450 does a savegame-bump to introduce the new economy_mode variable, but I had no problems loading pre-pip savegames while testing. To me, it looks compatible to the previous savegame-numbers.
Which data boundaries are mixed up ? Have I missed something (again ) ?

Nah - I think the problem is that klogg's old game was saved under 5402+pip (uint16 production rate), and because 5450 has the savegame bump, it regards it as safe to try to load the data. However, the boundaries in klogg's game data are messed up, and so create the duff data.

As I said... PIP is not (yet) supported in MiniIN. Adding it as a patch across changing versions, and then claiming it has a bug, is faulty logic at best. But neither my (MiniIN) fault, nor yours.

klogg: when I said on this "unsupported" it means "dont bug MiniIN with problems you (may) have caused ". PIP will eventually be supported in MiniIN (when I have time - which is no time soon).

Im exhausted at the mo... and finding it really hard to find time for MiniIN. Work is sapping all my braincells, and the next few weekends are heavily booked too.

Can someone with submit authorisation cover MiniIN for the next couple of weeks? There are a few patches and updates to patches that need applying - most are referenced in this thread.

Any volunteers?

Before posting my ptoblem I would like to say what great work you are doing on the MiniIN! Thumbs up!!!

I have a problem concerning PBS: Even though using PBS signals and being able to build them and everything the trains seem not to use it at all, as can be seen on the picture attached: When the short and empty coal-train crossed that PBS-junction, the longer train had to stop even though the other track was free. Shouldn't they cross the junction right next to each other?
You can see on the other direction that the entrance PBS-signal is showing red on that junction the loaded train is crossing - shouldn't it show green because there is another safe way to go?

Do I have a wrong layout or is it some kind of bug?

I'm playing the 5450 Win32 version.

THX!!!