Somethings not (or hidden) in doc but you need to know

[eradicator]

@darkfrei:
Functions must _always_ be defined before they can be called, that applies to control.lua too. The wrapper function you're registering to on_tick is not calling "foo" and "bar" until the first tick happens though, and by that time all functions in the script have already been parsed.

[Optera]

And when I need two handlers?

Code: Select all

function first_tick_handler(event)
-- first part
end

function my_tick_handler(event)
-- second part
end

script.on_event(defines.events.on_tick, function(event) 
first_tick_handler(event) 
second_tick_handler(event) 
end)

That is 1 handler calling 2 sub functions.

While you can bind multiple events to 1 function

Code: Select all

script.on_event({defines.events.on_preplayer_mined_item, defines.events.on_robot_pre_mined, defines.events.on_entity_died}, OnEntityRemoved)

you can't bind one event to multiple functions

Code: Select all

local function Do_A(event)
  log("A")
end

local function Do_B(event)
  log("B")
end

script.on_event(defines.events.on_tick, Do_A(event))
script.on_event(defines.events.on_tick, Do_B(event))

This will only ever print B.

[darkfrei]

Code: Select all

icons =
{
    {
        icon = "__foo__/graphics/my-icon-1.png",
        tint = {r = 0.8, g = 0.8, b = 1}
    },
    {
        icon = "__foo__/grahpics/my-icon-2.png",
        tint = {r = 1, g = 0.5, b = 0.5}
    }
}

Can we use here spritesheet? Some big picture and
shift = {x = x1 * 32, y = y1 * 32}
icon_size = {x = 32, y = 32}
or
icon_width = 32
icon_height = 32

[Mooncat]

Code: Select all

icons =
{
    {
        icon = "__foo__/graphics/my-icon-1.png",
        tint = {r = 0.8, g = 0.8, b = 1}
    },
    {
        icon = "__foo__/grahpics/my-icon-2.png",
        tint = {r = 1, g = 0.5, b = 0.5}
    }
}

Can we use here spritesheet? Some big picture and
shift = {x = x1 * 32, y = y1 * 32}
icon_size = {x = 32, y = 32}
or
icon_width = 32
icon_height = 32

I haven't tested yet, but I guess width and height won't work, because there is "icon_size" specifically for this purpose (see SOLUTION TO INCORRECT ICON SIZE).

[eradicator]

Can we use here spritesheet? Some big picture and

Icons have to be on-per-file. There's no support for icon-sheets.

[bobingabout]

Please add prefix to your prototype names. To be honest, this should be in the modding tutorial.
For each prototype in each type (entity, item, recipe, etc.), its name has to be unique. You have to make sure it won't collide with any prototype of the same type provided by other mods.
When more mods are involved, being unique is more difficult. So, the easiest way is to add prefix, which is your mod ID.
For example, the ID of my Creative Mode is creative-mode, so you can see that every prototypes in the mod is named after "creative-mode_".

Of course it is not a must. You can ignore this if you are making something that will be commonly used / shared by other mods, like common ores, matels, etc, such that the prefix will be an obstacle. But make sure you communicate with other modders because you may not be the only one who has this idea.

Entities, and their related items/recipes, sure, yes, make those unique with a prefix, Most recipes might also benefit from this too.

but when you look at intermediates...
"Why can't I use bob's tin to make 5dim stuff, and vica verca?"
Tin plate, vs 5dim's tin plate... It's confusing and annoying, it would be better to have a single tin plate that can be used for everything.

So, Resources and Intermediates: Follow base game naming scheme. Everything else: Prefix with your mod name. (I notice you did make a brief point about this)

It also brings me to the gas/fluid prefix system people use... Examples of fluids in the base game: "water", "crude-oil", there is no prefixing, and they're a resource/intermediate... Gasses? Maybe only "petroleum-gas" could be said to be suffixed with "gas", but "steam" is a gas, and isn't.

If we were agreeing on a standard to differentiate a fluid from a gas, I would suggest that all gasses are suffixed with "-gas" (like petroleum gas, which makes steam an odd one out), but fluids aren't prefixed or suffixed with anything. Personally I don't prefix or suffix any fluid types at all, but I also know that pisses people off. The main reason why I still don't, is because it would probably break quite a few things... not only would I need to migrate fluids (Which wasn't even a thing before 0.13, I think) but other mods who check for my names to add the prefix would break, because they wouldn't detect my new name.

I am also aware that due to LUA peculiarities, reading a prefix is far easier than reading a suffix, so I understand why people would suggest prefixing rather than suffixing.


I try to follow this list of rules with any new items I create (pretty much everything that isn't an intermediate is bob- prefixed), but a lot of older things in my mod still don't have this prefix. I kind of have this "if it ain't broke don't fix it" mentality.

[Nexela]

It also brings me to the gas/fluid prefix system people use... Examples of fluids in the base game: "water", "crude-oil", there is no prefixing, and they're a resource/intermediate... Gasses? Maybe only "petroleum-gas" could be said to be suffixed with "gas", but "steam" is a gas, and isn't.

This is even easier in .15 just add a gas_temperature value to your fluid prototype

[bobingabout]

It also brings me to the gas/fluid prefix system people use... Examples of fluids in the base game: "water", "crude-oil", there is no prefixing, and they're a resource/intermediate... Gasses? Maybe only "petroleum-gas" could be said to be suffixed with "gas", but "steam" is a gas, and isn't.

This is even easier in .15 just add a gas_temperature value to your fluid prototype

I was going to do that, but didn't like the change to the way it looked.
(Most of my fluids have been made with the standard primary/secondary colour system, where the secondary is often quite random. The system to display gasses in the game shows the primary as the bar colour, and secondary as the fluid colour in pipes. as a default all my base gasses (Oxygen, Nitrogen, Hydrogen and Chlorine) were a light grey, and others were strange colours. I disabled this change for now, but I'd need to go through and update these colours for every gas in my mod.)

[eradicator]

but when you look at intermediates...
"Why can't I use bob's tin to make 5dim stuff, and vica verca?"
Tin plate, vs 5dim's tin plate... It's confusing and annoying, it would be better to have a single tin plate that can be used for everything.

So, Resources and Intermediates: Follow base game naming scheme. Everything else: Prefix with your mod name. (I notice you did make a brief point about this)

This feels very much like a think that is specific to your situation, because you have the biggeste player base you can afford to (and maybe even have a right to - see below) define the price/balance of all intermediates you name. (Not trying to be rude, that's just how i feel about that thought.)

On a technical/implementation level having several mods use the same name for an item without communication between the mod authors raises quite a number of questions for me:

1) Price: What if differnt mods using the same-name-intermediate (short: SNI) have different concepts of how to produce that SNI. Mod1 might produce tin by simply placing tin-ore into the world and having it smelt to plates, while Mod2 might require the player to produce it as a byproduct from some other ore. If both methods exist next to each other the price-balance of Mod2 will be completely disrupted.

2) Loading order: If none of the mods check if the SNI already exists then the last mod in the loading order will - most of the time - overwrite any changes made by any previous mods. And even if checking is done, what is the later-loaded mod supposed to do? There's no guarantee that just because there's something with the same name it also has the same properties (especially for fluids which have many different properties).

3) Graphics: Even if there's checking done, and let's even assume the items are similar enough to be reasonably exchangable - then who gets to decide which graphic is used?

Also your argument (that i don't agree with) - that the player might complain about not being able to craft mod1 products with mod2 SNI's - can be easily expanded on common machine names. What if several mods add a "crusher". You said machines should be prefixed (i agree) but this effectively means that that the player is "confused" again because suddenly there's two machines with the same concept (and possibly localized name) but different recipe-categories.

I think these kind of naming conflicts need to be very very carefully considered on a case-by-case basis. Especially new modders should be encouraged prefix everything until they've seen enough other-ppls-code to decide for themselfs if they want to share an SNI with another mod.

In Minecraft this problem was solved by the ore-dict and consensus of large parts of the community about approximately how rare/expensive a certain ore should be (and of course by large modpacks enforcing the same rarity over all mods they contain). But we don't have an ore-dict or the "benefit" of having mod-pack-makers decide on a "good" rarity for each ore. And i have no clue if there's a consensus.

[bobingabout]

but when you look at intermediates...
"Why can't I use bob's tin to make 5dim stuff, and vica verca?"
Tin plate, vs 5dim's tin plate... It's confusing and annoying, it would be better to have a single tin plate that can be used for everything.

So, Resources and Intermediates: Follow base game naming scheme. Everything else: Prefix with your mod name. (I notice you did make a brief point about this)

This feels very much like a think that is specific to your situation, because you have the biggeste player base you can afford to define the price/balance of all intermediates you name. (Not trying to be rude, that's just how i feel about that thought.)

I gave a specific example of what I have encountered, this is true. But at the end of the day, tin is tin is tin, and most people believe that 5dim's intentional prefixing his tin plate was silly. (he had my mod to know what I named it, and chose to name it something else), I've even had requests to make my tin compatible with his, I mean, that just makes me go "WTF?" because not only was I first, but I use a standard name and he uses a prefixed name.

On a technical/implementation level having several mods use the same name for an item without communication between the mod authors raises quite a number of questions for me:

1) Price: What if differnt mods using the same-name-intermediate (short: SNI) have different concepts of how to produce that SNI. Mod1 might produce tin by simply placing tin-ore into the world and having it smelt to plates, while Mod2 might require the player to produce it as a byproduct from some other ore. If both methods exist next to each other the price-balance of Mod2 will be completely disrupted.

I can understand that... simply putting tin ore in a furnace to smelt it (Which is actually how you make tin in my mods, lol. can't say that for all ores though, but it is realistic for tin!) does render a more complex method pointless. It's why some of my more complex systems give you more plates per ore than the standard smelt it recipes.

2) Loading order: If none of the mods check if the SNI already exists then the last mod in the loading order will - most of the time - overwrite any changes made by any previous mods. And even if checking is done, what is the later-loaded mod supposed to do? There's no guarantee that just because there's something with the same name it also has the same properties (especially for fluids which have many different properties).

It's one reason why I said you should prefix the recipe to make an item, but not the item itself.

3) Graphics: Even if there's checking done, and let's even assume the items are similar enough to be reasonably exchangable - then who gets to decide which graphic is used?

the one that loads last >.>

Also your argument (that i don't agree with) - that the player might complain about not being able to craft mod1 products with mod2 SNI's - can be easily expanded on common machine names. What if several mods add a "crusher". You said machines should be prefixed (i agree) but this effectively means that that the player is "confused" again because suddenly there's two machines with the same concept (and possibly localized name) but different recipe-categories.

I think these kind of naming conflicts need to be very very carefully considered on a case-by-case basis. Especially new modders should be encouraged prefix everything until they've seen enough other-ppls-code to decide for themselfs if they want to share an SNI with another mod.

In Minecraft this problem was solved by the ore-dict and consensus of large parts of the community about approximately how rare/expensive a certain ore should be (and of course by large modpacks enforcing the same rarity over all mods they contain). But we don't have an ore-dict or the "benefit" of having mod-pack-makers decide on a "good" rarity for each ore. And i have no clue if there's a consensus.

Many people do mention about how I've got the rarity of some of my ores wrong... my only real answer to that is "I used the base game resources as a base, and then made each of my ores are rare as one of these". it is a bit more complex than that, but going by the numbers on existing ores does offer more reliability than just plain guessing and seeing what works.

And you're right, case by case basis is probably best... but off the cuff... my general rule would be: Make a resource or intermediate's item/fluid name generic and follow base game specifications. EG tin-ore, tin-plate. In this instance, if it is a furnace recipe, go by convention, name it tin-plate. if it's any other method, prefix it with your mod prefix. so EG, I would have tin-plate as my tin smelting recipe, but bob-gold-plate for my gold smelting recipe as it uses a process "unique" to my mod. Most recipes should use a prefix regardless of it being a common item, unless of course you are purposely trying to overwrite someone elses recipe (Angel does it for a lot of mine)

Technology is another one, A lot of my technologies (Especially the newer ones, most of the older ones aren't even if they are unique to my mods) are prefixed, others where I'm trying to re-define how the structure works are purposely not prefixed (so that only one exists, mine or someone elses, doesn't matter as long as there's only one. Stat boosting technologies, like toolbelt-2 as an example)



But yes, end of the story is, until someone defines exactly what should or should not be prefixed, there is a lot of leeway in it, and these are my personal opinions on what should and shouldn't be.

[Mooncat]

I think Bob has made a good point. I hate those Lead, Tin and Copper oressssss in Minecraft generated by different mods and they are not always interchangeable. I will update the OP to state that intermediate items can be an exception for intermediate-advanced modders (because you'll need to check if the item already exists before data:extend it).

[Mooncat]

New:

• Data and Control
  • LuaEntityPrototype.collision_mask does not return not-colliding-with-itself

• Control
  • GUI Naming

Updated:

• Data
  • Prototype Naming
    • Better explanation for naming common intermediate items and resources

• Control
  • Find entity using position will not return entities without collider
    • Position-search can actually find the space rocket.
    • Added a note for the space rocket.

[eradicator]

But yes, end of the story is, until someone defines exactly what should or should not be prefixed, there is a lot of leeway in it, and these are my personal opinions on what should and shouldn't be.

"Is made via a common/base-game process" seems like a good indicator for when to use prefix-less item/recipe names that i can agree with =). Also i haven't played either yours or dims mods recently so i have no insight on that particular case, but i would imagine that he got similar complains about "making things compatible". In the end he might have had a good reason - or a bad one :P.

@Mooncat:
Concerning GUI Naming i consider it good practice to always check for the root name. This way i only have to keep the upper-most elements name unique and can keep the other buttons with more convenient namings. Don't know how other people handle this.

Code: Select all

local function is_my_gui(element)
  if     element.name   == 'name-of-root-frame-of-my-mod-gui' then
    return true
  elseif element.parent == nil then --this is the root gui element (i.e. gui.left/gui.center/gui.top)
    return false
  else
    return is_my_gui(element.parent) end --recurse upwards
  end

[Mooncat]

@Mooncat:
Concerning GUI Naming i consider it good practice to always check for the root name. This way i only have to keep the upper-most elements name unique and can keep the other buttons with more convenient namings. Don't know how other people handle this.

Code: Select all

local function is_my_gui(element)
  if     element.name   == 'name-of-root-frame-of-my-mod-gui' then
    return true
  elseif element.parent == nil then --this is the root gui element (i.e. gui.left/gui.center/gui.top)
    return false
  else
    return is_my_gui(element.parent) end --recurse upwards
  end

If you have unique name for each GUI element, then you don't need to check their parents, considering there is performance cost whenever you access element.parent (not ultra important but we love premature optimization don't we). You will need to distinguish your elements after all, why not do this in the first place.

[eradicator]

@Mooncat:
Concerning GUI Naming i consider it good practice to always check for the root name. This way i only have to keep the upper-most elements name unique and can keep the other buttons with more convenient namings. Don't know how other people handle this.

Code: Select all

local function is_my_gui(element)
  if     element.name   == 'name-of-root-frame-of-my-mod-gui' then
    return true
  elseif element.parent == nil then --this is the root gui element (i.e. gui.left/gui.center/gui.top)
    return false
  else
    return is_my_gui(element.parent) end --recurse upwards
  end

If you have unique name for each GUI element, then you don't need to check their parents, considering there is performance cost whenever you access element.parent (not ultra important but we love premature optimization don't we). You will need to distinguish your elements after all, why not do this in the first place.

A) Because by checking for the root i only have to check a very small list of names to see if i can skip the whole event (for most mods this would be a single name). And you always want to skip the event as fast as possible if it's not for your mod gui. Additionally i save lots of time by not having to call expensive string methods to try and extract prefixes for name checking. It also saves on string creation cost because i don't have to add a suffix for every element name. (And string creation/storage cost in this case would already outweight the cost of checking the parents name in any but the most simplistic guis).

B) For any semi-complex gui (that is to say anything with more than let's say 10 buttons) code readability and maintainability is greatly improved by not having to care about prefixing every button.

C) A prefix never ensures that that your button name is unique. The parent name on the other hand is guaranteed to be unique. And we love guaranteed correctness too don't we?

D) on_gui_click events are - compared to anything else - extremely rare unless you have some button that needs to be spammed. And even then you would at most see one every 5 ticks or so. So the cost of name checking the parent is completely negligible.

To clarify: the GUIs i make usually have a fair amount of complexity and clickable elements (easily above 50 clickable elements for a research queue gui), but i still think that checking the parent name is the easiest way for everything with more than one button

[Optera]

B) For any semi-complex gui (that is to say anything with more than let's say 10 buttons) code readability and maintainability is greatly improved by not having to care about prefixing every button.

How is readability reduced by prefixing objects/variables? Naming conventions in projects are made to increase maintainability.
A button ResourceMonitor_ResourceList_ScrollUp is so self explanatory just the name will tell you exactly what mod it belongs to and what function it provides.

You could argue it's a very long name to type, but serious development takes place in an environment providing intelli sense. Even NPP has rudimentary intelli sense.

[eradicator]

B) For any semi-complex gui (that is to say anything with more than let's say 10 buttons) code readability and maintainability is greatly improved by not having to care about prefixing every button.

How is readability reduced by prefixing objects/variables? Naming conventions in projects are made to increase maintainability.
A button ResourceMonitor_ResourceList_ScrollUp is so self explanatory just the name will tell you exactly what mod it belongs to and what function it provides.

You could argue it's a very long name to type, but serious development takes place in an environment providing intelli sense. Even NPP has rudimentary intelli sense.

For buttons with fixed names this might be true (tho even then just "ResourceList_ScrollUp" + parent name checking isn't that different.). But i mainly meant that comment for dynamic buttons that need to be un-/prefixed by substring functions ("ResourceList" sounds like it would need some of those), so it would be more like this:

Code: Select all

if string.sub(name,1,#MODNAME) == MODNAME then --detect if my mods button
--or
name = MODNAME .. SUBMENU .. "ScrollUp" --assigning button name

Also I'm not too confident about your assumption that most begginning/intermediate modders (that's who this thread is for right?) have an IDE that does those things for them - tho that might be because i'm not using one myself . Feel free to point me to any example code.

[bobingabout]

GUI elements is one area I'd prefix the name.

if everything in my mod starts with "bob" for example, then at the start of my button checking routine, I check to see if the button starts with "bob", and if it doesn't, end button checking, if it does, THEN you check the parent, or check the button name itself (depending on how complex the GUI is)

[y.petremann]

About gui names, eradicator method is quite good for the mod itself, but it doesn't prevent other mods not protected by this method to fall in this trap ...

An example is that I have two mods ModA (mine) and ModB (by any dev) defining each an interface with a cancel Button
So with eradicator methods I would have :

gui -> left -> moda -> ... -> cancel
gui -> left -> modb -> ... -> cancel

here I can protect moda against by clicking on modb cancel button, but I can't protect modb to be triggered wjen clicking on moda cancel button

with prefix :

gui -> left -> moda -> ... -> moda_cancel
gui -> left -> modb -> ... -> modb_cancel

My mod is protected against modb_cancel click because it don't exist in my mod base, and modb_cancel is protected again against moda_cancel because it don't exist ...

Also it permit to have a particular mod made to interact with your gui.

Okay making prefix is not really maintainable because you need to prefix every element you want to check, what can be done is making wrapper of gui creation and manipulation to handle your prefix, so when creating, you put your simple name, when handling the event, you use your is_my_gui(element) that can do the check you want (prefix or/and parent name).

[mrudat]

I haven't needed to do GUI stuff yet, but doesn't stdlib have GUI support code? I would expect that it does something along these lines, so you don't have to roll your own.