And as it usually happens, I found the solution myself:

Is it okay to use "DelayCommand" to get the code to work?
Or does the programmer's saying work here: "If it works, then don't touch it!"?

引用自 Лёв：

Is it okay to use "DelayCommand" to get the code to work?
Or does the programmer's saying work here: "If it works, then don't touch it!"?

Yeah, it's fine to use DelayCommand. You will use it a lot, particularly with cutscenes.

A few notes from working on cutscenes myself:

• If you have a lot of commands that execute at the same time or in a very specific sequence, it can be useful to wrap them in a function and use delay command on that function. It helps if you need to alter the timing later or insert another action.
  
• Before you take control of the camera it can be useful to store and later restore the camera settings for the PC, put these statements at the start of your cutscene:
  
  AssignCommand(oPC, StoreCameraFacing()); SetCameraMode(oPC, CAMERA_MODE_TOP_DOWN);
  and at the end of the cutscene use the following command:
  
  AssignCommand(oPC, RestoreCameraFacing());
  I find the camera settings can be strange if you try to store them in a module enter event script, so for an opening cutscene you might want to set the PC's camera to something reasonable.
  
• Have a plan for what you want to do with the PC's animal companions, summons and familiars. IIRC, SoU and HotU unsummon them, but invisibility and paralysis can also work.
  
• The effect tagging functions can be useful for adding and removing effects from PCs and NPCs in cutscenes (e.g. custscene invisibility and ghost effects). However, they also don't exist in Diamond, so if you use them the module will be EE only.

DelayCommand is OK and perhaps necessary.

When a PC enters a module or area, for reasons unknown their position is undefined. If you print the location, you'll see that the area is OK, but the position is (0. 0. 0.) and the facing is 0.0.

The position is actually set shortly after the event.

So, in those event scripts, anything that depends on PC position will fail. SetCameraFacing fails because it is reset almost immediately. Functions of the type GetNearest# are unreliable. Conversations may not start if the PC is not yet next to the speaker, and so on.

One remedy is to use a trigger instead. Trigger OnEnter events are very reliable and seem to wait until the area is properly set up.

The other is to use a delay. From experience, it seems that as long as you choose a fairly generous delay, it will always work.

For conversations in particular, I find that a delay of 2 seconds on entering an area is advisable, otherwise you get Unknown Speakers and default portraits.

引用自 Proleric：

DelayCommand is OK and perhaps necessary.
One remedy is to use a trigger instead. Trigger OnEnter events are very reliable and seem to wait until the area is properly set up.

The fact is that I already use this method, but I still have to use the "DelayCommand" function.

In any case, thank you all for the advice! The main thing is that now everything has begun to work!