Event listeners

[samdeane]

In general listening for events is more efficient than polling for status. Currently though, to listen for events a script author has to explicitly set up filters for each slot.

This does not really support general purpose scripts. It would be much better if scripts could register to listen for events using an API:

system.listenFor("statusChanged", elementID, function(status)
-- do something with new status
end)

This would also allow us to receive events for elements that are not explicitly connected to the controller.

[EasternGamer]

I think This would also allow us to receive events for elements that are not explicitly connected to the controller, is the part NQ won't want to happen. And might even be a limitation because of the link system.

I think if it's more for picking up changes to an element on a more base level (i.e., health changing), then it might be fine because you can't realistically link all 1000 elements to a programming board.

[samdeane]

I think This would also allow us to receive events for elements that are not explicitly connected to the controller, is the part NQ won't want to happen. And might even be a limitation because of the link system.

Yeah, it obviously works around a major limitation of the current system, and I can see that there might be resistance because of that. I think many of the limitations need serious reevaluation though. They were designed when the game was in a very different place, and they are applied quite inconsistently.

The fact that we can now get industry status for non-linked elements (for example) is a tacit admission that it's not practical to link everything via a tree of programming boards and databanks.

Someone needs to wipe the slate clean and actually redesign the Lua scripting from the ground up, starting by answering the question of what exactly they are trying to do.

[NQ-Ligo]

Hi there !

So! This is a hot topic! Let me try to be methodical.

So on the idea of event listeners, in idea I don't see any issue with that but it requires some changes on how the Lua system was made. So that would require a massive rework ... but that's something I'm planning.

However, on the idea of having event listeners via Lua with non-linked elements ... that's not something we want. So it's a no-no, or we find a good balance to remove the links but keep a limit on the number of interacted elements.

I hope that's clear enough ;)

[samdeane]

Thanks for the response @NQ-Ligo.

I kind of gave up on DU a while back as I found the scripting too limiting and the scripting tools too basic. I despaired of anything being done about it, as it seemed to be a deliberate and ideological decision. Whist I could see where the ideology was coming from, I fundamentally disagreed with it!

I am therefore very interested in this statement:

So that would require a massive rework ... but that's something I'm planning.

If there are indeed some big changes planned - even if only to the underlying implementation - and if there is any way I can input into it, I would be happy to do so. Just thought I’d put that out there, in case. Also, I’d love to give you access to most of my existing scripting work, which is all currently in private repos. DM me or hit me up on Discord/Forums (I am Samedi there).

[samdeane]

Whatever else happens, it’s great to see someone from NQ taking the time to respond to these suggestions, so thanks for that :)

[samdeane]

I despaired of anything being done about it, as it seemed to be a deliberate and ideological decision.

I do realise by the way that some of the Lua design is based around database and network bandwidth limitations. However, a lot of it just seems to be based around a rather confused idea of what should/shouldn’t be allowed - presumably so as not to “spoil” the game.

What this means in practice is that there are an enourmous amount of quality of life improvements that are blocked by the limitations of the API. Meanwhile, skill-based things that you might think should be kept for humans to do - like landing spaceships - are allowed!

Makes no sense to me…

(I like that landing space ships is allowed too, but I really wish I could also implement a better market UI, factory UI, and automate things like trains/etc in a way that gives the world some colour)

[NQ-Ligo]

I completely understand your point of view @samdeane . But there is a fact: we can't prevent autopilots from landing or flying. Otherwise, preventing it means ... like removing the whole Lua system regarding piloting. So no more custom Lua to control a ship or a specific/special design ... etc.

It's like removing the core Lua functionality of the game.

However, I'm trying to open up the Lua API a bit more since I joined the studio and took the position of Lua feature lead. However, I'm doing it gradually because I have other tasks to do and if I do it too quickly, I'll have to restrict it later due to abuse or automation, etc. And on top of that, there is a major overhaul needed from the way it was originally done.

To be clear, if an addition or change on Lua is abused or exploited; I remove it. We don't want to break the game with Lua. We want Lua to be part of the game, a tool, a key.

[samdeane]

Yeah, to be clear, I certainly don't want you to prevent autopilots!

What I'm saying is that many of the things that you do prevent are illogical, in a world where autopilots are allowed. The stated reasons for preventing them don't make a lot of sense.

It doesn't make sense that I can't automate the monorail I built. It doesn't make sense that I can't build quality-of-life user interfaces for things like factories and markets. It makes the DU world a much less interesting place to inhabit, when it being an interesting place surely ought to be the main objective.

[samdeane]

I'll have to restrict it later due to abuse or automation, etc. ... To be clear, if an addition or change on Lua is abused or exploited; I remove it. We don't want to break the game with Lua. We want Lua to be part of the game, a tool, a key.

This is the bit that I think is slightly misguided.

If a Lua feature provides an actual exploit opportunity, then it's a bug.

If a Lua feature allows people to grief, then you need to build tools to detect and remove the griefers, rather than removing the Lua feature.

If a Lua feature allows automation, that's where we disagree. I think a lot of automation is good, especially where it (a) adds life and interest to the world, or (b) fills in for poor user interface design or an incomplete implementation.

I've heard the argument that doing endless repetitive manual tasks is basically the way all MMOs work. I think that's a weak argument, and weak game design, and when the reason for restricting some Lua feature feels like it is based solely on that defensive attitude, it comes across to me as a big mistake.

Of course I understand that there are certain tasks that can't be allowed to be automated, but right now there's so little useful that can be done, it is really frustrating.

[samdeane]

However, I'm trying to open up the Lua API a bit more since I joined the studio and took the position of Lua feature lead. > ... And on top of that, there is a major overhaul needed from the way it was originally done.

Now on that front I completely understand, and sympathise. I've been that developer, coming into a large game codebase and realising that I wouldn't want to start from where I am :). Keeping everything working whilst taking the architecture apart and putting it back together again in a better shape is no easy task. Good luck!