You can probably work around this at least by editing the generic placeholders in the path fields of config.ini to have correct paths in them for your system. EDIT: The default __PATH__system-read-data__ placeholder expands to __PATH__executable__/../../data (except on macs, afaik) and __PATH__syste...

darkfrei wrote: ↑

Fri Feb 14, 2020 3:05 pm

Honktown wrote: ↑

Fri Feb 14, 2020 3:01 pm

Not to be a bother, but what are you logging!?!

Some mods + viewtopic.php?t=45107

so... exactly what you're not supposed to do with it? dumping large amounts of data?

print is already vararg, it prints all the args.

That it also cleaned up console errors was a convenient side effect - I actually wanted it because I display functions as <chunkname:linedefined> in debug views and in call stacks (in my vscode debugger) if they don't have a better name. There's a couple other small tweaks for debugging, like a bigg...

I changed this in a PR because it makes for nicer appearance of console defined (and serpent defined) functions in debugging tools with named chunks rather than the full source text. It was in 0.18.0.

Ah! ConMan doesn't set by_player because it doesn't know who (if anyone) caused the signals that triggered it, but I got a report from a user wanting events, presumably so that an instant-blueprinter can revive them. It seemed wrong to me to call the api and then just turn around and raise_event eve...

LuaItemStack.build_blueprint should have a flag raise_built to cause script_raised_built to be fired for each ghost

How would you ensure that your mod is compatible to both versions at the same time if prototypes changes in experimental. You think your idea works because some simple mods need only to change the value in the info.json but that's just coincidence. It would be fairly straightforward in data stage t...

/c local ls = {""} ls[2]=ls game.print(ls) I would expect to get an error due to this being deeper than the 20 levels max depth, but instead the game crashes with a stacktrace that just repeats parseLocalisedString forever: ERROR: Factorio crashed due to Stack overflow. 42.119 Time travel...

Cool, I didn't know that. The more you know. :) I'm assuming the first one is more performant. I wonder I I can trick to the compiler into generating these SELF instructions, because I'm fairly sure that my approach is going the GETTABLE/MOVE route. Anyway, from a code standpoint, it doesn't really...

Lua doesn't have a real concept of self. The only thing close to it is using ":" syntax to call a "method" instead of ".". Well, it kinda does. The ':' call syntax compiles to a different lua vm opcode, SELF which does the lookup operation and prepares the resulting fu...

Thanks for report. I deleted the function since it's no longer valid anyway. You can check if a mod exists by checking "if mods[name]" before doing the require. If you don't know if the file exists even if the mod exists I question why anyone would want to write that code. The `mods` tabl...

It looks like this was intended in the past to solve the problem of "require these files if they are available", but fell out of use in favor of the is_demo flag, and then was unnoticed when `package` was stripped. It now throws a scripterror when it attempts to use `package.searchers or p...

It might be useful for comparing server vs client UPS issues to be able to print the timings (similar to the in-game Update tree) to a headless server's console with a command

Sounds like we've got a few volunteers to write all the checks

Edit2: If your planned feature of adding an entity to a blueprint should rely on the same functions as the construction order, it would be in your interest to read the control behaviour type of an entity prototype, just like this topic initially suggested. I eventually arrived at this conclusion as...

eradicator wrote: ↑

Tue Nov 12, 2019 7:12 pm

100% of mods that have more than one event handler for the event can't meaningfully use it (this includes anything using stdlib).

Sounds like someone shoehorning multiple mods into a single package, rather than actually separating them properly!

In version 0.17.2, if you place an entity over an existing entity of the same name, it just places a ghost entity at that position and does not overwrite the existing entity. Working as designed. Decon the original one first. snip This is my modified control of version 0.17.2. The core idea is repl...

For one thing, you may want to use ConMan from github master, or wait another day or so for me to release that version, which handles all entities control behaviors correctly already. But also, what did you find not working, and why did you not report it on github, where i'll actually see it to fix ...

Btw, here's another usecase for manually raising on_build: If i use create_entity{raise_build=true} then another mod could destroy the created entity before i even ever see it. Therefor function() create_entity{raise_build=false} --dostuff script.raise_event(defines.events.on_built,...) end means i...