Jump to content

The forgotten LUA API for dispensers


Yoarii
 Share

Recommended Posts

Dear NQ,

 

We in SVEA run an element shop, recently featured in The Helios Bulletin. We've developed a system to centrally update the screens for each of the 600+ dispensers so that our customers can see the price and batch size without having to click on the dispenser, in addition to making the shopping experience nicer.

 

Although updating all screens centrally saves a lot of time, the dispensers still needs to be manually updated with price (and batch size if that is to be changed). We did get a nice update to the UI for the dispensers a while back but that only helps with the initial setup, not the long-term management of the only way a "player market" can be created in the game right now.

 

Can we please have a word on when a LUA API for dispensers will be a thing?

 

These are the most important API functionalities the dispensers are missing:

 

  • SetPrice(price) - sets the price.
  • GetPrice() - Returns the currently set price

 

These are extras I thought would be nice to have

  • Activate() - Disables purchases from a container without having to go through the RDMS system, much like the VR Pod station needs to be activated via RMB.
  • Deactivate() - Opposite of Activate(), obviously
  • GetContainerId() - returns the ID of the connected container, or 0 if not yet connected.
  • HasBatchContents() - returns true if the dispenser has any configured batch contents.
  • BatchesAvailable() - returns the number of batches available in the connected container.

 

At first I thought that a function like SetBatchSize() would be good, but instead of that, lets change the dispenser such that the buyer can enter the number of batches they want to buy (up to whatever total the seller has configured)

 

You already know that there are other similar shops out there and while I don't speak for them, I think they too would appreciate the above proposed improvements.

 

Br,

 

Yoarii

 

PS: Not sure if tagging NQ like this actually helps in getting their attention, but here goes. @NQ-Deckard

 

 

 

Link to comment
Share on other sites

5 hours ago, blazemonger said:

I would not be in favor of NQ turning dispensers into market terminals. They are expected/supposed to deliver player run markets, not shoehorn dispensers into something they really should not be

I completely agree. A market terminal is something completely different, something I too would like to have, though I don't know how I'd like it to to work. A market terminal like the one on the current market hubs won't be enough, they'd need to have an extensive LUA API so that we can use the tooling we've purpose-built for running our shops, screen integration, data extraction to tools outside the game etc. On the other hand, they should work out-of-the-box so that anyone can use them.

 

All I'm asking for here is that NQ opens up an API to an already existing functionality in the dispenser as a QoL improvement for all the shop keepers out there.

Link to comment
Share on other sites

2 hours ago, Yoarii said:

A market terminal like the one on the current market hubs won't be enough, they'd need to have an extensive LUA API so that we can use the tooling we've purpose-built for running our shops, screen integration, data extraction to tools outside the game etc. On the other hand, they should work out-of-the-box so that anyone can use them.

And that ladies and gentlemen, is why this is feature is now how many years late?

NQ is to busy with nerfing stuff that actually works and adding low hanging fruit like a new VFX system that nobody asked for or needed, to be bothered with essential features that would require some work to complete.

Link to comment
Share on other sites

  • 1 month later...

I totally agree with author, adding just few API calls would make like easier.

Do we have dispensers? - Yes, so why not to make it better?

 

If NQ is planning ( I hope to see this piece of plan in the upcoming RoadMap ), then It will be great for big player's shops.

Dispensers won't be replaced.

So, Why not to make our life comfortable by the most demanding few APIs?

 

Link to comment
Share on other sites

getPermissionDebit() returns Bool
getPermissions() returns array of object permissions on object
giveMoney(float)
vendingMode(bool) true == dispenser, false == item purchase agent

 

so dispenser could work in both directions XD

Link to comment
Share on other sites

  • 3 weeks later...
1 hour ago, space_man said:

Hey sounds like the long awaited mining unit API is coming. Good thing, otherwise I'd forget to calibrate every Saturday.

 

Come on NQ... We're waiting.

That means they would have to program something useful. Instead they focus too hard on the grand vision they fail at basic shit that needs to happen.

WHERE IS THE ABILITY TO DISABLE MY FRIENDS LIST LOCATION LOCK FFS

Link to comment
Share on other sites

5 hours ago, Snipey said:

That means they would have to program something useful. Instead they focus too hard on the grand vision they fail at basic shit that needs to happen.

WHERE IS THE ABILITY TO DISABLE MY FRIENDS LIST LOCATION LOCK FFS

it should be an RDMS policy, just like they should have added this ages ago.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

I think having a dispenser GUI for personal and org owned dispenser management would rock. Let me mange all personal or org owned dispensers from one screen. Let me do everything outside stocking them from here. 

 

Maybe this could be the player market and part of the market UI we have today. 

 

Link to comment
Share on other sites

  • 2 weeks later...
On 4/13/2022 at 7:00 PM, Endstar said:

I think having a dispenser GUI for personal and org owned dispenser management would rock. Let me mange all personal or org owned dispensers from one screen. Let me do everything outside stocking them from here. 

 

Maybe this could be the player market and part of the market UI we have today. 

 

As long as it allows us to import/export all data points so we can use out-of-game tools to manage prices etc. etc.

Link to comment
Share on other sites

So ! 

First point, do not hesitate to ping on thread about the Lua. I can't spend a lot of time on the forum, because we have a lot of work to do, but even if I can check on time a week, it let know interesting and even useful threads about Lua ;)  Else I totally miss these thread and reply weeks (and month here 😅 later)

Secondly, so, I do not promise anything, but just would check your proposals about the dispenser API. So to sum your posts :

  • SetPrice(price) / GetPrice() - I don't see anything against that.
  • Activate() / Deactivate() - There is no state on dispensers currently, you activate ou deactivate it.
  • GetContainerId() - Would be the local id, the id of the container on the construct.
  • HasBatchContents() - If we add a function to get the content of the batch, this functions would be useless.
  • BatchesAvailable() - Can be a bit harder to be done, but indeed could be a nice to have.
  • getPermissionDebit() - No RDMS control on Lua yet, so not possible.
  • getPermissions() - Same as previous

For reversed dispenser, it require to add an other and specific element with so a new dev on that.

 

So to summarize, it would be (no promises guys huh 😉) ?? 

  • setBatchPrice([float] price, [bool] notify) : Set the price of the batch and if you want to notify the player (only if the price is 0).
  • [float] getBatchPrice() : Return the batch price set.
  • setDelay([float] delay) : Set the delay between two batch claim.
  • [float] getDelay() : Return the delay set between two batch claim.
  • setBatchLimit([int] limit) : Set the limit of batch per player.
  • getBatchLimit() : Return the limit of batch per player set.
  • setPlayerBeneficiary([int] pId) : Set the player with the given ID as beneficiary.
  • setOrgBeneficiary([int] oId) : Set the organisation with the given ID as beneficiary.
  • setTag([string] tag) : Set the tag of the dispenser.
  • [string] getTag() : Return the tag of the dispenser.
  • setBatchContent([table] content) : Set the batch content for the table in format {{id, quantity},{id, quantity}, ...}
  • [table] getBatchContent() : Return the batch content as table of pair itemId and quantity.
  • [int] getContainerId() : Return the local id of the container.
  • [int] getBatchAmount() : Returns the amount of batches available in the linked container.
  • [event] purchased([int] pId) : Emitted when a a player claim a batch.


The lack of an entity/portfolio API can be a hindrance to adding a distributor API, to designate the beneficiary. The item API was a requirement to consider the dispenser API addition.

Link to comment
Share on other sites

2 hours ago, NQ-Ligo said:

So ! 

First point, do not hesitate to ping on thread about the Lua. I can't spend a lot of time on the forum, because we have a lot of work to do, but even if I can check on time a week, it let know interesting and even useful threads about Lua ;)  Else I totally miss these thread and reply weeks (and month here 😅 later)

Secondly, so, I do not promise anything, but just would check your proposals about the dispenser API. So to sum your posts :

  • SetPrice(price) / GetPrice() - I don't see anything against that.
  • Activate() / Deactivate() - There is no state on dispensers currently, you activate ou deactivate it.
  • GetContainerId() - Would be the local id, the id of the container on the construct.
  • HasBatchContents() - If we add a function to get the content of the batch, this functions would be useless.
  • BatchesAvailable() - Can be a bit harder to be done, but indeed could be a nice to have.
  • getPermissionDebit() - No RDMS control on Lua yet, so not possible.
  • getPermissions() - Same as previous

For reversed dispenser, it require to add an other and specific element with so a new dev on that.

 

So to summarize, it would be (no promises guys huh 😉) ?? 

  • setBatchPrice([float] price, [bool] notify) : Set the price of the batch and if you want to notify the player (only if the price is 0).
  • [float] getBatchPrice() : Return the batch price set.
  • setDelay([float] delay) : Set the delay between two batch claim.
  • [float] getDelay() : Return the delay set between two batch claim.
  • setBatchLimit([int] limit) : Set the limit of batch per player.
  • getBatchLimit() : Return the limit of batch per player set.
  • setPlayerBeneficiary([int] pId) : Set the player with the given ID as beneficiary.
  • setOrgBeneficiary([int] oId) : Set the organisation with the given ID as beneficiary.
  • setTag([string] tag) : Set the tag of the dispenser.
  • [string] getTag() : Return the tag of the dispenser.
  • setBatchContent([table] content) : Set the batch content for the table in format {{id, quantity},{id, quantity}, ...}
  • [table] getBatchContent() : Return the batch content as table of pair itemId and quantity.
  • [int] getContainerId() : Return the local id of the container.
  • [int] getBatchAmount() : Returns the amount of batches available in the linked container.
  • [event] purchased([int] pId) : Emitted when a a player claim a batch.


The lack of an entity/portfolio API can be a hindrance to adding a distributor API, to designate the beneficiary. The item API was a requirement to consider the dispenser API addition.

Thank you for engaging with us, @NQ-Ligo

 

That sums it up pretty well, but wouldn't it be better to implement this in a similar way to industry machines, i.e. setDispenserPrice(id-of-dispenser, price, notify)? For such important things like prices etc. in dispensers, I think it would make sense to not have to rely on communication via emitters/receivers to distribute this information; having a single board to mange all dispensers in a construct would be very beneficial. I'm ofc talking from my own experience where we have an entire wall of programming boards, emitters/receivers (~400 or so) for each individual dispenser/screen pair. With this API implemented via the core (or an object we get via core.getDispenserController()) and the new item API I think I can completely remove the communication part which would remove something like 800 elements from our shop.

 

Another thought - setTag and getTag() shouldn't they be on all elements, not specific to the dispenser? Also, there can be multiple tags on an element so they need to take/return a list of tags.

Link to comment
Share on other sites

3 hours ago, NQ-Ligo said:

Activate() / Deactivate() - There is no state on dispensers currently, you activate ou deactivate it.

A dispenser that has not been set up in any way returns an error when a use is attempted, so the lua would just have to have a "reset" function, which disables the use.

 

Just check if
 

setBatchContent{{0, 0}}


disables use due to this. (I guess I would have to use an actually existing item ID and set amount to zero?)

 

Other than that, Yoarii and I may have the same amount of dispensers, but he sure is far more knowledgable when it comes to lua and dispensers in combination.

Link to comment
Share on other sites

Hi @Yoarii @Gottchar !

So to answer to remarks :

  • Have access from the core, and not via link :

Not for in fully honesty, firstly because it could push people to use more and more dispensers and so generate a large amount of server requests on changes.
Secondly, if you could be able to change the price, batch ...etc you would no longer need a soo large array of dispenser, no ?

  • Activate / Deactivate :

Sorry if I explained it wrong, the point is simply that there is no state. If we want to add this enable/disable feature, it just means we have to add it. ;)

 

My goal here is mainly to make sure I have a clear vision for you on what can be done, what needs to be done if we want to do it, and for me to make sure I understand what you want. ;) 

Link to comment
Share on other sites

16 minutes ago, NQ-Ligo said:

Not for in fully honesty, firstly because it could push people to use more and more dispensers and so generate a large amount of server requests on changes.
Secondly, if you could be able to change the price, batch ...etc you would no longer need a soo large array of dispenser, no ?

@NQ-Ligo Until dispensers allow the buyer (and later the seller in reverse dispensers) the ability to select the number batches to buy/sell, we're still forced to have at least two dispensers to sell both single/smaller amounts and larger amounts.

 

As to the number of server-requests/server load - I don't think that point is valid. With the per-dispenser API we'll just work around it by having a programming board per dispenser (just like we have now for each screen) that configures the dispenser on command from a central programming board. Same number of calls to the server, just from different programming boards, with whatever added load that means. Allowing it to be done from a single programming board would not only significantly reduce the number of elements needed, thus reducing both server and client load, it would also allow for a much more pleasant developer experience.

 

Side question: Since all constructs have a core, why is it not made available via something like system.getCore() instead of manually linking it?

 

25 minutes ago, NQ-Ligo said:

And in addition @Yoarii, for the getTag and setTag, not all elements have tags. And it's not the same thing here, than engine tags for example.

Ah, so these are not RDMS tags? What are they then? Just some arbitrary tag to attach some data to a dispenser?

Link to comment
Share on other sites

@Yoarii
 

First of all, the links are a mechanic made to limit things, and even though you can use a lot of programming boards ... etc, it's still not as convenient, and so it pushes players to not have too much of that. Simplifying things is going to push more people to do it, and the people who were already doing it, are going to be able to do it even more. That's why I said server requests. ;) 
 

And then we don't want to, by gamedesign, have control over everything without using links. On that point, it's a no-no. Even though we might consider adding subscription to events in Lua, links are still needed to limit players in DU for now. I can understand the frustration, believe me, but it is an essential part of the game. :) 
 

So, on that note, we will keep that link requirement. On that note, I remain firm sorry.


And for the tag on dispenser ; only one per dispenser, it's used to be able to group dispensers together and make that if you have delay set for example, it will prevent the player to take a batch on other dispensers of the tagged group.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...