maximal paksize + where are these stations?

[SaschaPascalS]

Well, Prissi, that's the reason why I asked for what I could change for my personal SimutranSP-Version in the code to have a Simutrans for more users on the first hand, because I know, it's free software and if you want something special, that perhabs for the mostly rest of the players is not needed or wanted, you can have your personal spinoff (I even wouldn't publish it, because it's personal). On the second hand I asked, if perhabs for the future there could be found a GOOD way to handle bigger sizes paks, because I see, that in the future perhaps the standard paksets could get so detailed and big, that you could not use as many addons as you want (what is one of the great features, that I like with Simutrans, inspite of e.g. Transport Gigant oder similar not so free programs). It's not, that I would say: WE MUST, and I will e.g. test the version markohs compiled for me, what effects it will have on gameplay.

The funny thing is, that you all always argue with the TRAINS. I also know by my gaming experience, that the trains are not really good intermixable, as you said, because of the different alignment-points of the sets, but e.g. intermixing the buildings (my buildings-folder of Pak128db, where all the buildings of the sets, I found, are together organized (I could explain the system, if you like), is over 550 MB big, the pak128db WITHOUT trains and where I have put out ALL the buildings etc., which have been rebuilded in the last time (e.g. RES_01_01 in vers. 5, vers. 7 is actual)), ways (especially the roads and monorail/maglev/water ways, in some degree also the tracks, because the roads are quite standardised and the special systems are mostly only made for one specific train set), citycars, trees. Pak128db is quite 1 GB big and I now try to build a pakset (without the trains), to see how big a intermixed set only consisting of the buildings, factories (I've seen, that there are some differences, I'll try to build a factory-system, that is consistent, but has all needed goods (for etc. NOT the vegetable2-5 of pak128.japan) for a realistic big world), trees, city cars, ways, waysigns and so, how big it will be in MB and images.

As I said, my approach of gaming is building a big world, a world simulation, if I would for e.g. want to play a network game, I would of course stick on the original sets.

One thing to pak128.japan. It seems, that there are TWO nowadays ways, they draw it. The most trains, you can for etc. download at japanese.simutrans.com are same size as Pak128, even the modern ones, but there are some trains, mostly by Yoshi, that are painted much bigger, for a specific Pak128.japan. And, I'm always talking about Pak128. Not Pak64.Japan, because I prefer to play Pak128, more details (as you have experienced, I like it detailed ). I know, in Pak64 intermixing is much more problematic, because the size is smaller and so the differences bigger.

Too the Japanese-Real Point Rails: I mean the ones found here, quite new (december 2012): http://japanese.simutrans.com/index.php?Addon128%2FRailTools%202 (the first addon download), I don't know, for what I need them, the old package also works. I would be pleased, if somebody could translate the japanese description, I can't read japanese and google only brings garbish as translations.

[prissi]

The japanese wiki (addon) page has two download categories: pak128 and pka128.japan, because of the size issues.

And about non-trains: There is a Hongkong map around which has more than 300 Busses as addons and almost any building produced untiul 2009. I can positively say that those are way to many to be handled meaningful with the current depot. That would require a filter option.

[SaschaPascalS]

The japanese wiki (addon) page has two download categories: pak128 and pka128.japan, because of the size issues.

Yes, thats the reason, why I normally don't use the Pak128.Japan-Paks (only the Buildings, that are not in Pak128, for etc city buildings), but the trains in the Pak128-category. But even if I do so, I reach the Pak128-Limit. (Also because PakBritain (also a different size, the tracks are a bit SMALLER as the ones from Pak128, but a pixel higher over the ground) has much buildings, because for etc. Pak128 and Pak128German has really few NICE looking one family houses, they look (even the PakGerman ones) more like US-Simcity-inspired than German or Austrian Buildings, and the majority of "authentic" City Buildings in PakGerman are only for Tundra, MGB and polar zone.

And about non-trains: There is a Hongkong map around which has more than 300 Busses as addons and almost any building produced untiul 2009. I can positively say that those are way to many to be handled meaningful with the current depot. That would require a filter option.

Well, the depot itself is really a pitty, if you have quite much trains or busses. Fine, it's sorted by number of passengers, but even if you like, you cannot change this into "sort by name", because then I for etc search for the JRE 233-500, I have to look through the whole depot, because you cannot know the passenger-size of any train in simutrans If it would be sortable by Name, it would be a bit easier, you only would have to look in 233 or J (unfornatunaly there seems to be no rule how to name the trains). And there is no search function, which would make it much easier. And then you have as you correctly mentioned 200 "Alexander"-Busses, where only the color and size of the busses change. (Why they don't build now much of the nice Skyscapers of Hongkong, I don't know, would be sometimes quite funny do build up a real Hongkong.)

It seems, like simutrans now begins to get to the borders of it's nowadays design, when you began to program it, prissi, you were glad to have quite 100 building, stops and some trains, nowadays the enthusiasm of the simutrans-fans (especially in east asia, a student collegue of me from Japan also knows simutrans, you have produced the Vocaloid in trains, it seems) is so high and produces so much buildings, that we get a problem with it.

[Ters]

Another example of how everyone has their own opinion of what Simutrans is about. pak64 has only 251 buldings, not including factories. I have never seen the need for any more, even though at times I have found one type of building very dominating (usually right after its introduction date I think). I'm into Simutrans for the logistics aspect and it is therefore not in my interrest to alter Simutrans in any way that may hamper performance without improving the simulation. That's just my wish, for what it's worth.

From a technical standpoint, more images makes it more difficult to utilize hardware acceleration (which Simutrans doesn't today, but which I'm looking into as especially Mac's seem to take a dislike to Simutrans' old-school rendering). The GPU likes to render one million identical houses, and hates to render one hundred different houses. In a full 3D version of Simutrans, we would free up some images by not having up to eight different images of the same thing from different directions, but that is a long long way away.

[SaschaPascalS]

besch/bild_besch.h

Code Select Expand


struct bild_t {
   uint32 len;
   sint16 x;
   sint16 y;
   sint16 w;
   sint16 h;
   image_id bild_nr;   // Speichern wir erstmal als Dummy mit, wird von register_image() ersetzt
   uint8 zoomable; // some image may not be zoomed i.e. icons
   uint16 data[];
};


simimg.h

Code Select Expand


typedef uint16 image_id;

#define IMG_LEER ((image_id)0xFFFF)


simgraph16.cc

Code Select Expand


void register_image(struct bild_t* bild)
{
    struct imd* image;

    /* valid image? */
    if(  bild->len == 0  ||  bild->h == 0  ) {
        fprintf(stderr, "Warning: ignoring image %d because of missing data\n", anz_images);
        bild->bild_nr = IMG_LEER;
        return;
    }

    if(  anz_images == alloc_images  ) {
        if(  images==NULL  ) {
            alloc_images = 510;
        }
        else {
            alloc_images += 512;
        }
        if(  anz_images > alloc_images  ) {
            // overflow
            dbg->fatal( "register_image", "*** Out of images (more than 65534!) ***" );
        }
        images = REALLOC(images, imd, alloc_images);
    }
....


image_id type is used and made part of many simutrans inner structures. Increasing it to a 32-bit value will give enough room for every player. It will also increment the memory imprint of most simutrans data structures. I'm unable to weight if this whould cause a significant performance decrease in the game or not, other developers will know way better than me about this.

If you want to turn the counter to 32-bit I'd say only this change in simimg.h is needed:

Code Select Expand


typedef uint32 image_id;

#define IMG_LEER ((image_id)0xFFFFFFFF)


But didn't tried it much, I just changed it and all seems to work good (compiles and generates an executable, but don't have a pak with so much images to try, let alone to measure performance).

But as I said, I'm unable to know if it's worth changing or not, other developers of simutrans have the last word on this, not me.

EDIT: I generated an executable for you to try if you want to see if it worked or not.

*WARNING* This executable might work or not, might destroy your saved games, your simutrans installation or even drink the beers from your fridge, I have no responsability of what could happen.

You will prolly require to install this in your computer to be able to execute it properly:

http://www.microsoft.com/en-us/download/details.aspx?id=30679

The binary:

https://dl.dropboxusercontent.com/u/30024783/limit/Simutrans_limit.exe

Also bei mir meldet er, nachdem ich die vermissten dlls pthreadVC2.dll und mscvr80.dll ins Verzeichnis kopiert habe (die er trotz des MS-Downloads vorher nicht installiert hat):

"Runtime Error!

Program: C:\...\simutrans_limit.exe

R6034
An Application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information."

"Die Anwendung konnte nicht gestartet werden (0xc0000142). Klicken sie auf "OK", um die Anwendung zu schließen."

System: Windows 7 32 Bit, AMD Athlon 64 X2 TK55, 2 GB Ram

[greenling]

Hello SaschaPascalS,Markohs
On my Loptop work the Simutrans_limit.exe without problems now!
I have from the link http://www.microsoft.com/en-us/download/details.aspx?id=30679
the Visual C++ Redistributable für Visual Studio 2012 Update 1 for Windows 7 64bit downloaded
and have then install the vcredist_x64.exe on my laptop install.
Then have i create a new folder for the Simutrans_limit.exe and move the Simutrans_limit.exe in it.
Then have i the complet data out the sdl nightly zip that on the 15.5.2013 came out, copy in the folder.
I have then the pak128.britain nightly pakset from the 24.04.2013 be copy in the folder from Simutrans_limit.exe.
At the first start of the Simutrans_limit.exe came than a report from windows 7 that's the pthreadVC2.dll not give.
Than have i with google search the pthreadVC2.dll and have then the pthreadVC2.dll downloaded and have then
the file move in the folder with the Simutrans_limit.exe. After then have the Simutrans_limit.exe without problem work.

[SaschaPascalS]

Well, I use for first instance Windows 7 32 bit (as written). But I did it that way and it didn't worked.

Funnily too: My Pak128akt don't work with the actual game versions... it crashed when I try to build maglev, monorail or tram tracks, also airport, but NOT when I try to build roads or water... in a pakset where I have exactly the same configs, menu files, symbol files, cursor files and ground files everything works fine...

(Trains are not yet included, as well as no buildings in the pak yet)

[SaschaPascalS]

Ok, interesting bug: If you haven't put ANY way.track into your pak, than monorail, tram, airport, maglev and narrowgauge-track building will lead to a program crash...

[Ters]

The bug is not having any waytypes for defined tools. Simutrans doesn't check for every possible thing that might be wrong if someone has tampered with its internals. It's deliberate, probably because writing error checking is boring and developers just want to play what they written, not write more code they don't need. The same applies to documenting the code, and it not only applies to Simutrans.

[SaschaPascalS]

Well, of course, and when the "workaround" is as easy as putting a "placebo" way.track-file into your pak it's not needed to recode, there you right.

Edit: So, Pak128akt is quite big now: 58050 Images. included in the Pak are bridges, buildings, cursor, citycars, grounds, ground_objs, menu, misc, symbol, roadsigns, tunnels, ways, way_objects, pedestrian and trees. Not included yet are factories, goods and fields as well as any train. Of course the pak is cleaned of double objects as well as it has the most modern versions of the objects.

I packed it together to show, that a pak, where you really have not yet meet the obstacles of cars and trains running on different pixel-tiles, but only to build the world out of streets, tracks, buildings and enviroment, with SNFOS, the japanese buildings and ways (and here NOT included the real point tracks, cause I don't know the effect of having 5 types of the same track type only with a cursor in different directions) and the buildings and roads from pak128britain and pak128german, you are near to the border. If I now put in a working factory system into the pak, I meet the 65k border without ANY train pak put into the pak yet.

[greenling]

Hello SaschaPascalS
Can you speak German?
If you can talk it, write me a PM.
So that I can tell you why your simutrans limit.exe and thy pakset is stuck.

[Markohs]

So simutrans_limit is able to load more than 64K images, greenling?

[SaschaPascalS]

@greenling: yes, I'm natively german speaker.

64027 ist my last image number in my pak now, only without any trains