Doloro GDK 22 .1.0 Beta
by Tauri Interactive
|
Following subject attempts to clarify best practices of work with the module's features.
The subject skips details of services work process. You may find detailed information by reading of following subjects.
You also may find useful exploration of demo scenes shared with the package.
StoragesDatabase
works as a singleton instance that can be accessed by following call:
Database is never null
.
To clear the database enough to call Clear()
handler by following template:
Database clearance supposed to release entire related on-scene instances in case they object managed by the database or services. Be sure to include any custom objects into Dispose
handlers where are supported or release they in OnDestroy
callbacks.
To create a new storage entry, you have to follow the next template:
During creation we're receiving an ID provided by the database to a new storage.
Using this ID, you may access the container lately.
You also may create a new storage directly from a scene using StorageCaller
component.
Read more about: Auto load storages on a scene.
To delete a storage at database you need to know its id
.
The data base is serializable object and can be easily saved by using of the Serialization Tools features.
Following example shows the way to save database to file system at the application's folder.
The next example demonstrates a conversion to binary data that can be used lately as you need.
The data base is serializable object and can be easily load by using of the Serialization Tools features.
To load database, you have to provide binary data \ binary file.
Alternatively, you may load database from binary array other than file system.
To operate a StorageDatabase.StorageContainer
you have to call an Storage instance bond with the database entry.
There are several ways to rent an entity but the traditional one is to ask for entity with the Storage.id
provided by the StoragesDatabase
during storage registration.
Renting by storage ID:
Renting by database entry:
Both the Storage
is disposable object so you may access it with using
keyword.
When you are done with entity access, and it's not required anymore you have to release it with the same source as it was rented.
Release by ID:
Release by on-scene entity:
Release by data sources:
Both the Storage
and StorageContainer
is disposable objects so you may access them with using
keyword.
You also may access directly a database entry without loading related Storage
resource entity with it.
You may force call of Storage
entity on a scene using StorageCaller
component on any object at the scene, avoiding manual API calls.
The component allows both:
StorageCaller
component.In case of creating a new entry at the database reads entire AStorageFetuare
components data and sets they to the entry. That allows you to fully configurate the Storage
at a scene it must be located avoiding manual code declaration.
Read more: Features and provided In-box implementations.
Explore API: Doloro.InvetorySystem.StorageCaller
The system no allows manual modification of the storage that allows to prevent frequent bugs with items. All the transactions with storages managed with the Trasaction Service via orders.
To add items to a storage you need to know a destination storage ID or has reference to its data container or rented entity.
Then you need to call TransactionService
API member named as ExecuteAddOrder
most suitable from your arguments. As example:
The add order may fail transaction and return false
in case the storage has mask features that not allows item or its amount to be added.
To remove items from a storage you have to know target storage ID or has reference to its data container, or rented entity.
Then you need to call TransactionService
API member named as ExecuteRemoveOrder
most suitable from your arguments. As example:
The remove order will be failed and return false
in case the resource not found in the storage, or it has no enough amount.
To transfer some items from one storage to other you have to execute TransactionOrder
between them.
For this you have a 2 ways: Instant, Manual.
To execute a transfer order between two storages instantly you enough to call one of TransactionService
API members named as InstantTransactionOrder
with most suitable arguments. As example:
Transaction may fail and return false
in case the storage has mask features that do not allow item or its amount to be added to destination storage.
For some systems you may need to place a transaction that will make an items \ space reservation at storages but not execute it instantly leaving an opportunity to cancel the transaction.
For such operations you have to use TransactionService
API members named as PlaceTransactionOrder
.
Such a handler makes reservation of items. Also it can call reservation process at AStorageFeature
components related to a storage with IReservationAgent
interface.
Read more: Reservation Agent
Next you may confirm or cancel the order via the TransactionService
by calling of ConfirmTransactionOrder
or CancelTransactionOrder
member.
To confirm:
To cancel:
You may find entire orders place for a storage or orders placed between 2 storages using TrasactionService
API members names as FindOrders
.
The API also allows you to filter order to discard from selection some not passing a condition.
Following example demonstrates a case when you are selecting only orders with a certain service code applied to the order during its place process.