Transport Tycoon Forums

Iron Horse 1.5.0 on bananas or http://bundles.openttdcoop.org/iron-horse/releases/

-------------
1.5.0 Release
-------------

*New Features / Changes*

- balanced loading speeds for all vehicles
- tank, hopper, covered hopper and intermodal cars load twice as fast as other types
- metro trains load twice as fast as other passenger trains
- clay cargo sprites for open and hopper cars
- more cargo sprites for supplies cars
- more cargo sprites for narrow gauge flat cars (timber, lumber, metal, tarpaulins)
- most text now translatable

*Language Updates*

- af_ZA (telanus)
- ca_ES (juanjo)
- de_DE (planetmaker)
- en_US (Supercheese)
- es_ES (SilverSurferZzZ)
- fr_FR (arikover)
- hr_HR (Voyager1)
- la_VA (Supercheese)
- nl_NL (Alberth)

Just downloaded the source and tried to compile but I'm not having any success...

- compiler defaults to multiprocessing *off* instead of *on*, to avoid DoS-ing people's systems

I think I'm getting this exact error during the 'make'. I'm not sure where to look to maybe fix it. I have compiled other newgrfs so I'm not a complete novice, just 'nearly' a complete novice.

I was hoping to incorporate the paper bale graphics as it's a real pain to see the anonymous brown cubes on flatcars...indistinguishable from goods! It's almost certainly beyond my capabilities but I wanted to have a try.

Regardless, this is becoming my regular train set and I like that it disables the other sets (monorail/maglev) so I'm not tempted to try and upgrade.

DoS-ing a system does not come as error, it means your system just becomes terribly slow to the point of not working any more.
Perhaps you should open a new topic, and post about the problem you have?

3iff wrote:

- compiler defaults to multiprocessing *off* instead of *on*, to avoid DoS-ing people's systems

I think I'm getting this exact error during the 'make'.

Nah. If you try and compile the 1.5.0 tag (or newer), then the multiprocessing is disabled unless you enable it explicitly. All the multiprocessing does is run part of the compile much faster (using 16 simultaneous processes instead of 1). It's disabled because it can make your system unusable for maybe seconds or minutes or so by grabbing all your CPU.

Paste the error(s) here, most common problem is missing python libraries, but might be something else.

I understand DoS...yes my system does grind to a halt.

I'm getting LOTS of the following during the make...

Traceback (most recent call last):
File "<string>", line 1, in <module>
File "c:\utils\python\lib\multiprocessing\forking.py", line 380, in main
prepare(preparation_data)
File "c:\utils\python\lib\multiprocessing\forking.py", line 495, in prepare
'__parents_main__', file, path_name, etc
File "c:\utils\ottd\iron horse\src\build_iron_horse.py", line 19, in <module>
render_graphics.main()
File "c:\utils\ottd\iron horse\src\render_graphics.py", line 59, in main
pool = Pool(processes=16)
File "c:\utils\python\lib\multiprocessing\__init__.py", line 232, in Pool
return Pool(processes, initializer, initargs, maxtasksperchild)
File "c:\utils\python\lib\multiprocessing\pool.py", line 159, in __init__
self._repopulate_pool()
File "c:\utils\python\lib\multiprocessing\pool.py", line 222, in _repopulate_pool
w.start()
File "c:\utils\python\lib\multiprocessing\process.py", line 130, in start
self._popen = Popen(self)
File "c:\utils\python\lib\multiprocessing\forking.py", line 258, in __init__
cmd = get_command_line() + [rhandle]
File "c:\utils\python\lib\multiprocessing\forking.py", line 358, in get_command_line
is not going to be frozen to produce a Windows executable.''')
RuntimeError:
Attempt to start a new process before the current process
has finished its bootstrapping phase.

This probably means that you are on Windows and you have
forgotten to use the proper idiom in the main module:

if __name__ == '__main__':
freeze_support()
...

The "freeze_support()" line can be omitted if the program
is not going to be frozen to produce a Windows executable.

That's just a snippet. I eventually have to break the make and no files are produced. I'll give it a long run to see if I'm just being too impatient.
Any suggestions.

-------------------------

I ran the make for 20 minutes with no result (I terminated it eventually). No files generated. Python had about 15+ subprocesses running at a time and CPU usage went to near 100%.

File "c:\utils\python\lib\shutil.py", line 250, in rmtree
os.remove(fullname)
[Error 32] The process cannot access the file because it is being used by another process: '.\\generated\\graphics'
pool = Pool(processes=16)
File "c:\utils\python\lib\multiprocessing\__init__.py", line 232, in Pool
os.remove(fullname)

and

[Error 5] Access is denied: '.\\generated\\graphics'

3iff wrote:I understand DoS...yes my system does grind to a halt.'

Thanks, that looks exactly like a known python issue with multiprocessing on Windows

I thought I'd put the fix in place for the issue, but apparently not.
Need to wrap the Pool functions in '__main__', as per the error message you pasted.
https://docs.python.org/2/library/multi ... cess-class

If you want a workaround and are happy to edit src/render_nml_nfo.py, try setting 'use_multiprocessing = False' around L23 or so. I might have made a mistake with the logic there. If you're feeling more adventurous, remove the multiprocessing import and the calls to Pool around L27 (or try setting the number of pool workers to 1, instead of 16). That doesn't solve the Windows problem, but might isolate it.

Or try putting in the proper fix (I will add it later, but I don't have a Windows system to test on).

I'm happy to try editing the files. I'll give the suggestions a try and report back. Thanks.

=======

No joy. I've tried everything you suggested and quite a few other things. I did get everything to generate - except for the graphics files (.png's) and then it failed because they didn't exist.

So, nothing more I can do...I don't know anywhere near enough python. There's absolutely no rush on this so don't make a special effort to sort it out. I can happily continue using the regular version.

Thanks for your efforts.

3iff wrote:I did get everything to generate - except for the graphics files (.png's) and then it failed because they didn't exist.

Eh, there's probably another multiprocessing call for image generation (makes it waaaaaaay faster).
...
Yeah, it's in render_graphics.py and there's no flag to disable it. That needs sorted. You could probably hack around it by copying a similar loop as render_nml_nfo.py.

Otherwise wait for me to get to it. Conveniently FIRS is in a 'no new features' rewrite at the moment anyway, cleaning up some dubious ideas.

andythenorth wrote:Eh, there's probably another multiprocessing call for image generation (makes it waaaaaaay faster).
...
Yeah, it's in render_graphics.py and there's no flag to disable it. That needs sorted. You could probably hack around it by copying a similar loop as render_nml_nfo.py.

I did see one or two likely candidates and tried a few things (copying from the other render file as you mentioned) but python is too snaky for me to comprehend...I can wait.

Iron Horse 1.6.0 now on bananaas and such.

-------------
1.6.0 Release
-------------

*New Features / Changes*

- metal cars (3 generations)
- caboose car for narrow gauge
- '0-8-0 Collier' is now '0-10-0 Big Bertha' with even more TE (it was already high, now it's insanely high)
- refit support for FIRS Beans and Nitrates cargos
- all tank engines now have randomised forward/reversed sprites (random when built in depot)
- improved sprite shading for some box cars and flat cars
- improved sprites for some metro trains / wagons

*Fixes*

- box cars now have capacity > 0 when refitted to mail

*Language Updates*

- multiple languages
- translator credits http://bundles.openttdcoop.org/iron-hor ... redits.txt

*Codechanges*

- compile now uses python 3 not python 2
- compile now requires nml 0.4.0 or newer
- refactored compile scripts, keeping pyflakes happy, and not relying on weird magic related to python imports

andythenorth wrote:- '0-8-0 Collier' is now '0-10-0 Big Bertha' with even more TE (it was already high, now it's insanely high)

Does it have the headlight!?

1.6.1 now on bananaas or http://bundles.openttdcoop.org/iron-horse/releases/

Changelog
=========

*Fixes*

- Big Bertha tractive effort was a little too low
- 2nd generation reefer car sprites were out of position

*Language Updates*

- dutch
- translator credits http://bundles.openttdcoop.org/iron-hor ... redits.txt

It's Wunderful!
But its incompatible to to the kanadan city and the kanadian train stations.
BW89
Sry for bad English
I'm a Ideot

No, it's the other way around.

The author of the Canadian NewGRFs added specific code with no other goal than to make it impossible to use them in combination with FIRS and OpenGFX+airports.

Now, this might sound a little bit silly, but would it be possible to have a Parameter for IH which would disable the locomotives but retain the rolling stock? I'm currently running one of the UK newGRFs which has plenty of locomotives, however I'd like to run with a better choice of rolling stock, simply for the sake of my eyes (a 7 TL long train of box cars is very bland).

I understand if you don't think it's a good idea though

Yours,
Buragan

Buragan wrote:I understand if you don't think it's a good idea though

Just use the 'hide' feature in the buy menu, as provided by OpenTTD

*bonk* Forgot about that! Thanks, hehe.

Edit: Possible bug while using FIRS and IH on Android. Engineering supplies did not appear on the supply wagon rolling stock.

Buragan wrote:Edit: Possible bug while using FIRS and IH on Android. Engineering supplies did not appear on the supply wagon rolling stock.

Can you get a screenshot?

Moar Horse. 1.7.0 now on Bananas or http://bundles.openttdcoop.org/iron-horse/releases/

-------------
1.7.0 Release
-------------

*Features*

- scrap metal cargo graphics for hopper and open cars
- tank cars show different livery depending on cargo refit

*Fixes*

- all vehicles were 1px out of position for North-facing \ and / views
- Cargo Sprinter sprites were broken in multiple ways
- Cargo Sprinter weight and vehicle length were wrong
- Little Bear, some sprites were 1px out of position
- narrow gauge mail car, some sprites were out of position and/or too high
- bad purple pixels in Tin Rocket and narrow gauge open car
- tweaks to Slammer \ and / views
- covered hopper car was out of position

Great! Love using this set!