[MOD 0.17] Industrial Revolution

[Solinya]

I was playing multiplayer over the weekend and it's been a fun challenge trying to figure out all the intermediate component puzzles.

One bug we noticed is that if the non-host dies, they respawn with a vanilla pistol and firearm ammo. The vanilla pistol can't be deconstructed like IR pistols, but can be combusted. I believe when the host died, they did not respawn with the vanilla gear, but I can't confirm.

I'm using alien biomes which may mess with rubber tree distribution, but I find them pretty difficult to find - which I don't mind at all. It requires a fair bit of exploration, again something you don't get much of in vanilla. In combination with autoforesters, looking for 10 rubber tree saplings to secure yourself a steady supply of rubber wood makes for a fun, organic exploration quest. I'd be down for more exploration opportunities of this kind.

We thought alien biomes was unsupported so we were playing without it and the rubber distribution is pretty sparse. But I also didn't mind as I got to take a long journey with the monowheel, exploring a bunch of chunks on a quest for saplings. It's a way to get you out of your base (at least until you get artificial production going) which I wish the game had more of.

[Deadlock989]

One bug we noticed is that if the non-host dies, they respawn with a vanilla pistol and firearm ammo. The vanilla pistol can't be deconstructed like IR pistols, but can be combusted. I believe when the host died, they did not respawn with the vanilla gear, but I can't confirm.

I had one other report of this. There's clearly something I haven't quite understood about how the freeplay scenario sets up starter and respawn items. It's working fine for single player and interesting to hear that it's only working for the host in a multiplayer game. I'll do some more digging.

[pnunes515]

Just wanted to post to say I've been having a blast with this mod. I'm playing with Krastorio and have only just got to my first steam engine - loving it so far, great job.

[Klonan]

I had one other report of this. There's clearly something I haven't quite understood about how the freeplay scenario sets up starter and respawn items. It's working fine for single player and interesting to hear that it's only working for the host in a multiplayer game. I'll do some more digging.

It should work doing something like this:

Code: Select all

local respawn_items = function()
  return
  {
    ["pistol"] = 1,
    ["firearm-magazine"] = 50,
    ["light-armor"] = 1,
    ["my-item"] = 10,
    ["big-bobs"] = 2,
  }
end

remote.call("freeplay", "set_respawn_items", respawn_items())

[Deadlock989]

It should work doing something like this:

That's what I thought. This is what I'm doing, in on_init():

Code: Select all

local function initialise()
	if global.player_tips == nil then global.player_tips = {} end
	game.forces["player"].research_queue_enabled = true
   	register_commands()
	if remote.interfaces["freeplay"] then
		remote.call("freeplay", "set_skip_intro", true)
		remote.call("freeplay", "set_respawn_items", nil)
		if not kit then
			remote.call("freeplay", "set_created_items", kits.no_kit)
		else
			remote.call("freeplay", "set_created_items", kits[age])
		end
	end
end

The reason the conditional check to see if the interface exist exists is because there was one time, in one patch, when it was semi-randomly failing to find the interface. Bit baffling if I'm honest. I can mess around in Blender and I know data.raw like the back of my hand, but control scripting is difficult. "kit" is a local variable in the control script which is effectively a constant, it is never modified.

[Klonan]

The reason the conditional check to see if the interface exist exists is because there was one time, in one patch, when it was semi-randomly failing to find the interface.

You should always do the conditional check, because the mod might be loaded in another scenario or save, which doesn't use the freeplay (such as sandbox, PvP, etc).

Bit baffling if I'm honest. I can mess around in Blender and I know data.raw like the back of my hand, but control scripting is difficult. "kit" is a local variable in the control script which is effectively a constant, it is never modified.

Ah, I see the problem
You are setting the respawn items to nil,
The freeplay script checks if they are nil and if so, sets them back to the defaul

You should set them to just an empty array:

Code: Select all

remote.call("freeplay", "set_respawn_items", {})

[Deadlock989]

Ah, I see the problem
You are setting the respawn items to nil,
The freeplay script checks if they are nil and if so, sets them back to the defaul

You should set them to just an empty array:

Code: Select all

remote.call("freeplay", "set_respawn_items", {})

Nice one. Thanks for the help.

[Omnifarious]

There's nothing in the EULA to prevent it as far as I know. I did experiment with Patreon but their model implies an ongoing commitment to work on something and it didn't really feel appropriate. If I could find a way to take one-off donations without broadcasting my real-world identity I'd be all over it. I don't want to make an income off modding, I already have a job.

A Bitcoin address?

[Deadlock989]

A Bitcoin address?

Bit nebulous - I was thinking of something more substantial, like the actual tears of the actual Tooth Fairy.

But no, there won't be any way of sending me money. Don't need it, don't want it.

[disentius]

Flowers?

[Drury]

I could spare some diamonds. Got dozens of the things lying around.

[Deadlock989]

Make it a lifesize monowheel and a flying helmet and we're quits, I'll supply my own cigar and goggles.

[suprnova74]

Been toying with this since yesterday and makes Bob's full materials mod tiny in comparison I absolutely love the changes and the graphics are fantastic!
It was quite a "culture shock" when I went to hand-craft my first drill to see all those intermediary components. It'll make the automation that much more challenging!


I only got to Bronze so far and the only "glitch" I have found is furnaces will not pull more ore to smelt automatically once they have 48 bars cached. I can manually input 1000 ore and it'll process through. It feels like it's similar to how vanilla assemblers will not take more materials once they have 2 or 3 items built typically. Anyway, I wasn't sure if that's intended or not. It's not a huge deal as I'll be implementing belts/storage boxes shortly, but just noticed it as a quirk that's different from vanilla furnace behavior.

The only mods I have enabled are:
Bigger Stack Sizes Modded v2
Crafting speed research
EvoGUI
Fill4Me
Research Queue The Old New Thing
YARM

[fishycat]

Just here to share some love for this masterpiece of mod. Beside all the fantastic artwork and animations, the small thing that let me fall in love with this mod instantly, is the map-marker-place sound
I'm excited to see what else I will discover! Thank you very much for all the long hours you put in this project!

[Deadlock989]

I only got to Bronze so far and the only "glitch" I have found is furnaces will not pull more ore to smelt automatically once they have 48 bars cached. I can manually input 1000 ore and it'll process through. It feels like it's similar to how vanilla assemblers will not take more materials once they have 2 or 3 items built typically. Anyway, I wasn't sure if that's intended or not. It's not a huge deal as I'll be implementing belts/storage boxes shortly, but just noticed it as a quirk that's different from vanilla furnace behavior.

1000 ore???

It took me a while to work out what you meant and then I was like, duh, the output buffer of furnaces. Can't believe I didn't notice this and it didn't come up in playtesting either. Vanilla furnaces will stack up to 100 (or the item stack size), but IR furnaces don't, because (shhh, don't tell) they're not technically furnaces ... It's no wonder they behave like assemblers because on the code/prototype level they literally are. I have made a note to see whether properties can be adjusted to compensate for it. From memory of how that works, not sure I can replicate vanilla behaviour, but may be able to get it closer.

[Deadlock989]

Just wanted to say I am pretty blown away by the things I am reading from people playing the mod and all the positivity and support that is coming from them. Had no idea it would be this well received. I absolutely love seeing screenshots of people's setups and bases (favourite game for screenshots is spot-the-monowheel) so please keep them coming if you can.

I am stepping Away From The Keyboard during the week to catch up on some tedious RL stuff and also play my own damn mod a bit. So there won't be an update for a few days at least, maybe not before the weekend unless people find something really gamebreaking.

As I hinted for the pre-1.0.0 versions, based on what I'm hearing and reading and experiencing for myself, I am expecting there will be some balance changes coming soon, but at this point I don't think they will be especially major and they are all centred on pretty late game, i.e. around the boundary of Chrome Age and beyond.

There is also a German locale translation sitting on my hard disk, courtesy of tiriscef, many many thanks to them for putting that work in, hugely appreciated.

[kingarthur]

I only got to Bronze so far and the only "glitch" I have found is furnaces will not pull more ore to smelt automatically once they have 48 bars cached. I can manually input 1000 ore and it'll process through. It feels like it's similar to how vanilla assemblers will not take more materials once they have 2 or 3 items built typically. Anyway, I wasn't sure if that's intended or not. It's not a huge deal as I'll be implementing belts/storage boxes shortly, but just noticed it as a quirk that's different from vanilla furnace behavior.

1000 ore???

It took me a while to work out what you meant and then I was like, duh, the output buffer of furnaces. Can't believe I didn't notice this and it didn't come up in playtesting either. Vanilla furnaces will stack up to 100 (or the item stack size), but IR furnaces don't, because (shhh, don't tell) they're not technically furnaces ... It's no wonder they behave like assemblers because on the code/prototype level they literally are. I have made a note to see whether properties can be adjusted to compensate for it. From memory of how that works, not sure I can replicate vanilla behaviour, but may be able to get it closer.

recipes have a overload multiplyer variable that is supposed to change how much inserters try to fill the machine. i assume if the inserters cram more in before they reach a full state it should stack the output higher. https://lua-api.factorio.com/latest/Lua ... multiplier

[suprnova74]

1000 ore???

Hah, yeah, Bigger stack sizes mod. It helps me not run around like a headless chicken in the initial game keeping everything loaded and/or unloaded. I had my statement worded better and then did a select/paste faux pas and lost the initial draft so glad you were able to decipher it.

Can't believe I didn't notice this and it didn't come up in playtesting either. Vanilla furnaces will stack up to 100 (or the item stack size), but IR furnaces don't, because (shhh, don't tell) they're not technically furnaces ... It's no wonder they behave like assemblers because on the code/prototype level they literally are. I have made a note to see whether properties can be adjusted to compensate for it. From memory of how that works, not sure I can replicate vanilla behaviour, but may be able to get it closer.

Hmm, makes sense now that I'm thinking through it. 48 /12 = 3 "batches" which is the same output buffer a traditional assembler allows.

recipes have a overload multiplyer variable that is supposed to change how much inserters try to fill the machine. i assume if the inserters cram more in before they reach a full state it should stack the output higher. https://lua-api.factorio.com/latest/Lua ... multiplier

I never understood the assembler limitation or the lack of ability to change that in-game anyway. If it has the internal storage to hold more output, it should take more input automatically IMO.

[Deadlock989]

I never understood the assembler limitation or the lack of ability to change that in-game anyway. If it has the internal storage to hold more output, it should take more input automatically IMO.

Actually, it can be really damn annoying with actual (modded) assemblers, especially ones making expensive stuff. You don't necessarily want them to eat and eat and eat until they're full. Not often a problem but it can be, so I can understand why the default is set pretty low. Agreed, it depends what you're doing. I would guess better sometimes too little than always too much.

The reverse problem also holds with input buffers and loaders - having built a very loader-focused mod or two, I would get reports saying WHY UR LOADER FILL SO MUCH WHY WHY and it turned out that because loaders don't have inserter behaviour, they'll fill a machine slot to maximum stack size no matter what, and if some mod makes an item with stack size 10,000 it'll just merrily carry on filling up that assembler 1 with it forever, when an inserter wouldn't. You might want that behaviour. Most people didn't. Nothing can be done about the loader thing, but as king_arthur pointed out there are some options for recipes that can be tweaked for the output buffer issue.

[suprnova74]

I never understood the assembler limitation or the lack of ability to change that in-game anyway. If it has the internal storage to hold more output, it should take more input automatically IMO.

Actually, it can be really damn annoying with actual (modded) assemblers, especially ones making expensive stuff. You don't necessarily want them to eat and eat and eat until they're full. Not often a problem but it can be, so I can understand why the default is set pretty low. Agreed, it depends what you're doing. I would guess better sometimes too little than always too much.

The reverse problem also holds with input buffers and loaders - having built a very loader-focused mod or two, I would get reports saying WHY UR LOADER FILL SO MUCH WHY WHY and it turned out that because loaders don't have inserter behaviour, they'll fill a machine slot to maximum stack size no matter what, and if some mod makes an item with stack size 10,000 it'll just merrily carry on filling up that assembler 1 with it forever, when an inserter wouldn't. You might want that behaviour. Most people didn't. Nothing can be done about the loader thing, but as king_arthur pointed out there are some options for recipes that can be tweaked for the output buffer issue.

10,000?? And you thought 1k was shocking

Makes sense I guess. And yes, the way I build factories, I tend to think in terms of "max usage" in mind so technically as fast as possible or as much resources as possible is what I like. So I build buffer boxes to hold excess production for when I am redesigning or building out more production so the plates/wires etc do not stop producing. I know in a few minutes I'll be at a shortage when the next piece of production comes online, etc.