[0.17] Please post bugs and balance issues here.

[Foxy_Boxes]

I'm not seeing any effect from the classes?
Just started as a Miner and am unable to hand-smelt ores.

[bobingabout]

I'm not seeing any effect from the classes?
Just started as a Miner and am unable to hand-smelt ores.

Thank you for the report. it looks like while I was trying to get the "don't show the GUI in the map editor" thing set up, which wasn't working at the time, during my "Well, it shouldn't crash when you pick a class, even in this mode", I kinda added a check to see if a variable that didn't exist was nil, to not replace the character if it is nil, and, well, since it's a variable that never exists, it's always going to be nil, so it never replaces the class.

[TheRealBecks]

We're right in the middle of the game with all (?) Bob's mods (plus a few more) active. Actually the biters don't attack anymore. One week ago before the pollution update the game worked quiet good, but now about all biters stand still in their bases. Only a few attacks with little groups are seen here and there, but way less than 10 % from before.

Can anyone confirm that strange biter behaviour?

[BlueTemplar]

Does your pollution still reach the spawners ?

[orzelek]

We're right in the middle of the game with all (?) Bob's mods (plus a few more) active. Actually the biters don't attack anymore. One week ago before the pollution update the game worked quiet good, but now about all biters stand still in their bases. Only a few attacks with little groups are seen here and there, but way less than 10 % from before.

Can anyone confirm that strange biter behaviour?

Open the new pollution graph and check if any of the spawners are consuming pollution. If they are and there are no attacks then something might be bugged - that would be more on base game side then mod side. Mod only defines what biters should spawn from given spawner rest of the logic is in base game.

[TheRealBecks]

Yeah, pollution is still consumed by biter nests. See the attached screenshots...

Pollution in the last 10 h:

pollution.jpeg (322.03 KiB) Viewed 5365 times

Kills in the last 10 h:

kills_10h.jpeg (345.06 KiB) Viewed 5365 times

...and kills in the last 1 h:

kills_1h.jpeg (289.22 KiB) Viewed 5365 times

So, as everyone can see, it's not working correctly.

Edit:
I wanted to file a bug reported, but someone already did. So it seems to be a general bug: viewtopic.php?f=7&t=67861

[_npo6ka_]

Hello. I am working on modifying the Xander mod under version 17 and I discovered a problem with ore generation. I decided to check your mod, and your mod has the same problem. Some ores spawn at the same point, it can be clearly seen in the picture. Is this a flaw in our code or is it a bug report?

IMG

[bobingabout]

Hello. I am working on modifying the Xander mod under version 17 and I discovered a problem with ore generation. I decided to check your mod, and your mod has the same problem. Some ores spawn at the same point, it can be clearly seen in the picture. Is this a flaw in our code or is it a bug report?

IMG

it is a known issue with the new ore spawning system. It uses a system to prevent ores from stacking on top of each other, but that system is dependant on knowning how many ores are available before it begins. these values are hard set to 4 (starting area) and 6 (total), exactly what the base game has. so when you go over that number, like when mods add new ores and use the same system, you get these errors.

I have been considering a modding fix, which involves copying the base game function into my library, an editing it to not be dumb, but that would only work if everyone who wanted to use that new system then used my library mod.

You're probably best sticking with RSO.

[ukezi]

I have been considering a modding fix, which involves copying the base game function into my library, an editing it to not be dumb, but that would only work if everyone who wanted to use that new system then used my library mod.

You have access to the code base. You could write a fix for the base game function and submit it to the devs to be integrated into the next release.

[BlueTemplar]

See [0.17.x] demo-resource-autoplace.lua sucks

[bobingabout]

I have been considering a modding fix, which involves copying the base game function into my library, an editing it to not be dumb, but that would only work if everyone who wanted to use that new system then used my library mod.

You have access to the code base. You could write a fix for the base game function and submit it to the devs to be integrated into the next release.

Yeah, a "Fix" isn't what it needs, it needs a rewrite:

See [0.17.x] demo-resource-autoplace.lua sucks

[RocketManChronicles]

Hello. I am working on modifying the Xander mod under version 17 and I discovered a problem with ore generation. I decided to check your mod, and your mod has the same problem. Some ores spawn at the same point, it can be clearly seen in the picture. Is this a flaw in our code or is it a bug report?

IMG

it is a known issue with the new ore spawning system. It uses a system to prevent ores from stacking on top of each other, but that system is dependant on knowning how many ores are available before it begins. these values are hard set to 4 (starting area) and 6 (total), exactly what the base game has. so when you go over that number, like when mods add new ores and use the same system, you get these errors.

I have been considering a modding fix, which involves copying the base game function into my library, an editing it to not be dumb, but that would only work if everyone who wanted to use that new system then used my library mod.

You're probably best sticking with RSO.

What does RSO (with bob's ores) provide in this case compared to vanilla (with bob's ores)?

[orzelek]

...

What does RSO (with bob's ores) provide in this case compared to vanilla (with bob's ores)?

It provides the same as RSO with vanilla: more sparse resources with guaranteed starting area resources.
When used with bob's ores it has the benefit of having it's own resource generation system that actually tries to make sure ores do not overlap.

[bobingabout]

...

What does RSO (with bob's ores) provide in this case compared to vanilla (with bob's ores)?

It provides the same as RSO with vanilla: more sparse resources with guaranteed starting area resources.
When used with bob's ores it has the benefit of having it's own resource generation system that actually tries to make sure ores do not overlap.

Basically... Something that actually works.

[Recon419A]

Hey Bob, wanted to crosspost this here. Don't think it's either person's fault directly, just an unforeseen collision.

https://github.com/McGuten/5DimsFactorioMods/issues/89

[bobingabout]

Hey Bob, wanted to crosspost this here. Don't think it's either person's fault directly, just an unforeseen collision.

https://github.com/McGuten/5DimsFactorioMods/issues/89

I know exactly what the issue is.

next_update is a tag entities have to tell the update planner what the defaults are if you don't set a manual configuration.
Since bobassembly adds furnaces up to MK4, there's a clear progression chain of Electric Furnace -> MK2 -> MK3 -> MK4, so I use next_update to assign that.
5Dim then changes the fast replace group of the Electric Furnace to "electric-furnace", perhaps because he adds his own furnaces, which causes mine to no longer be in the fast replace group, breaking the chain.

To be honest, since you can only fast replace an entity with another of the same size (Unless they changed things without me realising, You can replace belt and splitter with each other now, and they're not the same size), changing the group would be pointless because stone/steel furnaces can't be fast replace with electric furnace anyway.

Either way, it is something I could possibly fix, by applying the "electric-furnace" fast replace to all my 3x3 electric furnaces, including Chemical and Mixing furnaces. (7 in total if you include the base game electric furnace, chemical and mixing from bobplates, then the 3 tiers added to furnace in assembly, and the 2 tiers of chemical-mixing furnace)
But to be honest, it's not really a change I WANT to make, because then it could break the fast replace groups of other mods that add an electric furnace with fast replace group "furnace", as is default.

[ChaoticMind]

Hey Bob: I was giving your mods a shot, and was frustrated that the reach seems to be so much less than what I'm now used to in 0.17. After investigating (weirdly, I couldn't find anyone complaining about this already), I found that the values in the "character classes" mod (https://mods.factorio.com/mod/bobclasses) are still based off of the 0.16 reach value of 6. 83.33% and 133% of 6 are 5 and 8 respectively.

I believe the values in "player.lua" should be updated to be relative to 0.17's default reach value of 10 ("build_distance" and "reach_distance"), otherwise all three player classes have a considerable disadvantage over the "vanilla class".

[MageKing17]

Hey Bob: I was giving your mods a shot, and was frustrated that the reach seems to be so much less than what I'm now used to in 0.17. After investigating (weirdly, I couldn't find anyone complaining about this already), I found that the values in the "character classes" mod (https://mods.factorio.com/mod/bobclasses) are still based off of the 0.16 reach value of 6. 83.33% and 133% of 6 are 5 and 8 respectively.

I believe the values in "player.lua" should be updated to be relative to 0.17's default reach value of 10 ("build_distance" and "reach_distance"), otherwise all three player classes have a considerable disadvantage over the "vanilla class".

I think it would make more sense for them to be calculated instead of explicitly set to specific values.

[bobingabout]

Hey Bob: I was giving your mods a shot, and was frustrated that the reach seems to be so much less than what I'm now used to in 0.17. After investigating (weirdly, I couldn't find anyone complaining about this already), I found that the values in the "character classes" mod (https://mods.factorio.com/mod/bobclasses) are still based off of the 0.16 reach value of 6. 83.33% and 133% of 6 are 5 and 8 respectively.

I believe the values in "player.lua" should be updated to be relative to 0.17's default reach value of 10 ("build_distance" and "reach_distance"), otherwise all three player classes have a considerable disadvantage over the "vanilla class".

I think it would make more sense for them to be calculated instead of explicitly set to specific values.

Perhaps. that's actually not a bad idea.

[Aphelius]

After finishing Chemical Processing 2 research the game crashed