beautifydoc.diff

planetmaker, 2010-06-24 19:39

Download (14.5 KB)

View differences:

docs/nml.css Thu Jun 24 19:38:57 2010 +0200
1
/*
2
    NML Documentation -- Stylesheet
3
	adopted from the PHost project
4

  
5
    The documentation is formatted in a mixture of "hard" (HTML 3.2)
6
    and "soft" (CSS) formats, to look good in all browsers. Tested with
7
    - Netscape 4
8
    - Netscape 6
9
    - Mozilla 1.0
10
    - IE 5 1/2
11
    - Links 0.95
12
    - Lynx 2.7
13
 */
14

  
15
/* Show headings and other emphasized things in a bright color. */
16
h1,h3,h4 {
17
   color:#000000;
18
   margin-left:-20px;
19
   margin-top:10px;
20
   margin-bottom:5px;
21
   font-family:tahoma, serif;
22
}
23
h2 {
24
   color:#000000;
25
   margin-left:-20px;
26
   margin-top:10px;
27
   font-family:tahoma, serif;
28
   border-bottom: solid black 1px;
29
}
30

  
31
em.hd {
32
   color:#880000;
33
   font-weight:bold;
34
}
35
em,b,th {
36
   color:#000000;
37
}
38
body {
39
   margin-left:40px;
40
   margin-right:40px;
41
   font-family: georgia, serif;
42
}
43

  
44
/* These are the boxes used for missions, commands, fcodes, ... */
45
table.heading {
46
   border:solid;
47
   border-color:#000000;
48
   border-width:1px;
49
   background:#ffffff;
50
   color:#000000;
51
   margin-top:10px;
52
}
53

  
54
table.t {
55
  margin:1px;
56
  border:1px solid black;
57
  border-collapse:collapse;
58
}
59

  
60
table.t td,th {
61
  border:1px solid black;
62
  margin:0px;
63
  padding:3px;
64
  background:lightgray;
65
}
66

  
67
pre.exl {
68
  margin-left:2em;
69
  background: lightgrey;
70
}
71
pre.code {
72
  margin-left:2em;
73
  background: lightgrey;
74
  color: #0000FF
75
}
76

  
77
.ext {
78
  font-family: serif;
79
}
80

  
81
hr { display: none; }
82

  
83
dt {
84
  margin-left:0em;
85
  margin-top:0.2em;
86
  font-weight: bold;
87
  font-family: sansserif;
88
}
89
dd {
90
  margin-left:1em;
91
}
92

  
93
dl {
94
  color: black;
95
}
96

  
97
address {
98
  margin-top: 1em;
99
  margin-left: -20px;
100
  padding-left: 20px;
101
  padding-top: 0.5em;
102
  margin-bottom: 0px;
103
  padding-bottom: 0px;
104
  border-top: solid black 1px;
105
}
106

  
107
code {
108
	color: #004400;
109
	font-style: typewriter;
110
}
111

  
112
bitlist {
113
	color: #FF0000;
114
}
115

  
116
/* Nice idea, but looks all too un-familiar.
117
tt.cfg a {
118
  text-decoration: none;
119
} */
120

  
121
/* Nice idea, but this looks rather ugly since <ex> inside <ul>
122
   gets indented
123
table.ex {
124
  background:#eeeeee;
125
} */
126
@media print {
127
  body { color: #000000; }
128
  a { text-decoration: none; color: #000000; }
129
  .screenonly { display: none; }
130
  hr { display: none; }
131
}
docs/reference.html Thu Jun 24 19:38:57 2010 +0200
1 1
<html>
2 2
<head>
3 3
<title>NML documentation</title>
4
<style type="text/css">
5
pre {
6
	background: lightgrey;
7
}
8
</style>
4
<link rel="stylesheet" title="Standard Style" type="text/css" href="nml.css">
9 5
</head>
10 6
<body>
11 7

  
......
105 101
Nearly all NML files will start with a <a href="#block-grf">grf-block</a>. The
106 102
grf-block takes no parameters and is one of the simplest blocks there is.
107 103
Following is an example grf-block.
108
<pre>grf {
104
<pre class="code">grf {
109 105
	grfid : "AB\02\03";
110 106
	name : string(STR_GRF_NAME);
111 107
	desc : string(STR_GRF_DESCRIPTION);
112 108
}</pre>
113 109
Let's look at this code line for line.
114
<pre>grf {</pre>
110
<pre class="code">grf {</pre>
115 111
This block is a grf-block. A grf-block has no parameters. The '{' is the start
116 112
of the block content.
117
<pre>	grfid : "AB\02\03";</pre>
113
<pre class="code">	grfid : "AB\02\03";</pre>
118 114
This line sets the grfid of the resulting grf. The value is the letters AB
119 115
followed by a byte with value 2 and then another one with value 3. The
120 116
semicolon marks the end of the statement.
121
<pre>	name : string(STR_GRF_NAME);</pre>
117
<pre class="code">	name : string(STR_GRF_NAME);</pre>
122 118
The name of the grf. In NML nearly all strings are put in
123 119
<a href="#language-files">language files</a>. The format of the language files
124 120
is described in another section. For now just assume a string with the name
125 121
<code>STR_GRF_NAME</code> exists. To reference a string from the language file
126 122
you use <code>string(&lt;stringname&gt;)</code> where <code>&lt;stringname&gt;</code>
127 123
should be replaced by the actual name of the string.
128
<pre>	desc : string(STR_GRF_DESCRIPTION);</pre>
124
<pre class="code">	desc : string(STR_GRF_DESCRIPTION);</pre>
129 125
This looks a lot like the previous line, only it sets the description instead
130 126
of the name.
131
<pre>}</pre>
127
<pre class="code">}</pre>
132 128
This marks the end of the last-opened block, in this case the grf-block.</p>
133 129

  
134 130
<h2>Parameters</h2>
......
137 133
parameters for internal use. If a user sets parameters for your grf, these are
138 134
the starting at parameter 0. Each parameter is available by using
139 135
<code>param[&lt;expression&gt;]</code>. You can set parameter number 4 to 3 by doing:
140
<pre>param[4] = 3;</pre>
136
<pre class="code">param[4] = 3;</pre>
141 137

  
142 138

  
143 139
<h1><a name="block-syntax">Block syntax</a></h1>
......
166 162

  
167 163

  
168 164
<h2><a name="block-grf">GRF</a></h2>
169
<pre>grf {
165
<pre class="exl">grf {
170 166
	grfid: &lt;literal-string&gt;;
171 167
	name: &lt;string&gt;;
172 168
	desc: &lt;string&gt;;
173 169
}</pre>
174 170
Example:
175
<pre>grf {
171
<pre class="code">grf {
176 172
	grfid: "AB\03\02";
177 173
	name: string(STR_GRF_NAME);
178 174
	desc: string(STR_GRF_DESC);
179 175
}</pre>
180 176

  
181 177
<h2><a name="block-item">Item</a></h2>
182
<pre>item (&lt;expression&gt; [, &lt;ID&gt; [, &lt;expression&gt;]]) {
178
<pre class="exl">item (&lt;expression&gt; [, &lt;ID&gt; [, &lt;expression&gt;]]) {
183 179
	(&lt;property-block&gt;|&lt;graphics-block&gt;|&lt;livery_override-block&gt;)+
184 180
}</pre>
185 181
The first argument is the feature of the item, the second (optional) argument
186 182
is the name and the third (optional) argument is the numerical id you want to
187 183
use for this item.
188 184
Example:
189
<pre>item (FEAT_ROADVEHS, hereford_tram) {
185
<pre class="code">item (FEAT_ROADVEHS, hereford_tram) {
190 186
	property {
191 187
		name:               string(STR_NAME_HEREFORD_TRAM);
192 188
		climates_available: CLIMATE_ALL;
......
196 192
}</pre>
197 193

  
198 194
<h3><a name="block-item-property">Property</a></h3>
199
<pre>property {
195
<pre class="exl">property {
200 196
	(&lt;ID&gt;: (&lt;string&gt;|(&lt;expression&gt; [&lt;unit&gt;]));)+
201 197
}</pre>
202 198
This one looks a lot more complicated then it actually is. A property-block
......
210 206

  
211 207
<h3><a name="block-item-graphics">Graphics</a></h3>
212 208
In general the layout for defining graphics is like
213
<pre>
209
<pre class="code">
214 210
spriteblock(FEATURE) {
215 211
	spriteset (SPRITESET_NAME, graphics_file) {
216 212
		[left_X, upper_Y, width, height, offset_X, offset_Y]
......
223 219
}
224 220
</pre>
225 221
An example which defines two graphics for a train engine:
226
<pre>
222
<pre class="code">
227 223
spriteblock(FEAT_TRAINS) {
228 224
	spriteset(turbotrain_engine_set, "sprites/pcx/opengfx_trains_start.pcx") {
229 225
		[142,112,  8,22,   -3,-10]
......
261 257
A livery override block offers the possibility to change the look of an engine or wagon depending on wagons coupled to them, e.g.
262 258
allowing a freight engine to be differently coloured than a passenger engine. The spritegroup needs to be defined before it can
263 259
be used in a livery override. A livery override block is always part of the engine definition and looks like
264
<pre>
260
<pre class="exl">
265 261
livery_override (vehicleID) {
266 262
	spritegroup_name
267 263
}
......
269 265
Concerning this example it is assumed that it is preceeded by the graphics definitions given as example in the <a href="#block-item-graphics">graphics definition</a>
270 266
and that a vehicleID "passenger_wagon" is defined. The engine will get different looks (spritegroup "turbotrain_passenger_group") in this example, if the passenger
271 267
wagon is attached. For all other wagons it will show sprites from "turbotrain_engine_group".
272
<pre>
268
<pre class="code">
273 269
// Turbotrain engine:
274 270
item(FEAT_TRAINS, turbotrain, 20) {
275 271
	property {
......
289 285
<h3><a name="block-spriteblock-spritegroup">Spritegroup</a></h3>
290 286

  
291 287
<h2><a name="block-switch">Switch</a></h2>
292
<pre>switch (&lt;expression&gt;, (SELF|PARENT), &lt;ID&gt;, &lt;expression&gt;) {
288
<pre class="exl">switch (&lt;expression&gt;, (SELF|PARENT), &lt;ID&gt;, &lt;expression&gt;) {
293 289
	(&lt;range&gt;: &lt;return_value&gt;;)*
294 290
	&lt;return_value&gt;;
295 291
}</pre>
......
306 302
<h2><a name="block-template">Template</a></h2>
307 303

  
308 304
<h2><a name="block-cargotable">Cargotable</a></h2>
309
<pre>cargotable {
305
<pre class="exl">cargotable {
310 306
	ID [, ID]*
311 307
}</pre>
312 308
The cargotable is a list of 4-byte long IDs. For example:
313
<pre>cargotable {
309
<pre class="code">cargotable {
314 310
	PASS, MAIL, GOOD, COAL
315 311
}</pre>
316 312

  
317 313
<h2><a name="block-if">If/else</a></h2>
318
<pre>
314
<pre class="exl">
319 315
if (expression) {
320 316
	block;
321 317
} else {
......
323 319
}
324 320
</pre>
325 321
For example:
326
<pre>
322
<pre class="code">
327 323
if (param[1] == 1) {
328 324
	param[2] = 3
329 325
} else {
......
345 341
<h3><a name="block-replacement-replace">Replace TTD sprites</a></h3>
346 342
<p>Using a <code>replace</code> block, it is possible to replace TTD's built-in sprites.
347 343
The syntax is as follows:</p>
348
<pre>replace(&lt;sprite-id&gt;, &lt;image-file&gt;) {
344
<pre class="exl">replace(&lt;sprite-id&gt;, &lt;image-file&gt;) {
349 345
	&lt;real-sprites&gt;...
350 346
}</pre>
351 347
<p>The first parameter <code>&lt;sprite-id&gt;</code> should be a compile-time constant
......
358 354
(<code>{</code> and <code>}</code>). The first sprite in this list replaces sprite with id
359 355
<code>sprite-id</code>, the second replaces <code>sprite-id + 1</code> and so on.
360 356
Sprite templates can be used as well. For example:
361
<pre>
357
<pre class="code">
362 358
// Rail overlays for crossings
363 359
replace (1005, "src/gfx/rails_overlays.png") {
364 360
		[ 20,198, 40,21, -20,  5]
......
375 371
sprites. As these sprites are not present in the original base graphics, they cannot
376 372
be replaced using a normal <code>replace</code> block. Instead, a <code>replacenew</code>
377 373
block has to be used. The semantics are like this:</p>
378
<pre>replacenew(&lt;type&gt;, &lt;image-file&gt;[, &lt;offset&gt;]) {
374
<pre class="exl">replacenew(&lt;type&gt;, &lt;image-file&gt;[, &lt;offset&gt;]) {
379 375
	&lt;real-sprites&gt;...
380 376
}</pre>
381 377
The <code>&lt;type&gt;</code> parameter indicates the type of sprites that will be replaced.
......
385 381
 and references to which sprites are actually needed. However this is a lot
386 382
 of work (even TTDP wiki doesn't list all info) and this is not really a
387 383
 high priority job -->
388
<table>
384
<table class=t>
389 385
	<tr><th>Type</th><th>Number of sprites</th></tr>
390 386
	<tr><td>PRE_SIGNAL</td><td>48</td></tr>
391 387
	<tr><td>PRE_SIGNAL_SEMAPHORE</td><td>112</td></tr>
......
436 432
<p>A <code>font-glpyh</code> block makes it possible to provide sprites
437 433
for glyphs that don't have sprites in normal TTD. The syntax is as follows:</p>
438 434

  
439
<pre>font_glpyh (&lt;font-size&gt;, &lt;base-char&gt;, &lt;image-file&gt;) {
435
<pre class="exl">font_glpyh (&lt;font-size&gt;, &lt;base-char&gt;, &lt;image-file&gt;) {
440 436
	&lt;real-sprites&gt;...
441 437
}</pre>
442 438

  
......
461 457
grf file. You must have at least one starting point, but you can have more
462 458
than one.
463 459
<p>The general syntax of a town names block is:
464
<pre>town_names[(&lt;name&gt;)] {
460
<pre class="exl">town_names[(&lt;name&gt;)] {
465 461
	[styles : &lt;string&gt;]
466 462
	&lt;part&gt; &lt;part&gt; ....
467 463
}</pre>
......
483 479
Each part defines a piece of a town name. All pieces together form the name
484 480
generated by the block.
485 481
<p>An example of a part is
486
<pre>{
482
<pre class="exl">{
487 483
	text("name1", 1),
488 484
	text("name2", 2),
489 485
	town_names(othernames, 3)
......
500 496

  
501 497

  
502 498
<h2><a name="block-assignment">Parameter assignment</a></h2>
503
<pre>param[&lt;expression&gt;] = &lt;expression&gt;;</pre>
499
<pre class="exl">param[&lt;expression&gt;] = &lt;expression&gt;;</pre>
504 500
Set a parameter to the given expression. Neither of the two expessions has to
505 501
be constant, the following is perfectly valid:
506
<pre>param[param[2] + 1] = param[3] * param[4];</pre>
502
<pre class="code">param[param[2] + 1] = param[3] * param[4];</pre>
507 503

  
508 504
<h2><a name="block-sounds">Sound support</a></h2>
509 505
Sounds are supported by means of the <code>sounds</code> block.
510 506
An example of a sounds block that defines two new sounds is
511
<pre>sounds {
507
<pre class="code">sounds {
512 508
        load_soundfile("whistle.wav");
513 509
        import_sound(0x87654321, 3);
514 510
}</pre>The block starts with the keywords <code>sounds</code>, followed by one
......
533 529
<h1><a name="properties">List of properties</a></h1>
534 530
<h2><a name="property-trains">Trains</a></h2>
535 531
<h2><a name="property-roadvehs">Road vehicles</a></h2>
536
<table>
532
<table class=t>
537 533
<tr><th> property</th><th>value range</th><th>comment</th></tr>
538 534
<tr><td> name</td><td>                         string(STR_NAME_HEREFORD_TRAM)</td><td></td></tr>
539 535
<tr><td> climates_available</td><td>           BitMask(CLIMATE_XXX, CLIMATE_YYY, ...)</td><td>XXX = [TEMPERATE | ARCTIC | TROPIC | TOYLAND], alternatively CLIMATE_NONE or CLIMATE_ALL</td></tr>
......
569 565
<h2><a name="property-cargos">Cargos</a></h2>
570 566
<h2><a name="property-airports">Airports</a></h2>
571 567
<h2><a name="property-railtypes">Railtypes</a></h2>
572

  
573
<table>
568
<table class=t>
574 569
<tr><th>property</th><th>value range</th><th>comment</th></tr>
575 570
<tr><td>label</td><td>                   4-byte string</td><td>names of default rail types: "RAIL", "ELRL", "MONO", "MLEV", "3RDR"</td></tr>
576 571
<tr><td>name</td><td>                    string</td><td></td></tr>
......
591 586

  
592 587
<!--
593 588
example table:
594
<table>
589
<table class=t>
595 590
<tr><th></td><th></td><th></td></tr>
596 591
<tr><td></td><td></td><td></td></tr>
597 592
</table>
598 593
-->
599

  
594
<br>
600 595
The base speeds relevant for the curve_speed_multiplier are:
601
<table padding=1, border=2>
596
<table class=t>
602 597
<tr><th>curve length</th><th>base speed [km/h]</th></tr>
603 598
<tr><td>0 (90 degree turn)</td><td>30</td></tr>
604 599
<tr><td>1</td><td>44</td></tr>
......
617 612

  
618 613

  
619 614
Rail types define a number of fixed graphic blocks:
620
<table>
615
<table class=t>
621 616
<tr><th>block name</td><th>number of sprites</td><th>meaning</td></tr>
622 617
<tr><td>GUI</td><td>         16</td><td>4 rail directions, autorail, depot, tunnel and convert rail sprites for rail menu</td></tr>
623 618
<tr><td>TRACKOVERLAY*</td><td>10</td><td>6 flat and 4 slope sprites. Track without landscape</td></tr>
......
637 632

  
638 633
<h1><a name="vars">List of variables</a></h1>
639 634
<h2><a name="vars-global">General</a></h2>
640
<table>
635
<table class=t>
641 636
<tr><th>name <th>value range <th>comment
642 637
<tr><td>climate <td>CLIMATE_XXX with XXX = [TEMPERATE | ARCTIC | TROPIC | TOYLAND] <td>
643 638
<tr><td>ttdpatch_flags <td> <td>
......
666 661
<h2><a name="vars-cargos">Cargos</a></h2>
667 662
<h2><a name="vars-airports">Airports</a></h2>
668 663
<h2><a name="vars-railtypes">Railtypes</a></h2>
669
<table>
664
<table class=t>
670 665
<tr><th>name</th><th>value range</th><th>comment</th></tr>
671 666
<tr><td>terrain_type</td><td>         TILETYPE_NORMAL, TILETYPE_DESERT, TILETYPE_RAIN_FOREST, TILETYPE_SNOW</td><td></td></tr>
672 667
<tr><td>enhanced_tunnels</td><td>     0</td><td>should custom tunnel entrances be modified other values than 0 might be returned</td></tr>