Skip to main content ↑ ↓

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - dantedarkstar

1
Simutrans-Extended development / Re: [6.6] Mess with the distance_per_tile again (or still ?)
That's a great find !

I actually can see this "second factor" for maintenance. Well... even 10 of them :D
Sure, they are derived from main distance_per_tile, but they are separate variables.

And actually this gives the last piece of the puzzle to us !

We know the identity of MBMM. All those cst_* variables are together MBMM.
If you load pre-6.0 save, because of the bug, the maintenance is scaled by CDPT, while later OSF is read as DPT for savegame.
Thus, this gives results exactly consistent with my theory !

Yay !


Now I'll have to start thinking on the hard part of the problem. How to explain even more crazy behavior of my old, old savegame. It was originally created in Simutrans-Standard and then migrated through several older versions of Experimental (2.x through 3.14). The funny thing it behaves differently than plain 3.14 savegame.

But at least the first part is solved !

[Edit:] Actually, after looking at the posted code again, I see some things that might just be responsible for the old old savegame behavior. Would have to think about that though.
2
Simutrans-Extended development / Re: [6.6] Mess with the distance_per_tile again (or still ?)
Well, after incorporating the info that 0.3 scaling factor was present before, just didn't do all it does now, I formulated a working theory and after few calculations it turned out I can explain all maintenance values for new 6.6 and 3.14 games. It sort of explains the revenue and running costs too.

So here's the theory:

Used abbreviations: distance_per_tile value as used in current game = DPT, mysterious building maintenance modifier = MBMM, current distance_per_tile value in config = CDPT, pre-6.0 distance old scaling factor = OSF

Theory:
There are 2 variables that dictate the whole scaling: DPT and MBMM.
DPT affects revenue calculation, running costs and way maintenance.
MBMM affects building costs and maintenance (but not ways).
When you start new game in 6.6, both DPT and MBMM are set to CDPT.
When you load an old game (3.14), DPT is set to OSF=0.3, while MBMM is set to CDPT.
When you modify the DPT in savegame (as I did during testing), it of course affects DPT, but does not affect MBMM at all.



Above theory explains all my test results in 6.6 for new 6.6 games and old 3.14 games (but not 3.14 values in 3.14 games unfortunately). It doesn't touch the my old savegames (I checked, the game contained in them was started in Simutrans Standard, and went through different simutrans experimental stages up to 4.0 I believe), as the behavior of these is still confounding me.
3
Simutrans-Extended development / Re: [6.6] Mess with the distance_per_tile again (or still ?)
Quote from: jamespetts – on
there is only one number for scaling, the distance_per_tile value. There is no other number that affects scaling, and never has been.
Well, then how is it possible that when I load 3.14 game into 6.6 with DPT of 100 I get the same revenue and runnig costs than when I load 3.14 game into 6.6 with DPT of 30, while the maintenance changes ?
And since it's 3.14 game, then these values later on are fixed for these savegames, so they must be saved inside savegame. It doesn't use the value from the config file anymore.

I understand that on a conceptual level there is only one number for scaling, but on the implementation level there are more, or above situation is simply impossible. I'm not saying it's intentional, but the experiment says so.


Quote
I am not sure what you mean here, since loading a saved game does not write anything to any saved game. Do you mean when that saved game is then re-saved in 6.6? It will then write the new values based on the full scaling in 6.6, but using the same scale figure (albeit slightly adjusted) as in < 6.0.
Here, I meant that for example 3.14 loading savegame from 2.3 or maybe even form Simutrans Standard and then re-saving under 3.14.

Quote
No, that is not correct. There is only one distance_per_tile variable in the code. If it loads a pre 2.0 saved game, it will use the distance_per_tile value from simuconf.tab.
I see, so the 30 value that I thought hard-coded was actually sort of transcription of the factor used for journey time for >2.0 <6.0 game. That explains why it's always 30. Still the maintenance costs don't adhere to that, but to the DPT from the config file at the moment the game was first loaded into 6.6. So in the end they get rescaled by different value than revenue and operational costs.


Well, I think I'm beginning to understand the whole thing with sudden revenue etc. changes. The effect of new game with DPT=30 is same as loading 3.14 game with DPT=30 in config. You get the same values. Still, you can never get values as if started with DPT=100 (very close to values present in 3.14) when loading old game. Fine.

Still, there are some problems with the scaling. I'm a scientist IRL. I did the experiment (all the tests) and obtained results. Of course my hypotheses formed on the basis of those results may be wrong, but the results themselves are hard facts.

Well, so the first on the plate is:
Why loading old game with different DPT give different-maintenance but same-revenue/running costs savegames ?

I can upload the savegames I made for testing purposes, but you can get this effect using any pre-6.0 savegame (I think any, for sure 3.14) - just load them with different DPT in config and run on fast forward for a year. You should see the same thing as in my test sheet.


[Edit:] While I can't compile simutrans from sources (I gave up trying to make it work on watcom), I might try someday trace the problem at hand in the source code. Maybe I'll just find the thing ? Don't have enough time for that now, but maybe someday I will.
4
Simutrans-Extended development / Re: [6.6] Mess with the distance_per_tile again (or still ?)
Ah, I didn't remember that the scaling was started much earlier than 6.0.

Well, this probably explains the behavior of my save game.
****uming:
>I started out before any scaling started (don't remember the version, I think it was 2.4 or something like that)
>When simutrans pre-6.0 loading even older savegame doesn't find the journey distance scaling factor it doesn't write ANY factor into the savegame
>When 6.0+ loads savegame without factor, it doesn't write one EITHER, and uses current DPT from config file for revenue calculation
Then:
>The behavior of my old savegames is explained, where the revenue would depend on current DPT in config, regardless of what's in save game

This requires all 3 ****umptions, and some of them mean that simutrans is acting weird. I mean, the revenue depends on current DPT, but running costs/etc depend on different parameter. This means simutrans is implementing scaling in different ways in different places. And this is dangerous to calculation consistency. It is already broken by loading old savegames, but you never know if a small change in seemingly unrelated place in future wouldn't break the consistency again.


Still, the 6.0+ seems to be using not only ONE parameter for scaling, but has the scaling hidden among several parameters. Otherwise it would be impossible to get some of the results:
>Same revenue and running costs but different maintenance for DPT=30 and DPT=100 loaded 3.14 games
>Same running costs but different maintenance and revenue for DPT=30 and DPT=100 loaded very old games

My point is:
Make ALL the scaling depend on the very same SINGLE number.
Currently it's not (as the test results prove), so the scaling is not robust. New games may not suffer at the moment, but the fact that weakness/problem can't be seen doesn't mean it won't show up later.

[Edit:] Sorry if it sounded like I'm demanding something. I'm just concerned that this may affect the future of experimental and being non-robust may prevent those features to be eventually incorporated into standard. Besides, I just wanted to continue my old game :(
5
Simutrans-Extended development / [6.6] Mess with the distance_per_tile again (or still ?)
Hello !

I was quite happy that the bug with the distance_per_tile was fixed. But it appears it wasn't the only one, or wasn't fixed fully. My main concern is about loading old savegames, meaning those before scaling was introduced. I have made extensive testing, and found out simply stunning variety of results you could get. For me, it looks like the scaling was not introduced in one, comprehensive way, but in each place it could matter slightly differently, using different methods, thus depending on what exactly you do you get very different results.

Anyway, here's the issue:

Regardless what you do (at least from what I CAN do), you cannot set the scale back to 1km/tile and get the same results as in experimental 3.14.

The zipped excel sheet with all the experimental setup explanation and results can be found here:
http://simutrans-germany.com/files/upload/DPT_test_results.zip

As you can see, the exact numbers never agree between 3.14 and 6.6, regardless what tricks you use. Maybe there are hidden modifiers in the savefile that I couldn't find that would allow to make changes to xml-formatted save to make it play just like 3.14 in regards to distances.
New games started with distance_per_tile (DPT) of 100 are very very close to original 3.14 when it comes to cargo, except for small variation in maintenance cost (no idea why it's there). The bad thing is that you can't get the same numbers when trying to convert old savegame (that has exactly the same setup like the new one you are creating) - when just loading with any DPT setting, the game uses hard-coded default of 30 (except for maintenance cost, this resembles the behavior in 6.4 where current DPT was used for maintenance and DPT from savegame for anything else, now current DPT is used for maintenance conversion, while still default 30 is used for anything else apparently). When "fixing" DPT in savegame, this works half-way, as revenue/operation costs are fixed, but some maintenance costs are not, resulting in discrepancy again.

For the p****engers, the situation is even more complicated, where fixing DPT in savegame drastically reduces p****enger flow, but I'm guessing this is due to time cutoffs (WAD) and not due to wrong DPT calculations. That's why I used cargo as main reference point (and all test games used cargo).

Anyway, it's still impossible to load older savegames and continue playing in 6.6, unless you don't mind basically re-building whole transport network to account for different conditions. Wouldn't it be quite easy actually to change the hard-coded "default DPT" to 100 instead of current 30, so that when loading older savegames, they are sort of converted properly ?

And on top of all that, there's the issue of my old save behaving really odd - as you can see the Revenue depends on CURRENT DPT and not in 100% consistent way. I don't know how it is possible, unless 3.14 saves differently games originally started in earlier versions than ones started in 3.14. While this doesn't seem to affect more recent saves or new games, this might hint to possible weakpoints already present in the code, that might break the game in future. I would think about re-implementing it again in a more robust way. Decide whether it should be game parameter (like station coverage, so always current value from config file is used) or should it be game variable (so the value from save game is always used). But if it's supposed to be variable, then it should be set by user on a game basis, just like climate heights or starting year, instead of being hidden in the config.

Well, all in all, the scaling still turns out to be buggy and very messy when trying to load older savegames.


Well, the main points are:
1. Could the hardcoded default for older saves be changed to 100, so they load properly ?
2. Watch out for the weak points in the code, as it seems the scaling is really unstable in current implementation as all the tests have shown.
6
Simutrans-Extended development / Re: [Bug/Problem 6.3] distance_per_tile issues
Yes, after I realized the distance was rescaled, I could understand the behavior of all values.
But what is buggy, as I said, is that changing distance_per_tile in simuconf.tab changes upkeep costs for infrastructure accordingly, regardless what is the value in the savegame.
Moreover, the revenue seems to be "immune" to changing distance_per_tile in savegame itself (done using xml save format) while running costs do change.

Actually, rather than increasing stop coverage, I would actually lower maintenance cost for stops and similar structures. Well, at least for sure I would lower the cost of basic stops. I mean... how a single pole with a sign can cost more upkeep than a kilometer of a highway ?
And I'm not sure if changing catchment to 3 could solve the infrastructure relative high costs. Yes, the area changes significantly, but you still need this train station as big as before, and depots etc. still cost all the same. Maybe it could be turned to profit, but certainly it wouldn't be like in regular 1 tile = 1 km setting. Even on typical scaling, I usually found infrastructure costs almost as high as running costs for vehicles (and even more so with still undeveloped p****enger network).
7
Simutrans-Extended development / Re: [Bug/Problem 6.3] distance_per_tile issues
Maybe it doesn't load two different values and that's the issue ? Like just using some default for revenue calculations instead the actual value from the savegame ?

Anyway, here is the savegame in question:
http://simutrans-germany.com/files/upload/Q4_x13_14.sve

When I loaded it into 6.3 and just ran for a year, I seen a sudden decline in revenues and running costs (while maintenance changed only a little since the big part of it were stops, not ways). This decline can be easily seen in the history graphs in budget.
8
Simutrans-Extended development / Re: "Too heavy"
When I first loaded my old savegame into simutrans-experimental (old version 2.somehting if I remember) I found out that the weight limit is NOT checked when vehicle enters the way fragment in question. It is checked when it searches for route. So I was dumbfounded at first, when my buses stopped working (back then, without even "too heavy", it was just "can't find route"), while they were driving through all the roads just a moment ago.
I don't know if something changed since then (due to exactly the weight problems for city road in pak128 I play with weight restrictions off), but it might be related as to why they started get to heavy out of a sudden. Besides, they might be just "on the edge" with weight, so when not fully loaded they would be still within limit while loaded to full would not. Maybe they made few rounds without full load of p****engers ?
10
Simutrans-Extended development / Re: "Too heavy"
The weights of vehicles AND all weight limits are actually set by the pak, so all complains about that must go to the pak makers in question. And when the paks are actually fixed so that the weight limits are sensible and consistent with vehicles available it adds to the game. Having optional feature was never a bad thing :)
I do not know why the simutrans standard supported the weight limits for ways in paks when it completely ignored them in-game, but that's probably the reason why these values are such mismatched - before simutrans experimental nobody ever could find out without digging through pak source files that they were not matching properly. If it weren't for simutrans experimental, then I would never know that there even were any weight limits defined in pak files in the first place.

From what I noticed the weight problem afflicts both pak128 (most notably some buses can't fit on city roads) and pak64 (some steam engines are heavier than any track allows). Didn't really use any other paks so I can't say for them.
11
Simutrans-Extended development / Re: "Too heavy"
You can always turn it off in simuconf.tab.

I did. pak128 isn't very consistent with weights and there are city buses heavier than city roads allow (which is a problem since you can't "build a better way" inside a city - it would get eaten up anyway).

[edit:]
The weight enforcement setting in simuconf.tab is:
"enforce_weight_limits="
(it's explained what to put after "=" in comments there)
12
Simutrans-Extended development / [Bug/Problem 6.3] distance_per_tile issues (FIXED)
Hello

After a large break, I played Simutrans a little bit recently. I found out a small issue with the distance scaling.

Issue:

When loading a game, the current value of distance_per_tile in simuconf.tab is disregarded, and instead a value saved with game is used when determining running costs and revenues of vehicles. (WAD as I understand)

BUT

1. The maintenance cost of ways uses distance_per_tile from simuconf.tab instead the one from savegame. (BUG)
2. When loading an old save game (from before the distance scaling was added) a value 2530 is used for running costs and revenues, not the current value from simuconf.tab (problem, all older saves were build with distance 100 so suddenly changing to 25 causes m****ive problems). [edit: actual value used, found out in savegame]



Story:

I noticed that when loading an older save game (from 3.14) and playing for a while my transport empire that normally earned like 2-3 millions annually, was falling apart with over half million losses.
Looking at history graphs I noted that my revenue and running costs plummeted down about fourfold (without much decline in transported p****engers/goods), while the infrastructure maintenance remained mostly the same. After reading what's actually new in 6.3 I noticed the scaling and immediately knew what's wrong - all distances were cut to 1/4 thus reducing revenue and running costs, but the infrastructure (stops mostly) still drained cash away as before, resulting in big minus instead of big plus overall.
So, to revert to "old ways" (after all, that game started like that and whole network was built in these conditions) I changed the distance_per_tile from 25 to 100. Unfortunately, I found out that pretty much NOTHING changed.

Curious why, I made experiment:
Small, new map. 10 tiles of road and a bus with order to go from one end to the other. Settings: distance_per_tile = 100. I ran for a year.
Then, I changed distance_per_tile = 25, loaded the save and ran for another year. Then, changed distance_per_tile = 10000, loaded and ran another year.
Result: Only maintenance cost of ways was affected. The running costs were not (can't say about revenue because it was all 0, but looking at issues with the savegame it would stay the same too).

Next experiment:
Now small map. 10 tiles of road and a bus. The same setup, except this time I started game with distance_per_tile = 10000. I ran for a year. Then, changed to distance_per_tile = 25, loaded save and ran for another year.
Result: The running costs were through the roof (as expected with distance_per_tile =10000), as were road maintenance costs. But after switching to 25, road costed accordingly less, but running costs were still astronomical.

Conclusion:
distance_per_tile is saved with savegame (I suppose this is WAD, since there's no way for a bug like that to occur by itself), but it is not used for maintenance cost. Maintenance uses current value from simuconf.tab, creating disparity between these two if distance_per_tile in savegame and in simuconf.tab do not match.
Moreover, experimenting a little with my old savegame, I realized that it always uses 25 for running costs/revenues (default), but the issue is that with older, pre-scaling savegames it was always 100, so transport empires crash around and die and you can do nothing about it.

[Edit:]
Actually, after saving the savegame as xml, and finding the value in the save (thanks to small trial save with some odd value for distance_per_tile like 313), I noticed that the old savegames have "****umed" the value 30, not 25.

[Edit2:]
Hmm... I don't understand it anymore. Now that I fixed the distance_per_tile in savegame, the running costs came back to normal. However... revenue didn't. Something's a bit wrong. Oh well. Revenue must use different multipliers hidden in save file somewhere else. It didn't change when changing distance_per_tile in simuconf.tab, nor when changing it in savegame (or at least I thought it was that, I mean, it worked for running costs), so I guess it must be still somewhere out there.
13
Pak128 Add-ons and Graphics / Re: Gas Station Art
There's more than one "window" color. There are at lest two or three of them. Maybe you could find the pair that will work well for the shaded windows.

Aside from that, looks very good !
14
Extension Requests / Re: Smoother large maps
Or perhaps use self-similar structures for landscape ? Meaning to generate the landscape as a fractal. This way it will look still plausible on very large scale, while retaining fine structures.
Otherwise I get the feeling that just scaling spatial density by map size would create extremely smooth large maps - on small scale they would be featureless.
15
Pak128 / Re: [Release 1.0] New Sand Quarry
Okay. I kept just the xcf file and simutrans-germany took the 1.5MB. Maybe there's a typo and the limit is not 20.0MB, but 2.00MB ? 1.5MB okay, 3.6MB too large...

Anwyay, the release 1.0 is up ! Check the first post for links.


Further plans:
When I get back to the sand quarry, I thought of maybe making it somewhat animated to make it look more "busy". I was considering some simple digging animation and people moving around. Maybe the lamp going out and back on in intervals, like some lanterns tend to do.
But I won't be doing that soon. The version 1.0 is up anyway, so it can be put into the pak128, so the rest is just for fluff. Maybe I'll do different industry rather than adding such flashy stuff to this one. Will see.
16
Pak128 / Re: [WIP, release 0.2] New Sand Quarry
Ehm... I would have put up 1.0 already, if not for a snag. simutrans-germany/files despite saying straight that maximum file size is 20.0MBytes refuses my 3.6MB upload saying ERROR, file too large

Do you know what's up and if there's anything that can be done ?
The full sources came out large (3.6MB), because I crammed in gimp xcf file, export from gimp to photoshop psd file and also few layers in png format.
I would like to sort this out before releasing, since this impacts the text files I include in all the zip files.
17
Pak128 / Re: [WIP, release 0.2] New Sand Quarry
VS, just a small question. If I were to put all the information into the text file (like in pre-1.0), what license should I put there (what is the target license for pak128) ?
Aside from that, I'm releasing 1.0 as soon as you tell me this info :) All is set.

[Edit:]
Could you also tell me if this is going to be incorporated into next pak128 release ? I would like to include that info into the text file.
18
Pak128 / Re: [WIP, release 0.2] New Sand Quarry
Quote
Ummm... now I feel like a beggar, but did you consider this? No pressure; simply say how you feel about that and that's it then. Since you have the layered source, it can be always added later by anyone...
Like I said, with version 1.0 comes full xcf GIMP file, so you can take out any layer you want. I think I'll also put into the pack separately few main "layers" (like "buildings", "vehicle", "terrain") for people who do not use GIMP and could not read xcf file (although it's a matter of installing GIMP, that's available at least for linux and windows).

Ok, so these are the stats form the original quarry dat file ? I'll patch the dat file, do something with the small light and probably release all this as 1.0. Unless something occurs to me that also had to be done, then I'll just do that and release 1.0.
19
Incorporated Patches and Solved Bug Reports / Re: Compilation problem (Windows, NOT MSVC)
If I ever make it work...  ;D
And I'm afraid I might resort to "hacks" like putting #include <stdlib.h> into the simutypes.h (which solved the problem of compiler somehow not recognizing "abs" function). So putting a sensible patch might prove tough.
All this IF I make it work in the first place.

@VS
No, thanks. I can do that. I'm not THAT bad (I hope) :D
I just didn't recognize the thing correctly when I was looking around for this NORETURN thing and when you wrote that "it's defined there" I looked again and DUH ! This is not commented out ! Precompiler stuff has "#" in C
It was just one of these moments when you look straight at something and don't see it.
20
Pak128 / Re: [WIP, release 0.2] New Sand Quarry
A new version (0.2). It's almost finished.
Download:
http://simutrans-germany.com/files/upload/sand_quarry_pak.zip
http://simutrans-germany.com/files/upload/sand_quarry_src.zip
Screenies:


The only issues are now:
>Are the lamps okay as they are now ?
>Is there something amiss or wrong ?
>DAT file

About the lamps: I tried to do some lamps that light up a little below them. I'm a bit concerned if they look okay. Especially at night. The one on the entrance to the long barrack just melds into the area it lights up. Perhaps this one should go away ? The second issue is: during the day you can still see the "light" of the lamp (albeit not so good, still the gr**** and sand are both too bright to completely conceal it during the day.

About the DAT file: I put some values there, but I don't know if they make sense. VS, could you check the dat file (it's in the source zip) to see if they make sense (and compare them to the current sand quarry). I would be grateful if you could tell me what parameters are wrong and what values should I put there. If I get the feedback about the DAT file and we agree the graphics is also okay for the "full" release, then I'll be making version 1.0, that will also include full layered GIMP picture (xcf) in the sources (or as additional, 3rd package, since the xcf is itself few megs).
21
Pak128 Add-ons and Graphics / Re: Gas Station Art
Seems like I was in too much hurry to be happy about fixing special colors. Somehow when GIMP selects colors from picture merge he does it differently than when actually merging. I'm completely baffled about this discrepancy. I guess cleaning with each merge is necessary :(
22
Pak128 Add-ons and Graphics / Re: Gas Station Art
I actually managed to find a way to clear the unwanted special color pixels in GIMP before merging, so that you can have fully clean, layered source. You have to use "pick by color" with "sample merged" option for the tool checked. If you have then a handy palette of special colors in the corner of the picture, you can pick one by one to see where exactly on the resulting, merged picture such colors will appear. Then, you have to go to the layer that caused the unwanted pixels and tweak it so that in the end the color is not special (you can use the selection you just got to limit yourself to just the pixels in question), or you could add "special colour fixing" layer. Anyway, you can do that in GIMP. Don't know if it's possible in Photoshop.

(goes back to finishing sand quarry)...
23
Simutrans-Extended development / Re: [Bug 3.11] Seemingly random crashes
No, I'm 32 bit. It's because of the compiler (additionally I'm not familiar with Watcom). I get strange errors that result from the code not being suited for Watcom (defines that make compiler error out, unexplained ignorance of what "abs" is etc.). I solved few of them but got tired out by some more complicated now on the plate. Will pick it up tomorrow... err... today morning/afternoon.
24
Incorporated Patches and Solved Bug Reports / Re: Compilation problem (Windows, NOT MSVC)
Ah ! Thank you very much VS !
I just realized that I forgot how the precompiler stuff looks like in C++  :-[
Don't know why but when I found it in the simtypes.h I thought "but it's commented out" (because of the # at the beginning).

Been a while since I actually worked with C++. And I'm just trying to compile NOT on MSVC to see if the experimental simutrans version has the same random crashes on all compilers (or maybe MSVC is at fault, well... let's say I'm not a trusty person when it comes to MS products  :P )
I posted the problem here because I found the same thing in regular simutrans.

Thanks for help !
25
Pak128 Add-ons and Graphics / Re: Gas Station Art
This looks really nice, Asterix.

Quote
I can't let dantedarkstar have all the fun making new art... so I tried my hand at something:
Yes ! Let the avalanche begin and we will have opensource pak128 in no time !  ;D

It's nice to know I inspired somebody :)

Oh yes, one small hint/remark: make sure to hunt all special colors out of the shaded texture at the ground. I know that in my sand quarry I got loads of night-glowing pixels on the roofs and walls because I applied some Light layers. You can't hunt them down before you merge the whole thing into single layer (at least I couldn't in GIMP, maybe you can do that in Photoshop).
26
Incorporated Patches and Solved Bug Reports / Compilation problem (Windows, NOT MSVC)
Hello !

Today I tried to compile Simutrans from sources using Open Watcom 1.8 on Windows XP (and for certain reasons do not want to go with MSVC).
Unfortunately I didn't succeed. I get an error when compiling the first of many source files. But the error happens actually inside one of the included .h files, namely log.h

I get syntax error on the line with NORETURN. Why is that thing there ? Where it is normally defined ? Am I missing some important yet-almost-obvious point ?

(From the log.h file)
Code: [Select]
    void error(const char *who, const char *format, ...);

        /**
         * writes an error into the log, aborts the program.
         * @author Hj. Malthaner
         */
        void NORETURN fatal(const char* who, const char* format, ...);


        void close();


        log_t(const char *logname, bool force_flush, bool log_debug);
        ~log_t();
27
Simutrans-Extended development / Re: [Bug 3.11] Seemingly random crashes
Well, I tried my first compilation but I failed big time. Errors started popping from the very first file to be compiled  :(
But I'll be asking on the main simutrans development forum since it has nothing to do with your code (I looked and the same thing is in standard simutrans).

It might take some time before I succesfully compile that beast  :-\
28
Pak128 / Re: [WIP, release 0.1] New Sand Quarry
I was thinking the quarry to be available for tropic, mediterranean and temperate climates. For desert it looks kinda out of place, for tundra and higher there wouldn't be any sand to dig, either because of permafrost (tundra as northern climate) or too rocky ground (if we ****ume it takes role of high-altitude climate).

And no worries about feedback. I have few ideas that I will implement: some pump system to get rid of the water accumulation at the bottom, some lights (other than windows) and probably make the entrance barrier in different position (looks a bit weird for me, not to mention the red lights are too dense on it). Also maybe will re-implement shadows if I manage to make sensible shadows that extend to gr****y areas (if we agree to limit to tropic-temperate, then I could probably implement some internal gr**** as non-transparent and could shade it then. Of course external gr**** at the perimeter would remain transparent to seamlessly fit into the environment.
I'll probably play with it tomorrow (saturday).
29
Simutrans-Extended development / Re: [Bug 3.11] Seemingly random crashes
I can, but it won't help. After I started game again and loaded the save (it was by coincidence saved just a few moments before this occured) the jam didn't appear again. The "seemingly random" seems to be "really quasi-random". I just wanted to share a rare observation that might be or might be not really related to the issue at hand.

What I will have to do is to try compiling the simutrans-experimental on watcom and see if the same error occurs. Because if it doesn't, it may be either the VC or just some intricate interference between the current code and VC routines. Anyway, tomorrow or on saturday I will try that out.
30
Simutrans-Extended development / Re: [Bug 3.11] Seemingly random crashes
Today, I got a curious thing. During game, the screen got completely "jammed". It originated from one tile (when I moved away it was gone, when I moved to the location it was back). Shortly after the game crashed.
These symptoms in my book mean that the cause of these crashes is some pointer mixup or unchecked index out of bounds. It's bad news since these type of bugs could be practically anywhere in the code.
The appearance of parts of the sand quarry in the jammed part would point to pointer mixup - like if simutrans was trying to get graphics from a wrong place in memory. Maybe usually when this happens it's outside simutrans and immediately produces error that the memory cannot be read, but this one time he accidentally hit somewhere within simutrans and could therefore read ?

Here's the screenshot in question:

31
Pak128 / Re: New chains ideas
Recently I had idea od Copper production chain, that would be fed to electronics factory (instead of Steel). I would also incorporate Acid production (used in Copper mining and perhaps somewhere else in industry).


Chains/Parts:
*Sulfur Mine* -> Sulfur (100%)
Sulfur (32%) -> *Acid Plant* -> Acid (100%)

Acid (20%) -> *Copper Mine* -> Copper Ore (100%)
Copper Ore (400%) + Coal (100%) -> *Copper Mill* -> Copper(100%)

Freights:
Sulfur : Bulk good
Acid : Fluid good ? (although transporting acid and milk in same car is a bit weird)
Copper : Special Freight (could a category for Metals be made so that both Steel and Copper could be transported by same cars ?)


Then substitute Steel for Copper in Electronics Factory
Also, the Acid could be used in some other factory chains (can't remember all the chains right now). I know Sulfuric Acid is used majorly in phosphate fertilizers production (actually, to get phosphoric acid)).

The large % for Copper Ore used in Copper Mill is because copper ores are always very poor. The ores are concentrated in the mines to get Concentrate that has 20%-30% Copper, and this is the "ore" that actually gets transported to mills for further processing.
The Acid is required for Copper Mine preprocessing to get the Concentrate.


Maybe I'll get to making these chains, but for now I started remaking industries in pak128 that need new graphics (due to pak128 trying to become open source). So Copper and Acid production will have to wait.
32
Pak128 / Re: making 128 open source - what is left to do
Uhm... I "manufactured" my own dat file :)
Of course it will probably have to be tweaked before being incorporated into pak128. And the person to do the tweaking would be probably you, since you have big picture of the whole industry etc. I'm here mainly to supply graphics.
So far I learned that minimum production and production variance doesn't behave like described in simutrans-germany wiki. I get final numbers about twice as large as I expected from the values I put in.

Anyway, version 0.1 sand quarry is already done (under the name sand_quarry, feel free to change it anytime or tell me what name should I use if there's a grand scheme for that). Further versions will emerge as I gather strength to tweak it.


When I'm finished with quarry, I think I'll try tackling Steel Mill. I expect it to be a lot tougher than sand quarry. After all, I can't do worse than the current one and... well... it looks complicated :-X
33
Pak128 / Re: [WIP] New Sand Quarry
Well, I decided to first make it work, then go with improvements. Below are the screenies for the quarry in game:


I still didn't catch a single pixel on the long barrack that glows in the night when it shouldn't. Aside from that, there are quite some improvements I plan on doing.
The quarry looks bad on the desert. I used different sand coloring, because standard simutrans has very orange/coppery hue to it. I think we could agree to disallow the quarry on the desert on the grounds that desert sand is of wrong type. Besides the water pools look out of place under such conditions.

But anyway, the version 0.1 is up (and since it's open source, there is also link to sources):
http://simutrans-germany.com/files/upload/sand_quarry_pak.zip
http://simutrans-germany.com/files/upload/sand_quarry_src.zip
As I said I plan on uploading the GIMP xcf file with its all 50 layers, but I will do that when I get to version 1.0. For now it's just the png for the game and dat file (which probably needs quite some overhaul before being incorporated into pak128 because some values are ****igned sort of "on fly" and in the game it turned out perhaps not so great).


And thank you for all the encouragement. It really helped (otherwise I would be probably halfway with the buildings).
34
Pak128 / Re: [WIP] New Sand Quarry
I realized the digger came out huge. But I'm considering keeping the size and just making it look like it's large. I'll add a hint of a ladder and probably decrease size of the driving cabin, so that it actually looks like a big thing, rather than not-to-scale. After all, if they have things like this: http://en.wikipedia.org/wiki/Caterpillar_797B
then one-story high digger is a small fry :)
Besides it would myabe half-explain why the quarry can work with just one machine.

As for the fence, I agree. I will make it lighter, but keep it metallic/gray (maybe make it a bit rusty here and there). This industry isn't really shining new (just look at the barracks and the fence holes patched with "do not cross" tape). Nice, painted fence wouldn't suit it.

Anyway, right now I'm splitting the above version into tiles to see how it looks in game. Besides it's my first factory (and building too) so I have to learn how to do that efficiently and develop helper "tools" (like sectioned multilayer bitmap in GIMP, so that I can just "cut and paste").
35
Pak128 / Re: [WIP] New Sand Quarry
Hmm... you are right, I didn't any vehicle shadow. I will have to include that.

Here's the next version preview, with SIMULATED gr**** (the gr****y areas are transparent in png for the game). I made most buildings etc. and found that there's not much place for other sand mining equipment. I will try to squeeze it somewhere, or we could just say it's very small sand quarry :)



Anyway, I removed building shadows for now, because most of ground near buildings is gr****ed, and I can't make shadow over the transparent area easily. I will try to solve that somehow (dithered shadows ?). Anyway, suggestions welcome !