@rise-maritime/keelson-js 0.6.0-alpha.255.dev.1 → 0.6.0-alpha.275.dev.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.d.ts +83 -8
- package/dist/index.js +23 -1
- package/dist/index.test.js +31 -0
- package/dist/interfaces/AlarmAck.d.ts +2 -2
- package/dist/interfaces/AlarmAck.js +2 -2
- package/dist/interfaces/ContainerControl.d.ts +239 -0
- package/dist/interfaces/ContainerControl.js +1053 -0
- package/dist/interfaces/ContainerHost.d.ts +403 -0
- package/dist/interfaces/ContainerHost.js +1230 -0
- package/dist/interfaces/ErrorResponse.d.ts +7 -2
- package/dist/interfaces/ErrorResponse.js +12 -2
- package/dist/interfaces/Route.d.ts +141 -6
- package/dist/interfaces/Route.js +309 -4
- package/dist/interfaces/RoutePlanner.d.ts +19 -1
- package/dist/interfaces/RoutePlanner.js +23 -1
- package/dist/interfaces/ScenarioControl.d.ts +132 -3
- package/dist/interfaces/ScenarioControl.js +439 -37
- package/dist/interfaces/VehicleNavigation.d.ts +55 -0
- package/dist/interfaces/VehicleNavigation.js +233 -1
- package/dist/interfaces/VehicleSimulatorControl.d.ts +0 -83
- package/dist/interfaces/VehicleSimulatorControl.js +1 -293
- package/dist/interfaces/serviceRegistry.d.ts +84 -8
- package/dist/interfaces/serviceRegistry.js +4 -0
- package/dist/interfaces.json +2 -0
- package/dist/payloads/AdviceDisposition.d.ts +55 -0
- package/dist/payloads/AdviceDisposition.js +242 -0
- package/dist/payloads/ChecklistHandover.d.ts +522 -0
- package/dist/payloads/ChecklistHandover.js +1735 -0
- package/dist/payloads/ContainerHost.d.ts +407 -0
- package/dist/payloads/ContainerHost.js +1245 -0
- package/dist/payloads/Encounter.d.ts +104 -0
- package/dist/payloads/Encounter.js +573 -0
- package/dist/payloads/NavigationAdvice.d.ts +94 -0
- package/dist/payloads/NavigationAdvice.js +596 -0
- package/dist/payloads/NavigationState.d.ts +90 -0
- package/dist/payloads/NavigationState.js +377 -0
- package/dist/payloads/Route.d.ts +142 -6
- package/dist/payloads/Route.js +318 -4
- package/dist/payloads/RouteExecution.d.ts +7 -0
- package/dist/payloads/ScenarioEvent.d.ts +14 -0
- package/dist/payloads/ScenarioEvent.js +16 -0
- package/dist/payloads/index.d.ts +1 -1
- package/dist/payloads/index.js +2 -2
- package/dist/payloads/index.keelson.d.ts +10 -4
- package/dist/payloads/index.keelson.js +10 -4
- package/dist/qos.json +6 -0
- package/dist/subjects.json +20 -1
- package/package.json +1 -1
|
@@ -1,6 +1,109 @@
|
|
|
1
1
|
import { BinaryReader, BinaryWriter } from "@bufbuild/protobuf/wire";
|
|
2
|
+
import { Duration } from "./google/protobuf/duration";
|
|
2
3
|
import { Empty } from "./google/protobuf/empty";
|
|
3
4
|
export declare const protobufPackage = "keelson.interfaces.scenario_control";
|
|
5
|
+
/**
|
|
6
|
+
* One scenario the responder is willing to be asked about. Deliberately
|
|
7
|
+
* thin: the fields are the ones an operator needs to *choose* between two
|
|
8
|
+
* scenarios, not a description of what a scenario is. What a scenario is
|
|
9
|
+
* varies by simulator, and pinning that here would bind every
|
|
10
|
+
* implementation to one — the same reason LoadRequest.scenario is opaque.
|
|
11
|
+
*/
|
|
12
|
+
export interface ScenarioInfo {
|
|
13
|
+
/**
|
|
14
|
+
* Exactly what `load` takes. A listing whose ids are not loadable ids is
|
|
15
|
+
* a listing a picker cannot act on.
|
|
16
|
+
*/
|
|
17
|
+
scenarioId: string;
|
|
18
|
+
/** One line, from the document. Empty if it carries none. */
|
|
19
|
+
description: string;
|
|
20
|
+
/**
|
|
21
|
+
* Content hash of the scenario as the responder reads it — the same hash
|
|
22
|
+
* ScenarioStatus broadcasts, so a picker can tell which of these is the
|
|
23
|
+
* running one, and two responders offering the same id can be compared.
|
|
24
|
+
*/
|
|
25
|
+
scenarioHash: string;
|
|
26
|
+
/**
|
|
27
|
+
* How many vessels the scenario declares. Absent when the responder did
|
|
28
|
+
* not count; present 0 is a real answer — an environment-only scenario.
|
|
29
|
+
*/
|
|
30
|
+
vesselCount?: number | undefined;
|
|
31
|
+
/**
|
|
32
|
+
* The scenario's declared length in ticks, present only when it declares
|
|
33
|
+
* an end. Absent means there is no declared end to report: the scenario
|
|
34
|
+
* is open-ended, or the responder could not determine one. This listing
|
|
35
|
+
* deliberately does not distinguish those two — a picker renders both the
|
|
36
|
+
* same way, and a responder that guessed between them would be inventing
|
|
37
|
+
* the distinction rather than reporting it.
|
|
38
|
+
*/
|
|
39
|
+
durationTicks?: number | undefined;
|
|
40
|
+
/**
|
|
41
|
+
* The fixed step each tick represents. A Duration rather than a scalar of
|
|
42
|
+
* milliseconds so it is directly comparable with
|
|
43
|
+
* keelson.ScenarioStatus.step_size — a picker holding a listed scenario
|
|
44
|
+
* against the running one should not have to convert between encodings of
|
|
45
|
+
* the same quantity. Absent when the responder does not know.
|
|
46
|
+
*/
|
|
47
|
+
stepSize: Duration | undefined;
|
|
48
|
+
loadability: ScenarioInfo_Loadability;
|
|
49
|
+
/**
|
|
50
|
+
* Why, in the words the failed load would have used. Set when loadability
|
|
51
|
+
* is NOT_LOADABLE; it may also explain a LOADABILITY_UNKNOWN. It MUST be
|
|
52
|
+
* empty when loadability is LOADABLE — a caller must never have to decide
|
|
53
|
+
* whether text here is a warning about a scenario it can load.
|
|
54
|
+
*/
|
|
55
|
+
reason: string;
|
|
56
|
+
}
|
|
57
|
+
/**
|
|
58
|
+
* Whether the responder would load this scenario if asked.
|
|
59
|
+
*
|
|
60
|
+
* An enum with a countable unknown rather than a bool, because the zero
|
|
61
|
+
* value is what a partially-populated row reports and the affirmative has
|
|
62
|
+
* to be the safe one: LOADABILITY_UNKNOWN means the responder expressed no
|
|
63
|
+
* opinion, and a picker must offer such a row and let `load` answer. A
|
|
64
|
+
* bool would make every row a simpler responder builds read as "would
|
|
65
|
+
* refuse", greying out a whole library nobody has anything against.
|
|
66
|
+
*
|
|
67
|
+
* NOT_LOADABLE rows stay on the wire rather than being filtered out,
|
|
68
|
+
* because both alternatives are worse. Omitting them hides files the
|
|
69
|
+
* operator can see in the library and leaves them asking why one is
|
|
70
|
+
* missing; listing them as loadable is a lie the picker only discovers by
|
|
71
|
+
* trying. A simulator whose scenario language is still growing has these
|
|
72
|
+
* constantly: the document parses, and names a construct this build
|
|
73
|
+
* cannot elaborate.
|
|
74
|
+
*/
|
|
75
|
+
export declare enum ScenarioInfo_Loadability {
|
|
76
|
+
LOADABILITY_UNKNOWN = 0,
|
|
77
|
+
LOADABLE = 1,
|
|
78
|
+
NOT_LOADABLE = 2,
|
|
79
|
+
UNRECOGNIZED = -1
|
|
80
|
+
}
|
|
81
|
+
export declare function scenarioInfo_LoadabilityFromJSON(object: any): ScenarioInfo_Loadability;
|
|
82
|
+
export declare function scenarioInfo_LoadabilityToJSON(object: ScenarioInfo_Loadability): string;
|
|
83
|
+
export interface ListScenariosRequest {
|
|
84
|
+
/**
|
|
85
|
+
* Optional; the responder decides what it means (an id prefix, a glob).
|
|
86
|
+
* No filter lists everything the responder is willing to list. Same
|
|
87
|
+
* contract as ListCheckpointsRequest.pattern and ListFilesRequest.pattern.
|
|
88
|
+
*/
|
|
89
|
+
pattern: string;
|
|
90
|
+
}
|
|
91
|
+
export interface ListScenariosResponse {
|
|
92
|
+
/**
|
|
93
|
+
* Where the responder is listing from, for the reason its two siblings
|
|
94
|
+
* carry it: an operator choosing between two scenarios with the same id
|
|
95
|
+
* needs to know whether they came from the same place.
|
|
96
|
+
*/
|
|
97
|
+
baseDirectory: string;
|
|
98
|
+
/** Ordered by scenario_id, so a listing read twice reads the same way. */
|
|
99
|
+
scenarios: ScenarioInfo[];
|
|
100
|
+
/**
|
|
101
|
+
* True when the responder capped the listing. On the wire because a
|
|
102
|
+
* listing that quietly stopped short reads as "that is all of them", and
|
|
103
|
+
* an operator would go looking for a scenario that is in fact there.
|
|
104
|
+
*/
|
|
105
|
+
truncated: boolean;
|
|
106
|
+
}
|
|
4
107
|
export interface LoadRequest {
|
|
5
108
|
/**
|
|
6
109
|
* Identifier of the scenario to load, as the responder understands it —
|
|
@@ -29,8 +132,6 @@ export interface SetRateRequest {
|
|
|
29
132
|
* individual command can grow a return field later without a breaking
|
|
30
133
|
* type change and without that field bleeding onto the other commands.
|
|
31
134
|
*/
|
|
32
|
-
export interface LoadResponse {
|
|
33
|
-
}
|
|
34
135
|
export interface StartResponse {
|
|
35
136
|
}
|
|
36
137
|
export interface PauseResponse {
|
|
@@ -41,6 +142,23 @@ export interface ResetResponse {
|
|
|
41
142
|
}
|
|
42
143
|
export interface SetRateResponse {
|
|
43
144
|
}
|
|
145
|
+
export interface LoadResponse {
|
|
146
|
+
/**
|
|
147
|
+
* What was actually loaded, resolved. `scenario` in the request is
|
|
148
|
+
* whatever the caller typed; these are the responder's answer to it.
|
|
149
|
+
*
|
|
150
|
+
* Returned rather than left to the status broadcast for the reason
|
|
151
|
+
* StepResponse.tick gives below: a caller should not have to race a 1 Hz
|
|
152
|
+
* status sample to learn the result of its own call. It also makes an
|
|
153
|
+
* ambiguous id visible — a caller that asked for "harbor" and got back a
|
|
154
|
+
* hash it did not expect can say so.
|
|
155
|
+
*
|
|
156
|
+
* No run id here; see "Run identity" above. A load lands in STOPPED, where
|
|
157
|
+
* no run has begun.
|
|
158
|
+
*/
|
|
159
|
+
scenarioId: string;
|
|
160
|
+
scenarioHash: string;
|
|
161
|
+
}
|
|
44
162
|
export interface StepResponse {
|
|
45
163
|
/**
|
|
46
164
|
* Where the clock came to rest. Returned rather than left to the status
|
|
@@ -50,21 +168,32 @@ export interface StepResponse {
|
|
|
50
168
|
tick: number;
|
|
51
169
|
simulationTime: Date | undefined;
|
|
52
170
|
}
|
|
171
|
+
export declare const ScenarioInfo: MessageFns<ScenarioInfo>;
|
|
172
|
+
export declare const ListScenariosRequest: MessageFns<ListScenariosRequest>;
|
|
173
|
+
export declare const ListScenariosResponse: MessageFns<ListScenariosResponse>;
|
|
53
174
|
export declare const LoadRequest: MessageFns<LoadRequest>;
|
|
54
175
|
export declare const StepRequest: MessageFns<StepRequest>;
|
|
55
176
|
export declare const SetRateRequest: MessageFns<SetRateRequest>;
|
|
56
|
-
export declare const LoadResponse: MessageFns<LoadResponse>;
|
|
57
177
|
export declare const StartResponse: MessageFns<StartResponse>;
|
|
58
178
|
export declare const PauseResponse: MessageFns<PauseResponse>;
|
|
59
179
|
export declare const StopResponse: MessageFns<StopResponse>;
|
|
60
180
|
export declare const ResetResponse: MessageFns<ResetResponse>;
|
|
61
181
|
export declare const SetRateResponse: MessageFns<SetRateResponse>;
|
|
182
|
+
export declare const LoadResponse: MessageFns<LoadResponse>;
|
|
62
183
|
export declare const StepResponse: MessageFns<StepResponse>;
|
|
63
184
|
export type ScenarioControlDefinition = typeof ScenarioControlDefinition;
|
|
64
185
|
export declare const ScenarioControlDefinition: {
|
|
65
186
|
readonly name: "ScenarioControl";
|
|
66
187
|
readonly fullName: "keelson.interfaces.scenario_control.ScenarioControl";
|
|
67
188
|
readonly methods: {
|
|
189
|
+
readonly list_scenarios: {
|
|
190
|
+
readonly name: "list_scenarios";
|
|
191
|
+
readonly requestType: MessageFns<ListScenariosRequest>;
|
|
192
|
+
readonly requestStream: false;
|
|
193
|
+
readonly responseType: MessageFns<ListScenariosResponse>;
|
|
194
|
+
readonly responseStream: false;
|
|
195
|
+
readonly options: {};
|
|
196
|
+
};
|
|
68
197
|
readonly load: {
|
|
69
198
|
readonly name: "load";
|
|
70
199
|
readonly requestType: MessageFns<LoadRequest>;
|