Magic Data Discussion

Posted by TomMK 
Re: Magic Data Tutorial
Date: October 07, 2013 09:31PM
Posted by: Atticus.
Yep, I understand.

Nice ideas, tested them for both player and AI, but no, those are not it either.
Re: Magic Data Tutorial
Date: October 08, 2013 07:40PM
Posted by: belini
it's been a long time, I'll try and remember :)

desc79=????? - segment nr (start of some range) pit data
desc80=????? - segment nr (end of some range) pit data

these are pit in/out related, not needed, pit in/out problems are best fixed by altering tracks sectors or where the pit speed limit starts
and speed car is entering the pitlane

desc86=????? - unk (dw) AI wet?
desc87=????? - unk (dw) AI wet?
desc88=????? - new (dw) AI wet?
desc89=????? - new (dw) AI wet?

not sure, maybe ai performance on different compounds of wet tyre

this is magic from the last track I made and should have the latest info, as I said it's been a long time and I've forgotten a lot

GP3INFO
Name|Donington Park 2010|
Country|England|
Created|created with gp3 track tools|
Author|pk arnall|
Year|2010|
Event|formula one|
Desc|belini|
Laps|65|
Slot|17|
LengthMeters|4738|
LapRecordQualify|1:21.268|
Split1|326|
Split2|656|
#
;
;
MAGICDATA
14 ; FW AI DRY
14 ; RW
26 ; 1st
35 ; 2nd
41 ; 3rd
47 ; 4th
51 ; 5th
54 ; 6th
16 ; FW AI WET
16 ; RW
26 ; 1st
34 ; 2nd
41 ; 3rd
46 ; 4th
50 ; 5th
53 ; 6th
14 ; FW PLAYER DRY
14 ; RW
26 ; 1st
35 ; 2nd
41 ; 3rd
47 ; 4th
51 ; 5th
54 ; 6th
5688 ; DRY BRAKE BALANCE
16 ; FW PLAYER WET
16 ; RW
26 ; 1st
34 ; 2nd
41 ; 3rd
46 ; 4th
50 ; 5th
53 ; 6th
5613 ; WET BRAKE BALANCE
53 ; TYRE 1
52 ; TYRE 2
100 ; TYRE SELECT 0=HARD
16384 ;
16384 ;
16384 ;
16384 ;
16000 ; TRACK GRIP
16384 ;
16384 ;
35 ; DOWNFORCE
990 ; RIDE HEIGHT
15919 ; AIR RESISTANCE
8000 ; FUEL
128 ; AI AGGRESSIVE (128/512)
11441 ; TYRE WEAR
64768 ; AI GRIP
256 ; TRACTION/GRIP
507 ; ACE BHP (512)
480 ; ACE GRIP
507 ; PB
461 ; PG
497 ; SPB
451 ; SPG
480 ; AB
442 ; AG
461 ; RB
432 ; RG
512 ; RANDOM MIN (512)
2048 ; RANDOM MAX (2048)
0 ; AI ERROR
64 ; SPIN RECOVER RANGE
20 ; PIT IN
0 ; PIT OUT
20480 ; PRE-PIT ENTRY SPEED
16000 ; PLAYER FUEL 100%
15000 ; AI FUEL
0 ; AI RACE PERF
0 ; 2x2
81268 ; LAP TIME
0 ; TIME ADJUST
15400 ; AI TYRE 1
21000 ; AI TYRE 2
9 ; WEATHER %
6 ; PIT DATA
6 ; PIT DATA
256 ; AI RACE GRIP
20000 ; PLAYER WET
136 ; PLAYER GRIP
10000 ; BLACK FLAG PENALTY
2048 ; BLACK FLAG 1024=80k
5700 ; AI WET
16384 ; DW
16384 ; DW
16384 ; DW
16384 ; DW
16384 ; DW
16384 ; DW
100 ; PIT GROUP 1 %
24 ; STOP 1
10 ; PIT WINDOW 1
0 ;
0 ;
0 ;
0 ;
0 ;
0 ; PIT GROUP 2 %
0 ; STOP 1
0 ; PIT WINDOW 1
0 ; STOP 2
0 ; PIT WINDOW 2
0 ;
0 ;
0 ;
0 ; PIT GROUP 3 %
0 ; STOP 1
0 ; PIT WINDOW 1
0 ; STOP 2
0 ; PIT WINDOW 2
0 ; STOP 3
0 ; PIT WINDOW 3
0 ;
0 ; SUSPENSION
0 ; LOOSEWHEEL
0 ; PUNCTURE
744 ; ENGINE
1489 ; TRANSMISSION
744 ; WATER/OIL LEAK
0 ; THROTTLE/BRAKE
1489 ; ELECTRICS
16384 ;
16384 ;
16384 ;
16384 ;
19968 ; BUMP FACTOR
13 ; BUMP HEIGHT
;BUMPTABLE
41,1
73,0
274,1
293,0
329,2
361,0
864,2
880,0
;ENDOFMAGIC
;
;the end of data
Re: Magic Data Tutorial
Date: October 10, 2013 01:21AM
Posted by: Atticus.
First of all, thanks for the reply. :-)

6 ; PIT DATA
6 ; PIT DATA

So by 'not needed', we can assume these values are not used by the game, if I'm not mistaken.

desc86=????? - unk (dw) AI wet?
desc87=????? - unk (dw) AI wet?
desc88=????? - new (dw) AI wet?
desc89=????? - new (dw) AI wet?

As for these, there seems to be no corresponding data in a GP3 magic file (if that Donington Park magic file is for a GP3 track). There's one value below the black flag penalty, but it is 5700 in your file, whereas we have between 5 and 300 for these four values above.

Which makes me think we are looking for something GP4-specific. Or something that was overhauled in GP4 completely compared to GP3.

I tried to check AI performance on the wet tyres, but it's very hard to do because the water levels change from game to game. I doubt this is it, however.

20000 ; PLAYER WET
136 ; PLAYER GRIP

These are the most interesting. The first one was labeled AI TYRES in the earlier cited magic file of yours - now it's PLAYER WET.

I checked (this time thoroughly) if it's the timing of the game for calling the player car in for a wet/dry tyre change (I drove Alot of laps for this. :-)), but once again, it's a dead end.

And I have not experienced increase or decrease of grip levels for the PLAYER GRIP value for 0 and 500 - in dry conditions. There might be some effects in the wet, this I didn't test.

*

That's it for now. Painfully little progress overall. But once again, thanks for popping in again, belini. :-)
Re: Magic Data Tutorial
Date: October 10, 2013 07:12PM
Posted by: TheFueleffect
One question: is the pit refueling rate (ms per lap of fuel or quantity per second) somewhere in the magic data?
Re: Magic Data Tutorial
Date: October 10, 2013 07:44PM
Posted by: klausfeldmann
No, it's in the exe. You can change it with GP4-Tweaker ;-).
Re: Magic Data Tutorial
Date: October 10, 2013 08:31PM
Posted by: TheFueleffect
I know GP4Tweaker can change refueling time. But is the refueling speed constant for all tracks (for example 300 ms per fuel lap)? Then pitstops should be significantly faster at the longest tracks (like Spa-Francorchamps and the old Hockenheimring), which is not very realistic. :(
Re: Magic Data Tutorial
Date: October 17, 2013 02:26PM
Posted by: belini
Atticus. Wrote:
-------------------------------------------------------
> First of all, thanks for the reply. :-)
>
> 6 ; PIT DATA
> 6 ; PIT DATA
>
> So by 'not needed', we can assume these values are
> not used by the game, if I'm not mistaken.

yep

>
> desc86=????? - unk (dw) AI wet?
> desc87=????? - unk (dw) AI wet?
> desc88=????? - new (dw) AI wet?
> desc89=????? - new (dw) AI wet?
>
> As for these, there seems to be no corresponding
> data in a GP3 magic file (if that Donington Park
> magic file is for a GP3 track). There's one value
> below the black flag penalty, but it is 5700 in
> your file, whereas we have between 5 and 300 for
> these four values above.
>

gp4 only, I only messed with these when gp4 was released so it is a very long time ago

> Which makes me think we are looking for something
> GP4-specific. Or something that was overhauled in
> GP4 completely compared to GP3.
>

gp3 and gp4 are very similar, what I found in gp4 were relevant in gp4 and vice versa

> I tried to check AI performance on the wet tyres,
> but it's very hard to do because the water levels
> change from game to game. I doubt this is it,
> however.
>

yes, it's too difficult to work out what is going on especially as the game randomises virtually every
performance related value, I must have spent 100's of hours tracking this stuff down in the exe,
if you can't see any obvious difference, don't worry about it :)

> 20000 ; PLAYER WET
> 136 ; PLAYER GRIP
>
> These are the most interesting. The first one was
> labeled AI TYRES in the earlier cited magic file
> of yours - now it's PLAYER WET.
>

> I checked (this time thoroughly) if it's the
> timing of the game for calling the player car in
> for a wet/dry tyre change (I drove Alot of laps
> for this. :-)), but once again, it's a dead end.
>
> And I have not experienced increase or decrease of
> grip levels for the PLAYER GRIP value for 0 and
> 500 - in dry conditions. There might be some
> effects in the wet, this I didn't test.
>

I only used to run the game with the player grip patch on, it does make a subtle difference but as above
it's not that obvious because of the random factors.


> *
>
> That's it for now. Painfully little progress
> overall. But once again, thanks for popping in
> again, belini. :-)

my pleasure, as I said above, don't worry about these values they're so subtle it makes no difference to the
racing experience, great the community is still up and running

cheers
paul
Re: Magic Data Tutorial
Date: October 28, 2013 11:06PM
Posted by: TheFueleffect
Hi all,

I thought you might be interested in some testing data. Unfortunately, GP4 won't run on my old computer, but the good news is that it runs reasonably well on my laptop. Even CMagic seems to work, so I decided to give it a go.

Today I reduced the CC shuffler value and then I watched how the race progressed. My test track was Spa-Francorchamps, because this is the easiest track to see if CMagic works: in the original game the pitstop strategies are quite unrealistic (pitstops start as early as lap 6 for some reason) and changes in pitstop strategies are easy to spot. I changed the two-stop strategy to: stop 1: lap 14-17 and stop 2: lap 29-31.

Anyway, I also reduced the CC shuffler value to 1200 (instead of the original 2535) and these are Häkkinen's laptimes (* to indicate it was not an improvement of his best time so far) in the race:

1 1:52.496
2 1:49.586
3 1:49.418
4 1:49.380
5 1:49.149
6 1:48.958
7 1:49.192*
8 1:49.087*
9 1:48.851
10 1:48.780
11 1:48.972*
12 1:48.741
13 1:48.815*
14 1:48.593
15 Pitstop
16 2:11.401
17 1:49.738
18 1:49.469
19 1:49.080
20 1:49.663* (traffic)
21 1:48.886
22 1:49.188*
23 1:49.276* (traffic)
24 1:48.933*
25 1:49.463* (traffic)
26 1:48.990*
27 1:48.850
28 1:48.835
29 Pitstop
30 2:11.318

Unfortunately, in lap 31 Häkkinen crashed in a silly way while he was leading by 20 seconds. I hate these random errors. The laptimes confirm that tyre wear is not the dominant factor anymore, but the laptimes do not give any information about the exact tyre degradation or the fuel penalty. Autodromo Enzo e Dino Ferrari is a better track to estimate these two (counteracting) effects, as the common strategy was to make two late pitstops, which means that the laptimes were relatively bad in the first (long) stint. By the way, there is a little trick to create more realistic pitstop strategies. In the game, there is no correlation between the timing of the first and second pitstop, so the pitstops can be either too close together or too far apart. But using the otherwise unused 3-stop strategy pit windows may overcome this problem. For example:
1 stop: lap 31-34
2 stops: lap 25-30 and lap 46-47
3 stops: lap 21-24, lap 41-43 and lap 63 (the full race-distance is 62 laps, so hopefully lap 63 is enough)

I reduced the CC shuffler to 1300 (original: 3932 - pretty high, as the very soft tyre types 55 and 54 are used). The race was led by Michael Schumacher, but Coulthard and Häkkinen behind him were a little faster (I admit there is something wrong with my performance file) and fourth placed Montoya was running a 1-stop strategy. During the fist part of the race, the top-4 runners were covered by a few seconds.

1 1:31.343
2 1:25.944
3 1:25.982*
4 1:25.926
5 1:25.832
6 1:25.716
7 1:25.623
8 1:25.918*
9 1:25.501
10 1:25.542*
11 1:25.512*
12 1:25.576*
13 1:25.447
14 1:25.485*
15 1:25.451*
16 1:25.373
17 1:25.324
18 1:27.427* (Button blew his engine and everyone had to slow down)
19 1:25.303
20 1:25.329*
21 1:25.272
22 1:25.110
23 1:25.137*
24 1:25.037
25 1:25.701* (traffic)
26 1:25.116*
27 Pitstop
28 1:51.197
29 1:25.775 (Montoya: 1:24.598)
30 1:25.502 (Montoya: 1:24.973)
31 1:25.516* (Montoya: 1:25.178)
32 1:25.388 (Montoya: 1:24.908)
33 1:25.901 (Montoya: pitstop)

Unfortunately, this time the game crashed, presumably a sound issue. Montoya was in second place after his stop, just behind Michael Schumacher. It is unlikely that Schumacher would have build a large enough gap to remain in the lead after his second stop, given that Montoya was about half a second faster in clean air, but nevertheless it would have been entertaining to watch. Sadly, it was all over in one second. At least the race yielded some information: the laptimes decreased by about a second over 25 laps, but there is no good data to accurately estimate the tyre degradation. Hopefully the game won't crash next time.
Re: Magic Data Tutorial
Date: October 28, 2013 11:40PM
Posted by: TomMK
That's a great idea to use the 3-stop strategy as an alternative 2-stopper. Never thought of that but it's a very nice way to get rid of some of the randomness that GP4 introduces. Good one!!

I think we will never know the exact units for tyre wear (cc shuffler) and fuel consumption but it's more about getting the balance right. Being able to go 1 second quicker after 25 laps means tyre wear is very low, which is more akin to the Bridgestone days. The modern designed-to-degrade Pirellis need a value closer to 5000 to produce races similar to real life (although this year we have had 4 stop strategies at some races and 1 stop strategies at others so it's very variable even in real life!). It just depends what type of racing you're trying to emulate.

=====================================================


Intel Core i5-6200U, 8GB, Intel HD Graphics 520, MS Sidewinder Wheel
Re: Magic Data Tutorial
Date: October 29, 2013 01:28PM
Posted by: SchueyFan
2013 is at least in some ways easier to simulate than 2010. I have been doing a 2010 season at the moment and it's quite difficult to simulate it accurately.





My GP4 Downloads, Twitter (@ed24f1)
Re: Magic Data Tutorial
Date: October 29, 2013 05:42PM
Posted by: Atticus.
I also tinkered a bit with the CC shuffler a while ago, based on the findings of klausfeldmann on page 5. (Here's the doc, just in case: [docs.google.com])

What I found to be very annyoing is that red line, which goes flat at a CC shuffler value of around 3000-3500. This practically means that it is very hard to realistically induce a heavy tyre wear effect into the game. A lap time deg of about 1.5 sec is the maximum we could achieve. As CC shuffler marginally seemed to affect the initial lap times as well based on the bowl-shaped green line in klausfeldmann's test, for that 1.5 sec degradation we aim at the lowest CC shuffler value which hits that cliff, where the times don't get any worse anymore after some time, because this value has the biggest gap between early and late run lap times.

Alternatively, we can just use the softest compounds (55-54) for every track (they can't be distinguished visually in-game anyway), but this also has limited effect on actual tyre wear progression (more so, on overall lap time levels).

Still, what really could do the trick is to decrease track grip. My Sonoma (Sears Point) track uses the Montreal slot by default and initially I left all magic data values intact (they still are in the version found in my topic). Montreal has perhaps the lowest track grip value of the original tracks and this coupled with the demanding vertical and horizontal tyre load of Sonoma basically just washed away my tyres when I once did - or tried to do, to be precise - a 100% race distance race. They went in about 10 laps and my lap times fell drastically. So I think this could work - of course, needs a lot of tests.

*

By the way, when I adjust a value in magic data for some of my tracks, I usually gather its values from the 17 original tracks into an Excel file. It grows nicely and I could upload it some time just for some reference point and to find it easier to relate to the realistic values.
Re: Magic Data Tutorial
Date: October 31, 2013 08:20PM
Posted by: TheFueleffect
Quote
Atticus.
What I found to be very annyoing is that red line, which goes flat at a CC shuffler value of around 3000-3500. This practically means that it is very hard to realistically induce a heavy tyre wear effect into the game. A lap time deg of about 1.5 sec is the maximum we could achieve.

The tyre-degradation limit is probably way higher than you think, as the cars should get faster during the race as fuel burns. Correcting for fuel load, the tyre wear limit is probably 6 seconds per lap or so, which is not much of a problem. Just reduce fuel and fuel consumption to slightly above 0 and the laptimes will increase for a very long time.

Possibly cc shuffler determines the "hardness" of the tyre, which explains why the "initial" pace changes. Just when tyre wear hits its "limit" at the end of the race, the initial laptimes are best, indicating that from that point onwards the tyres get harder (slower and maybe more durable to compensate for the higher tyre wear?) when cc shuffler is increased. The same applies when cc shuffler is decreased, but I don't know why.
Re: Magic Data Tutorial
Date: November 23, 2013 02:24PM
Posted by: klausfeldmann
For a better understanding, I made some further tests with the cc-shuffler. Here are the specs:
- Track: Magny Cours 2007
- Only one cc-Car on the track making a 25-lap-stint
- I tried to delete all kind of randomnesses, including
--> no performance ranges neither in performance file nor in cmagic
--> no ai-errors, problems, defects or something like this.

Here are the results in an Excel-worksheet:
--> Link


Findings:

- The results show obviously, that there is a tyre-wear-limit for the cc-cars: With higher cc-shuffler-values, the laptimes increase very quickly, until this trend stopps suddenly and the decreasing fuel weight lets the laptimes decrease again.

- The lower the cc-shuffler is, the faster the laptimes - thats logical due to our findings.

- Some of you will maybe claim, that the times are slower, when the cc-shuffler-value is 0. So I thougt, there could have been something wrong with my test, and made a new run. But the general results were confirmed by the new test, so a cc-shuffler-value of 0 might be a slower value than for example 500.
Dunno why, theories are welcome.
Re: Magic Data Tutorial
Date: November 23, 2013 06:08PM
Posted by: Atticus.
Nice work, must have been painfully lot of work logging all those times by hand on stint after stint. I also tried it once, but was too impatient. :-)

It all but confirms your earlier findings, the run of the graph as a function of laps follow clear trends.
Re: Magic Data Tutorial
Date: March 13, 2014 08:09PM
Posted by: TheFueleffect
Quote
Klausfeldmann
For a better understanding, I made some further tests with the cc-shuffler. Here are the specs:
- Track: Magny Cours 2007
- Only one cc-Car on the track making a 25-lap-stint
- I tried to delete all kind of randomnesses, including
--> no performance ranges neither in performance file nor in cmagic
--> no ai-errors, problems, defects or something like this.

I've analysed the laptime data in order to estimate the influence of CC Shuffler on laptimes.
As far as I know, GPx uses a tyre-wear model that uses two wear (degradation) rates. Tyre degradation increases after a certain level (4 mm of "physical" tyre wear), which can easily be seen in the laptimes. For example, when CC Shuffler is 16000, from lap 6 the laptimes start to increase noticeably. When CC Shuffler is 8000, the laptimes start to increase from about lap 12. So CC Shuffler affects tyre wear linearly. If we call CC Shuffler x number of laps = total tyre wear, then the threshold value is about 96000. The second threshold, when tyre wear hits its upper limit, is at around 200000-240000. For this analysis, I've used 208000 (when CC Shuffler is 16000, the upper limit is reached in about 13 laps and 16000 x 13 = 208000).

Below are the results of the analysis. One "unit" of tyre wear is one lap with a CC Shuffler value of 1000, so ten laps with a CC Shuffler of 16000 yields a total tyre wear of 160 units.

Fuel load (in laps): 0.058
Tyre wear (low): 0.014
Tyre wear (high): 0.021
Tyre wear (maximum): 0.019

CC Shuffler = 500: -0.551
CC Shuffler = 1000: -0.544
CC Shuffler = 2000: -0.423
CC Shuffler = 4000: -0.545
CC Shuffler = 8000: -0.567
CC Shuffler = 16000: -0.713
CC Shuffler = 32000: -0.691
CC Shuffler = 64000: -0.710

Constant: 85.171

It seems that non-zero CC Shuffler values have a positive influence on the initial laptimes. The "high" tyre wear is about 1.5 times higher than the "low" tyre wear and the maximum tyre wear is about 0.019 x 208 = 4 seconds.

One question: typical laptimes for Magny-Cours are 1:16 to maybe 1:18 for fast cars, so why are the laptimes in this test that much slower (1:25 or worse)?
Re: Magic Data Tutorial
Date: June 27, 2014 12:54AM
Posted by: TheFueleffect
In order to create some more realistic (2000s-style) races I decided to test some variables in the magic data. Overtaking is too easy and it usually leads to a few odd-looking collisions of the CCs during the race, so it's rewarding to find a way to reduce the number of overtakes in the race. The other thing is that it would be nice to see the track improve over the session (which can possibly be used to mimic the refueling ban). Therefore I've selected two promising variables: #49, which allegedly influences the slipstream behavior, and #51, which indicates how much the track is improving during the session.

First of all I was playing with the slipstream value. The description ("subtracted from diff between field_e2 of 2 cars and then compared to speed of first car";) suggests that higher values should lead to a less pronounced slipstream effect. The value probably determines the distance at which the slipstream effect kicks in, so then a higher value means the trailing car has to be closer to get the tow. Some testing seems to indicate that overtaking becomes slightly more difficult when high values are chosen. I eventually chose 8192 (note: the default values for the tracks are in the range of 128-512) for Barcelona, a track at which the CCs have no difficulties to overtake. With the high slipstream value, the cars seem to spread out a little more (they are keen to avoid each other in the tight corners and they cannot use the tow anymore to bunch up again.) This leads to slightly fewer overtakes, which is more realistic, although more testing is required to draw conclusions.

I also tested the track improvement value. As the track rubbers in, the laptimes will gradually improve. Nowadays such an improvement is difficult to notice, but in the 2000s should be noticeable: the laptimes at the end of the race should be faster than the laptimes right before the pitstops. However, as the pitstops are usually not perfectly distributed over the race, there are differences in tyre wear in the low-fuel configurations, which cause some distortions. I tested a value of 64000, which is actually something like -1536 unless I'm very much mistaken. The fact that the fastest lap of the race was set right before the first pitstop, suggests that negative values of the track improvement parameter may indeed deteriorate the track conditions over time, although the effect is small (maybe a tenth of a second over the course of a race). Again, more testing is needed, but this looks promising.
Re: Magic Data Tutorial
Date: June 27, 2014 01:37AM
Posted by: TomMK
I've suspected for a while that the slipstream value one is actually something to do with the cars defensive behaviour as another car approaches them. When there is a decent speed differential between a car and the one behind, that's what seems to trigger a defensive move to the inside of the next corner.

=====================================================


Intel Core i5-6200U, 8GB, Intel HD Graphics 520, MS Sidewinder Wheel
Re: Magic Data Tutorial
Date: June 27, 2014 01:28PM
Posted by: Atticus.
Maybe, but that defensive behaviour is related to other factors as well, such as the closeness of the next braking zone. A car won't move across the track if the next turn is nowhere to be seen yet, no matter how large the speed differential is.

I still think the AI in GP4 is among the best, if not the outright best, in F1 sims.
Re: Magic Data Tutorial
Date: July 01, 2014 10:16PM
Posted by: klausfeldmann
TheFueleffect schrieb:
-------------------------------------------------------
> I also tested the track improvement value.

What line of the magic data are we talking about?
Re: Magic Data Tutorial
Date: July 08, 2014 06:40PM
Posted by: klausfeldmann
I still would like to know, what is meant by "track improvement value" ;-).

***

I have just tested the slipstream value in Barcelona once again, because there was - once more - a post suggesting, that it could affect the amount of overtaking maneuvers. I tested the values 0, 256 (standard) and 64000. I didn't notice any difference in slipstream strength, nor slipstream length, nor in the car's defensive behaviour. I hope this story is history now - finally.

Who had as first the idea, that this value could be linked to the slipstream and are there any evidences for it? We tested this value so often now and there has never been any noticeable effect so far.

***

What about the following values?

19968 ; BUMP FACTOR
13 ; BUMP HEIGHT
;BUMPTABLE
41,1
73,0
274,1
293,0
329,2
361,0
864,2
880,0

Do we know, what they mean? And if yes, what do they mean in detail?
Sorry, only registered users may post in this forum.

Click here to login

Maintainer: mortal, stephan | Design: stephan, Lo2k | Moderatoren: mortal, Vader, stephan | Downloads: Lo2k | Supported by: Atlassian Experts Berlin | Forum Rules | Policy