Friday Facts #319 - New T-shirts & Lua event filtering

[TheKingOfFailure]

Hi, will there be a t-shirt with printed factorio base?
I remember some time ago you had this big banner https://cdn.factorio.com/assets/img/blo ... 9-img3.jpg
It would be great to have a t-shirt with this huge base printed on it.

I would love this too!

It would be cool if the artists could come up with a simplified wireframe-esque base and have that pattern covering the whole shirt, as opposed to the big rectangle of image plastic this would create.

I'd like to see more stealth opions like the factorio or wube logo over the breast pocket area. Or a cheesey quote like "keep on moving" underlined with belts

[stretch611]

I can't believe that I have had my grey Factorio T-shirt for nearly 2 years now. (received just before Christmas, right after the initial release.)

I like the inserter design, but I really think that the red long-handed inserter is most appropriate one for me... Any chance of these in the future?

[Phasma Felis]

Shirts look great! I would love one with just a big version of the eight-toothed rusty gear logo, though.

[jan1i3]

Long awaited, Rseding. Thanks.

Still missing: Schedule time-events. E.g.:
- raise an event every 60 ticks, as payload the index-number of that event
- raise event in 200 ticks, then in 250, then in 480 ticks... (a list of wanted time-events plus some payload for that event)

And if this scheduler works:
- raise an event in a tick where no other event is raised (to use that unused CPU time and make background calculations)

1) there is event.on_nth_tick() if that is what you mean
2) scheduling will not work because lua functions cannot be serialized savely (most of the time/basically always), so upon save and load the events would be forgotten.
Although there is the possibility to store ids to functions instead of the functions themselfs, that would mean the mod has to register the same functions with the same ids every time upon loading a save (mod load)
(and migrate them properly)

3) i like that idea. might need like a max tick delay so it doesn't never run

My general thoughts:
I really like the filters
Though the current implementation of (core/lualib/)event_handler.lua does not work with them.
but i'm pretty sure it is possible to work with some changes.

only downside is, once a more generic system is using that eventhandler, it cannot rely on the filters it registered, since something else might have registered the same event but with different filters, and those have to be or-ed together.
maybe it's time for a (significantly more complex?) event system where you can subscribe multiple handlers to the same event. I mean that is basically what the event_handler is doing - on the lua side.

[ssilk]

1) there is event.on_nth_tick() if that is what you mean

Ah, sorry and thanks, my knowledge needs to be updated, since it is more than 2 years old.

maybe it's time for a (significantly more complex?) event system where you can subscribe multiple handlers to the same event. I mean that is basically what the event_handler is doing - on the lua side.

I would prefer to use C++ code instead of a LUA-library code. It's just so much faster.

[Klonan]

Though the current implementation of (core/lualib/)event_handler.lua does not work with them.
but i'm pretty sure it is possible to work with some changes.

only downside is, once a more generic system is using that eventhandler, it cannot rely on the filters it registered, since something else might have registered the same event but with different filters, and those have to be or-ed together.
maybe it's time for a (significantly more complex?) event system where you can subscribe multiple handlers to the same event. I mean that is basically what the event_handler is doing - on the lua side.

Yes I was thinking about the base game event handler, it doesn't really seem like its too possible to make it work with the new filters, as different libs might want the same event with different filters,
So it would mean somehow reimplementing the filters through the event handler, which then completely defeats the point

For now I am not worried about it, I am happy with how it works so far

[darkfrei]

I can't believe that I have had my grey Factorio T-shirt for nearly 2 years now. (received just before Christmas, right after the initial release.)

I have one from June 2017, from Prague, but new T-shirts looking also cool! Especially yellow and light green.

[Honktown]

Hey! I made a prototype filter for my mod. I still want to do n-deep properties, but it can do a first-pass 0 and 1-deep property check. I bet yours doesn't handle retrieving a subitem and checking that for properties, jerk.

Also:

From the description of event handling... it looks like events don't own who they're supposed to trigger? That sounds awful. You can also get a performance improvement if you use the same memory block, and only store it for long enough for whoever's listening to hopefully catch it. Multicasting.

[theolderbeholder]

Merchandise is still paypal only?
How about: A parcel containing units of a currency of your choosing, order and shipping information and some chocolate as an incentive arrives at your office?

[movax20h]

On a topic of Lua. Did you investigated using LuaJIT instead of normal Lua? It is very compatible with lua scripts and even Lua C APIs, and do provide substantial performance boost in many cases, it also includes very fast interpreter and essentially is never slower than normal Lua. It is supported on most major platforms just fine.

I checked the Linux binary, and it looks like you are using pretty standard Lua right now.

It would benefit some mods a lot I think.

[coderpatsy]

On a topic of Lua. Did you investigated using LuaJIT instead of normal Lua? It is very compatible with lua scripts and even Lua C APIs, and do provide substantial performance boost in many cases, it also includes very fast interpreter and essentially is never slower than normal Lua. It is supported on most major platforms just fine.

I checked the Linux binary, and it looks like you are using pretty standard Lua right now.

It would benefit some mods a lot I think.

From what I've seen, LuaJIT is not fully compatible with Lua 5.2, and Factorio uses a modified Lua 5.2.1. So they'd have to put in the work to make it compatible, which is probably not worth the effort (at least, not before Factorio 1.0).

[movax20h]

On a topic of Lua. Did you investigated using LuaJIT instead of normal Lua? It is very compatible with lua scripts and even Lua C APIs, and do provide substantial performance boost in many cases, it also includes very fast interpreter and essentially is never slower than normal Lua. It is supported on most major platforms just fine.

I checked the Linux binary, and it looks like you are using pretty standard Lua right now.

It would benefit some mods a lot I think.

From what I've seen, LuaJIT is not fully compatible with Lua 5.2, and Factorio uses a modified Lua 5.2.1. So they'd have to put in the work to make it compatible, which is probably not worth the effort (at least, not before Factorio 1.0).

Yes, LuaJIT is more of a Lua 5.1 at the moment. I didn't say it is something to do before 1.0, not at all. Just something to look at later.

[eradicator]

Btw, now that filters are thing, i'm officially requesting data stage filters, just for the record: viewtopic.php?t=77494

―――――――――――――――――――――――――――

Yes, LuaJIT is more of a Lua 5.1 at the moment. I didn't say it is something to do before 1.0, not at all. Just something to look at later.

I always wondered why they didn't already change. Now i know it's a different base version, thanks! ;)

Long awaited, Rseding. Thanks. :)

Still missing: Schedule time-events. E.g.:
- raise an event every 60 ticks, as payload the index-number of that event
- raise event in 200 ticks, then in 250, then in 480 ticks... (a list of wanted time-events plus some payload for that event)

And if this scheduler works:
- raise an event in a tick where no other event is raised (to use that unused CPU time and make background calculations)

My ugly private event handler actually has had all those features for quite a while. Filters, delayed queueing, unqueing, multiple handlers per event, stored payload, prefetching of LuaPlayer, (naive) load balancing. It requires each event handler to be registered with a unique name. And in the background it builds a repeating queue for on_tick stuff. I always felt that it's lacking in code beauty so i never released it.

So it would mean somehow reimplementing the filters through the event handler, which then completely defeats the point

While it might reduce the point for performance it's imho still a significant reduction in code complexity of the handler because most of the time the filters are very similar.

[Honktown]

There, now my searching can filter n-deep properties and their value AND an item that has a DIFFERENT n-deep property and value, in completely different category!

ASSHOLE

AND I EVEN FIXED THE BUGS

[Optera]

Long awaited, Rseding. Thanks.

Still missing: Schedule time-events. E.g.:
- raise an event every 60 ticks, as payload the index-number of that event
- raise event in 200 ticks, then in 250, then in 480 ticks... (a list of wanted time-events plus some payload for that event)

And if this scheduler works:
- raise an event in a tick where no other event is raised (to use that unused CPU time and make background calculations)

An even scheduler working across all mods? Now I want that.
I have plenty of non time critical functions that could benefit from telling the game to just give an event roughly every 60 to 300 ticks.

But for now, time to redesign some functions to use event filters.

[T-A-R]

Just received new shirts, they are awsome!