Unity3d hot update book-script (5) ngui

Let's take a practical look at how to combine ngui with C # lightedevil.

Ngui2.7 is used here because it is an open-source version. The latest ngui version cannot be used in our open-source project without the permission of the author.

 

The function completed in this example is to find three interfaces from the ngui example and switch them one by one with the lowest buttons.

This is based on the demo of mode1 in the previous framework.

It is driven by a state machine, which I recommend you to use scripts.

= This is a script and a program

The mode1 mode defines an interface class and is implemented by the script inherited from this type. Because AOT is always considered (compatible with IOS), our script has many restrictions, for example, the Il type cannot be generated during running.

If you are familiar with the AOT and JIT mechanisms, you will surely find that it is impossible for scripts to inherit program types.

Because our script is compatible with the C # syntax, in fact, this istate will be used separately in the program and in the script. They are two different things. It just looks exactly the same in syntax.

= This is a program

Through a class called scriptinstancestate, It is the istate in the program and its function is to call the istate in the script. Through this type, the script status and program status can be seamlessly switched.

There is a tongue twister:

In actual games, you can implement some States using programs, and some States using scripts.

Because our script is a strict subset of C #, the status of all scripts can be normally executed as a program.

The state of the program implementation, rewrite the syntax, and change it to the State that can be passed by C # light, which can be executed as a script.

Let's skip this. In fact, seamless switching is very simple. Let's look at it here.

= This is a program

S is the state, new is the program directly, and we create the scriptinstancestate from our bonding class, that is, the script.

Most operations are okay.

One annoying thing is the callback. Here, C # lightedrop is under rigorous consideration and only supports access to the event, while the use of ngui is not the event

Here we can modify the ngui without any adverse impact on the function.

= This is a script

This is the code in the script. It is relatively lazy to use anonymous functions. In fact, we recommend that you use a function defined independently in the script. Do you remember that we are a project that strictly takes care of AOT, anonymous functions cannot be generated.

It is an implementation that simulates anonymity, and there is additional overhead for closure.

Here onclick + = is the usage of event.

= This is a program

Here, you need to add an event before onclick. Currently, C # lightedrop only supports access to the event and cannot assign values to delegate directly.

= This is a program

The deletype must also be specifically implemented. Its definition is the same as the action <gameobject>. You just need to copy reghelper_deleaction and modify it.

The callback for script registration is not a recommended method. In fact, it can define an onclick event in istate, which is processed by the program and completed through the implementation interface in a centralized manner.

 

This example uses anonymous and custom events to show more aspects of C # lightedevil.

 

As for the recommended method of using C # lightedevil, the script and program can be connected through an interface and can be switched seamlessly.