Japanese version

From those days, SCASM had been famous and popular. In my case, I started trying to use Scenery MAKER enclosed with Schiratti Commander because I bought it. I write the situation of FS, SceneryMAKER, and SCASM in those days like this table.

1997	User defined variables	Dynamic scenery
FS5.1, FS95	-	some kind of aircraft without texture
Scenery MAKER	yes	not available
SCASM	no	available

User defined variables means not FS inner variables but variables which is defined and used by user. In those days, the user defined variables gave me freedom of programming and it was important when I tried to make Tokyo MEX highway with trial and error in many times. On the other hand, there was dynamic scenery already, but it could move only aircrafts without texture. From a viewpoint for making animated Yamanote-line train, it seems that it was no use. Therefore, the advantage of Scenery MAKER over SCASM is clear for my purpose, and I have done roadwork after that using Scenery MAKER.

With the lapse of time, in 1999, because I am ill-informed about hot news, I am aware of the following situation.

1999	User defined variables	Dynamic scenery
FS98	-	some kind of aircraft with texture
DynKit	-	It is possible to allot voluntary 3D object to dynamic scenery.
Scenery MAKER	yes	not available
SCASM	yes	available

As you can see, Scenery MAKER has no change but SCASM comes to handle user defined variables by version-up. At this point, the advantage of Scenery MAKER over SCASM is vanished. FS grows up for handling textured aircrafts as dynamic scenery. And DynKit ! It's great. At last, voluntary object comes to be adapted for dynamic scenery object. By DynKit, making Yamanote-line with dynamic scenery comes true.

By the way, that is a problem. I cannot make dynamic scenery using Scenery MAKER. After all, I decide switching to SCASM when I make the scenery with dynamic scenery section. SCASM is a programing language for making scenery used in worldwide as a standard now. SCASM is version-uped frequently and will be done from now on too. This is used by many GUI scenery making tools. And by unconfirmed information, Schiratti Control Center which is a succession of Schiratti Commander adopts SCASM and API files which is Airport macro files. This situation comes out at the home-ground of Scenery MAKER ! Is there the future of Scenery MAKER ? It will vanished ?? Anyway, because I have a lot of source code of Scenery MAKER program and I am accustomed to this tool, I will be bilingual of Scenery MAKER and SCASM case by case for a while.

So, I make dynamic scenery using SCASM and DynKit. After that, I find typical problems by itself. Dynamic scenery is designed for making animated aircraft originally, but I use it for making animated train forcibly. In this point of view, I will tell you advantages and disadvantages.

Advantages

In a window mode, there is no problem at a one object exists only as an aircraft. But if 11 objects gathers in small area like Yamanote-line, the motion of the objects becomes discontinuity just like the motion of Yamanote-line made with no dynamic scenery. But there is a great difference in 3D mode ( Alt + Enter ). All of the motion of the objects are very smooth, and the quality of the motion is very good.

Further, it seems that the limit of the number of objects which has been a problem are eased. In previous method, all position of the objects must be specified. In dynamic scenery, the motion is specified in vector form contains a direction of a motion and quantity of a motion. Comparing them to digital movie format like MPEG, all I pictures are transmitted in a previous method, and only a motion vector is transmitted in dynamic scenery. Of course, the quantity of the space of allocated memory for dynamic scenery in FS probably affects this limit, I think. Anyway, it is clear that a quantity of data is greatly decreased from a theory.

Disadvantages

Also, this is not a problem in the case of an aircraft but very problem in the case of a train, a perspective relationship of the objects each other is not maintained. This may be not easy expression in abstractly. In technical speaking, it is impossible to include section 9 object and section 15 object within PerspectiveCall routine together. (This expression may be more difficult to understand for the people in the liberal arts. ??) Of course, dynamic scenery (section 15 object) and static scenery (section 9 object) have reference point (SetPos, Refpoint) both. If the distance of the objects is longer than predetermined one, an order of display is controlled by the position of this reference point. If the distance of the objects is shorter than predetermined one, an order of display must be controlled by PerspectiveCall command. Concretely, the distance between an aircraft and a control tower is not a problem, and the distance between a train car and a track of train is a problem. This problem is able to be eased by a treatment of section 9 object. In my Tko_tm2.bgl, this treatment is done, but the problem does not vanish completely. (This is the reason why I made door open scene of Yamanote-line train at the station in Tko_tm1.bgl, and I don't make this scene in Tko_tm2.bgl).

Next problem is that time and spatial resolution are low. In time domain, the smallest controlable value is 1 second. In spatial domain, the smallest controlable value is 1 meter. This is not a problem for an aircraft but a problem for a train too. Specially, the brain will collapse in the case of curving with acceleration of a train which consists of 11 cars ! The control for detail motion is very difficult, and the motion will be not continuous. Further, not only resolution but also accuracy is low. For example, at changing Heading only, the time has lapsed in few moment.

And, absolute time control is impossible. Dynamic scenery objects start moving at observer approaching to it, so the effect for entertainment will be good. But detail control is not easy. Visibility control is also impossible. Concretely, if you want to see whole 11 cars of Yamanote-line, sometimes the edge of the train doesn't appear. Because pointing of altitude is absolute altitude basis, if you cross over synth tiles, then object floats in the air. Relative altitude basis pointing is impossible. And it is common that one of the scenery or both of the scenery is not displayed in the case of exsisting plural dynamic scenery files in a predetermined area. In metropolitan area like Tokyo, this is no good. You cannot enjoy many add-on dynamic sceneries at the same time.

I request a following point of dynamic scenery in the future.

Section 15 command should become section 9 command.

This contains several meanings. At first, Locate within PerspectiveCall is the biggest pending problem. I expect this will be resolved if section 15 command will be able to be used within section 9 routine. After that, another problem will be resolved I hope, for example, section 15 object cannot use section 9 inner variables; texture must be located in a main texture folder. And I hope the solution of the problem of visibility and altitude will be done too.

The conclusion for the proposition whether dynamic scenery is able to be used practically in the case of moving trains is NOT ENOUGH at the present time......I think. As I write advantages, basic characteristics is good but practical advantage is not enough yet. Because my road work is still under construction, I cannot speak about other work....but I feel that FS system is not completed yet. How about FS2000 ?? It's another problem ??

FS2000 comes out. After several experiment, I open to the public the Yamanote line train scenery made of dynamic scenery at last in Dec. 2000. I would like to write the result of the experiment on this time.
First, there are many good points. Some matter in which I pointed out is resolved. For example;

A perspective relationship of the objects between section 9 and 15 sceneries becomes being maintained. It means that the value for making the detail of Yamanote line train is existing. Therefore, I re-make Yamanote line train cars in detail, and do reviving "door opened train" which was made of no dynamic scenery in the past.

The motion of dynamic scenery becomes controllable in detail. Further, spatial accuracy becomes high dramatically. Because spatial accuracy becomes high, though time accuracy is still 1 second, I can make train cars as I like. It is OK to make 11 cars going curve track or going uphill gradually. (But making real scenery is very troublesome...)

But there are still some bad points.

As before, only one BGL file is viewable simultaneously. Enjoying plural dynamic scenery files is still impossible. And there are restriction for moving time and numbers of object. Based on the SDK, the maximum time is 255 seconds, and 1-34 will be processed concurrently in the XYZ relative system commands. Fortunately, Yamanote line scenery in this time is safe. But it will be NG if I will add another train or another track.

It is another bad thing, it seems that dynamic scenery has hysteresis effect. It is no doubt that you cannot see the scenery in the case of putting in plural dynamic sceneries which areas are duplicated. Of course, you cannot see plural dynamic sceneries which areas are not duplicated simultaneously. But in the case of NOT simultaneously ? This is also impossible ! In spite of moving between two areas not duplicated, you cannot see immediately the other object, if you will go into the other area just after being displayed one dynamic scenery in one area. It is just the hysteresis effect.

After all, it is difficult to design freely if these problems will not vanish. I hope the solution from now on.

The beginning of the thought for moving Yamanote-line train with dynamic scenery depends on the fact that just DynKit exists. Mr. Konstantin Kukushkin completes great work again. It's really great. I would like to say many thanks to him. By the way, I don't use Dynkit in FS2000 scenery. I don't use DOD, but Mr. Rafael Garcia Sanchez the author of DOD gave me valuable information about dynamic scenery. Thanks to him too. About FS2000 dynamic scenery, Mr. Manfred Moldenhauer who is the author of SCASM gave me very valuable information. Thanks to him very much.