[HRQ] ES64U Taurus (1016/1116/1216)

Ohho sehr schöne Bilder, das Modell der 1216 ist echt sehr schön gelungen, dass muss man schon sagen, sie gefällt mir auch besser als die 10 und 1116er

Der Sound ist leider auch nur bis ~45 km/h authentisch, danach ist's einfach der Sound einer 10/1116. Naja, ist ja noch nicht fertig

I've contacted the HRQ team and we are working for include this repaints in the next update of installer

So ... jetzt ist se fertig

Ahh ich liebe die RTS-Lackierung, neulich in Linz HBF hab ich eine 2016 und 1216 von RTS mit einem Benzolzug gesehen!!

Schöne Repaints!!

Ja, das liegt an der inkompatiblität der Repaints mit der neuen Version des HRQ-Taurus !

Es gibt aber ein Patch auf der Website von DW-Angency.de unter Downloads -> Diverses

Danach sollte es eig. laufen !

Nächstes Projekt meinerseits wird sein
ÖBB 1216.050 Weltrekord Taurus

werds dann hier zeigen .....

Ist eigentlich schon mal jemand aufgefallen, daß die superhellen Scheinwerfer der Taurus bei Lichtsignalen ungültige Signalbilder erzeugen? (Alle Lampen sind dann scheinbar an).

PS: Habe kürzlich die Hercules in den oben beschriebenen Skins herumfahren sehen.

Very nice!
Some weeks ago, I saw the "175 Jahre Eisenbahn" in Munich.
The picture was taken in Munich, right?

Keep up the good work!

Guter Plan!
Ich nehme das in die Hand.

Edit:
Erledigt
EMail ging gerade raus mit folgendem Inhalt:

Zitat

Hello
During the time many very nice repaints were created for the ES64U2.
A lot of them are not (yet) bundled with your addon, but are available for example at rail-sim.de and probably other sources:
http://rail-sim.de/railsimnew/…64f4-e189-eu45-4-0-ts2013
http://rail-sim.de/railsimnew/…loks/1280-hkx-taurus-pack
http://rail-sim.de/railsimnew/…int-paket-1-es64u2-taurus
http://rail-sim.de/railsimnew/…int-paket-2-es64u2-taurus
http://rail-sim.de/railsimnew/…oks/1141-taurus-skin-pack
... and more are in development.

So maybe we are going to get a problem in the near future.
The blueprints.pak is just now already huge with a size of ~2 MB if all those repaints are installed and is still growing.
So we users (your customers) at rail-sim.de would like to ask you if it's possible to make a new folder for the ES64U4, so the blueprints of the new Taurus will create its own blueprints.pak?
You could name it for example "HRQ/Taurus2" or something like that to prevent further increasing of the only blueprints.pak for all Taurus' if you only need one type of it in a scenario.
A very bad example of mismanagment is RSItalia, which has all its hundreds addons in only one subfolder installed with only one very huge blueprints.pak. This very big blueprints.pak will cause a lot of problems and even crashes because of massive use of memory, even if you only use just a single type of a locomotive in a scenario.
Please do not make the same mistake and plan your strategy of a folder hierachy more ressource friendly by splitting every type of addon in an individual subfolder:
HRQ/Taurus
HRQ/TaurusXY
HRQ/Tea
HRQ/Coffee
HRQ/... and so on ...

A very good example is virtualRailroads: You can exactly and precisely activate every single wagon or locomotive you need, which uses as less memory as possible.

Please tell me your oppinion about this suggestion, so I can inform the users of rail-sim.de accordingly.
We are all very interested to keep the folder hierarchy of assets as slim as possible!
Benefits:
- Less usage of memory
- therefore less crashes
- faster loading of scenarios
- increased use of your addons, because less problems compared with others (f.e. RSItalia)
- side effect: advertisement for you, caused by increased usage of your addons in scenarios
- happy users and probably more customers

Thank you very much for reading,
and kindly regards,

Alles anzeigen

Ich informiere hier natürlich über die Antwort.
Danke dw-agency für den nicht unwichtigen Hinweis.

Währe aber echt ratsam, wenn sie die Ordnerstruktur überarbeiten würden, sonst wird der irgendwann mal so groß und problematisch wie bei RWItalia

Hier kommt die Antwort.
Ich werde versuchen, sie möglichst authentisch zu übersetzen, damit niemand den Salat von Google-Translate verkonsumieren muss.

Zitat

Hi

I was playing and developing for this game since railworks 1 was released,
and watching forums like uktrainsim, but i've never heard about this theory.
Blueprint.pak files are meant to cache the frequently used information of
blueprints (type, name), so the game don't need to read the real blueprint
files, if it's not necessary, other parts of the file are seem to be just
junk, remained from the early stages of development (there are a lot of
unimplemented features have traces in the blueprints).

When you load a package in scenario editor, only the content of the
blueprint.pak is loaded (which is just few mbytes/kbytes for each package
that doesn't matters todays when the pcs have gbytes of memory). Other,
bigger parts(3d model, textures) loaded only when you actually place the
the object in the game world. But that would happen anyway in every game
engine, even if those are in seperate packages.

That blueprint filtering is only a cosmetic thing, to make the object lists
less populated, by not displaying those packages in the lists, which are
not selected.

Loading times are mostly depending on the complexity and quantity of the
objects, that are actually placed in the game work, not by the quantity of
the loaded packages or the objects in it, same true for the memory usage.

So i just tried this, by loading a lots of things in scenario (Kuju
contents, Kuju US content, munich augsburg, SAD contents, WCML north,
sherman hill, etc. about 9 gbytes of addons). The loading times were a bit
higher (because the game needs to check these loaded packages if anything
changed), but just twice as long(on a bigger route it wouldn't be so
noticeable, as the most of the loading time would taken by loading the
textures and models, only a small part would be to check the blueprint),
and it would be the same(or more) if these were in more but smaller
packages.
But the memory usage was exactly the same as when only Kuju contents were
loaded.
By the way, the Kuju/RailSimulator package which is used in Hagen-Siegen,
Seebergbahn, Newcastle-York, GWML and other old routes, have nearly 9
mbytes sized blueprints.pak file.
Seeing other blueprint.paks, that 2mbytes is actually an average sized pak

I've seen those RSitalia problems, and SBHHs, but all of them were caused
by missing files, and by the changed file structure policy of RSC which
also caused missing file errors, because the repaints referenced an old
file, which is not there anymore where it was.

That's why making different packages for repaints, wouldn't solve anything,
as the problem lies somewhere else. Moreover it would increase the memory
usage, as now in same package the common textures (bogie texture, glass
texture, light textures, and some of the blueprints, and script files too),
are loaded only once and shared between all of the locos. In different
packages, each of these textures should be supplied again and again, and
the game would load these multiple times, if the locos that are using these
are placed in the game world.

At scenario editing all of the crashes are caused by the general
instability of the game. Some of them because of the scenario is restarted
too many times, without restarting the whole game, but the most of the
crashes caused by the dispatcher ai, which is usually makes the game crash
if it can't solve a traffic situation

Alles anzeigen

Verstehe das auch nicht, was ist daran so schlimm die Ordentlich zu Strukturieren ?

Hier mal der Vorgänger der heutigen 1216.050 Weltrekord Taurus ...