Hope that the built-in commands of MOD are standard functions

Built-in commands: "out", "delay" ..., they are all variables
It is difficult to debug these codes in IDE.
I hope that the built-in commands will be changed to functions so that MOD can use standard Lua syntax.
such as:
red(wood)
out(signal-C,1)

I am a beginner in Lua and don't know English.
Hope it helps me.

I hope that the built-in commands will be changed to functions so that MOD can use standard Lua syntax.
such as:
red(wood)
out(signal-C,1)

Tables are also perfectly standard Lua, and make much more sense wrt how these signals work, so I don't really see what's the problem with these.
I.e. they are data, and are manipulated as data here. Can be iterated over, replaced, etc.

This definitely won't change, and I kinda feel like this is some weird miscommunication, given how strange this idea is.

Also maybe I just don't understand specific use-case where functions are better than tables, which can probably be fixed by providing a concrete example.

It should be easy to add some kind of extra accessor (getter/setter) functions here, but given how non-obvious their value to me, doubt it's worth bothering with in the mod lua env instead of your own code, unless I'm wildly out of sync with how people write their code these days.
Just paste such accessors along with that specific code where they make more sense to use than tables, I guess.

Thank you for your reply.

My idea is to facilitate debugging in the IDE

For example, these two pieces of code,
There is no difference in factorio.
The difference is very big in the IDE

'''
out[signal-C] = 0
delay = 120
out[signal-C] = 1
'''

'''
out('C', 0)
delay(120)
out('C',1)
'''

You can get the same feedback as in the game by adding a function written by yourself in the IDE
'''
local function delay(s)
local ntime = os.clock() + s / 60
repeat
until os.clock()> ntime
end

local function out(k, v)
print('signal-' .. k .. '' .. v)
end

out('C', 0)
delay(120)
out('C',1)

'''

Duplicate content
To delete

This example:

out['signal-C'] = 0
delay = 120
out['signal-C'] = 1

Is not how Lua code on combinators work.
I.e. if you expect signal-C to be unset for 120 ticks and set afterwards there, it won't work like that - only "out" values after code exits matter.

In this case, combinator will run the code, and end up with delay=120 and out['signal-C']=1.
Based on that, it will delay next run by 120 ticks, and set signal-C = 1 on the circuit network.

It can be simplified to out['signal-C'], delay = 1, 120 - this will do exactly same thing.

So don't think you get anything useful from printing values you set before code exits, and to debug what such snippet does, you can just do this:

out['signal-C'] = 0
delay = 120
out['signal-C'] = 1

print('delay='..delay)
for k,v in pairs(out) do print(('out[%s] = %s'):format(k,v)) end

And that's it, no need to define anything special, just print inputs/env before code runs and outputs/env after.
(that's also what setting debug=true on the combinator does btw, printing this kind of before/after dump to factorio log)

out('C', 0)
delay(120)
out('C',1)

I think it would've been possible to make Lua 5.2 work like this, if lua in factorio supported coroutines, actually.
I.e. you can have delay/out stuff call coroutine.yield and suspend execution until specified (or just next) tick that way.

But factorio does not support coroutines afaik, so you either just run the code until it halts (what this mod does), or do something clever to split it into subroutines, implementing your own language on top of lua - like scanning for "-- delay for 120 ticks here --" lines and running that code in parts, split by those.

Latter approach can be kinda-implemented, and without breaking changes to the mod too, but has a bunch of issues of its own - like syntax errors on split code blocks, or locals not working throughout - so idk if it's worth the effort.
It won't work with any kind of "custom infinite loop" scenarios anyway, which is probably what one might want it for, and where coroutines tend to be useful.

thank you for your help
o(^＠^)o

thank you for your help

I understand

😀

I probably pre-answered that in a message just above - i.e. not really.
And nothing you do before mod lua on_tick code stops executing matters, so there's no point setting different values for same signals within it in any way, as only the last one will be used by the game.

Thank you

I saw your reply after I posted the last reply,
I found that my question was low-level, and I said that I revised the reply

(✿◡‿◡)

Thank you

I saw your reply after I posted the last reply,
I found that my question was low-level, and I said that I revised the reply

(✿◡‿◡)