API UO CallSub en

UO.CallSub

Русский · English · Українська · Deutsch · Français · Italiano · Español · 繁體中文 · 日本語 · 한국어

UO.CallSub · UO.FunRunning · UO.SubExists

ClassicUO • Runtime API

Requests a separate task for a procedure already known to the manager. Use it to start a monitor or independent job from a controller. It is asynchronous, unlike an ordinary Basic call that waits for a result.

Exact syntax

UO.CallSub(subrutineName:String) -> Unit

Parameters

• subrutineName — Required String subrutineName is the catalogue's Sub/Function name, such as WeightWatch. Not a path, file name, run index, source text or label changed with SetScriptName. Matching ignores case but does not trim spaces. This call cannot pass procedure arguments.

Returns

Unit: no value, function result or successful-start acknowledgement. An unknown name starts nothing. Use a normal Basic MyFunction(...) call for synchronous execution.

Behavior

• Only this session's catalogue is searched. Duplicate names select the first match: give independent procedures unique names. These three commands neither load an unknown file nor search the disk.
• CallSub supplies zero arguments. Private access, syntax errors, required parameters, disabled Basic or the single-procedure rule can reject the launch; inspect IDE status/errors. Calling an active procedure again neither duplicates nor resumes it. A start after cancellation may wait for prior cleanup. The controller's next statement does not wait for completion.
• FunRunning resolves the source procedure name/key, not a renamed display label. Pausing retains the run and returns 1. Cancellation returns 0 even while cleanup continues. A check and a subsequent call are not atomic: the task can finish between them.
• SubExists can return 1 for a Private or invalid definition: existence is not launch permission. Stopping a run or closing its editor tab does not necessarily remove its catalogue entry. Reloading a changed file removes obsolete definitions. A function loaded only into a separate runtime need not be registered with the manager.

Internal functions: from call to result

These are real implementation stages; their C# names are not additional UO commands. All executable Basic helpers are fully defined in the examples.

1. CallSub

Required String subrutineName is the catalogue's Sub/Function name, such as WeightWatch. Not a path, file name, run index, source text or label changed with SetScriptName. Matching ignores case but does not trim spaces. This call cannot pass procedure arguments.

Unit: no value, function result or successful-start acknowledgement. An unknown name starts nothing. Use a normal Basic MyFunction(...) call for synchronous execution.

Project source: external/InjectionScript/src/InjectionScript/Runtime/InjectionApiUO.cs; function CallSub.

2. FindProcedureByName

Only this session's catalogue is searched. Duplicate names select the first match: give independent procedures unique names. These three commands neither load an unknown file nor search the disk.

SubExists can return 1 for a Private or invalid definition: existence is not launch permission. Stopping a run or closing its editor tab does not necessarily remove its catalogue entry. Reloading a changed file removes obsolete definitions. A function loaded only into a separate runtime need not be registered with the manager.

Project source: src/ClassicUO.Client/Game/Managers/YokoInjectionManager.cs; function FindProcedureByName.

3. Exec

Requests a separate task for a procedure already known to the manager. Use it to start a monitor or independent job from a controller. It is asynchronous, unlike an ordinary Basic call that waits for a result.

CallSub supplies zero arguments. Private access, syntax errors, required parameters, disabled Basic or the single-procedure rule can reject the launch; inspect IDE status/errors. Calling an active procedure again neither duplicates nor resumes it. A start after cancellation may wait for prior cleanup. The controller's next statement does not wait for completion.

Project source: src/ClassicUO.Client/Game/Managers/ClassicUOInjectionApiBridge.cs; function Exec.

These are real implementation stages; their C# names are not additional UO commands. All executable Basic helpers are fully defined in the examples.

Examples

Launch a monitor and continue Main

# Launch a monitor and continue Main
#
# Requests a separate task for a procedure already known to the manager. Use it to start a
# monitor or independent job from a controller. It is asynchronous, unlike an ordinary Basic
# call that waits for a result.
#
# Unit: no value, function result or successful-start acknowledgement. An unknown name starts
# nothing. Use a normal Basic MyFunction(...) call for synchronous execution.

SUB Main()
    # WeightWatch names the procedure below. Main returns 77 without waiting for its three samples;
    # 77 belongs to Main, not CallSub.
    # Save each example as a separate file, load it in the IDE/manager and start Main so the other
    # procedures are registered. WeightWatch/ManaWatch are fully defined teaching helpers: three
    # weight/mana samples, Wait(1000) meaning 1000 ms, output only while in the world. They are
    # finite monitors; pauses can extend elapsed time. The two-task example requires concurrent
    # procedures to be enabled.

    UO.CallSub("WeightWatch")
    Return 77
END SUB

Sub WeightWatch()
    Dim sample
    For sample = 1 To 3
        If UO.Connected() Then
            UO.Print("Weight: " & CStr(UO.Weight()))
        End If
        UO.Wait(1000)
    Next
End Sub

Parameter and execution notes:

• WeightWatch names the procedure below. Main returns 77 without waiting for its three samples; 77 belongs to Main, not CallSub.
• Save each example as a separate file, load it in the IDE/manager and start Main so the other procedures are registered. WeightWatch/ManaWatch are fully defined teaching helpers: three weight/mana samples, Wait(1000) meaning 1000 ms, output only while in the world. They are finite monitors; pauses can extend elapsed time. The two-task example requires concurrent procedures to be enabled.

Keep existing or paused work intact

# Keep existing or paused work intact
#
# Requests a separate task for a procedure already known to the manager. Use it to start a
# monitor or independent job from a controller. It is asynchronous, unlike an ordinary Basic
# call that waits for a result.
#
# Unit: no value, function result or successful-start acknowledgement. An unknown name starts
# nothing. Use a normal Basic MyFunction(...) call for synchronous execution.

SUB Main()
    # StartIfIdle checks the definition, then activity. False means no request was sent. True means
    # only that CallSub was requested, not that it started or completed successfully.
    # Save each example as a separate file, load it in the IDE/manager and start Main so the other
    # procedures are registered. WeightWatch/ManaWatch are fully defined teaching helpers: three
    # weight/mana samples, Wait(1000) meaning 1000 ms, output only while in the world. They are
    # finite monitors; pauses can extend elapsed time. The two-task example requires concurrent
    # procedures to be enabled.

    Return StartIfIdle("WeightWatch")
END SUB

Function StartIfIdle(name) As Boolean
    If Not UO.SubExists(name) Then
        Return False
    End If
    If UO.FunRunning(name) Then
        Return False
    End If
    UO.CallSub(name)
    Return True
End Function

Sub WeightWatch()
    Dim sample
    For sample = 1 To 3
        If UO.Connected() Then
            UO.Print("Weight: " & CStr(UO.Weight()))
        End If
        UO.Wait(1000)
    Next
End Sub

Parameter and execution notes:

• StartIfIdle checks the definition, then activity. False means no request was sent. True means only that CallSub was requested, not that it started or completed successfully.
• Save each example as a separate file, load it in the IDE/manager and start Main so the other procedures are registered. WeightWatch/ManaWatch are fully defined teaching helpers: three weight/mana samples, Wait(1000) meaning 1000 ms, output only while in the world. They are finite monitors; pauses can extend elapsed time. The two-task example requires concurrent procedures to be enabled.

Two independent monitors

# Two independent monitors
#
# Requests a separate task for a procedure already known to the manager. Use it to start a
# monitor or independent job from a controller. It is asynchronous, unlike an ordinary Basic
# call that waits for a result.
#
# Unit: no value, function result or successful-start acknowledgement. An unknown name starts
# nothing. Use a normal Basic MyFunction(...) call for synchronous execution.

SUB Main()
    # The calls start WeightWatch and ManaWatch independently. They do not share local variables;
    # output ordering is not guaranteed.
    # Save each example as a separate file, load it in the IDE/manager and start Main so the other
    # procedures are registered. WeightWatch/ManaWatch are fully defined teaching helpers: three
    # weight/mana samples, Wait(1000) meaning 1000 ms, output only while in the world. They are
    # finite monitors; pauses can extend elapsed time. The two-task example requires concurrent
    # procedures to be enabled.

    UO.CallSub("WeightWatch")
    UO.CallSub("ManaWatch")
END SUB

Sub WeightWatch()
    Dim sample
    For sample = 1 To 3
        If UO.Connected() Then
            UO.Print("Weight: " & CStr(UO.Weight()))
        End If
        UO.Wait(1000)
    Next
End Sub

Sub ManaWatch()
    Dim sample
    For sample = 1 To 3
        If UO.Connected() Then
            UO.Print("Mana: " & CStr(UO.Mana()))
        End If
        UO.Wait(1000)
    Next
End Sub

Parameter and execution notes:

• The calls start WeightWatch and ManaWatch independently. They do not share local variables; output ordering is not guaranteed.
• Save each example as a separate file, load it in the IDE/manager and start Main so the other procedures are registered. WeightWatch/ManaWatch are fully defined teaching helpers: three weight/mana samples, Wait(1000) meaning 1000 ms, output only while in the world. They are finite monitors; pauses can extend elapsed time. The two-task example requires concurrent procedures to be enabled.