Ah, OK. Is the prototype staying though for mods in 1.0?
Sure, the prototypes will stay, they are super useful debug entities for us, as well as mods etc.
switching the loaders to stack inserters
wait, what?
Team production would use loaders to input and output items to the player areas. However they don't have proper graphics, so I switched them to be stack inserters
Team production changes
Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love.
So after 4 years of accruing wisdom, I started making some general improvements.
Choose your teams
I think this is one of the main suggestions people had for team production. The scenario just shuffled the players and assigned people randomly, and you could end up all alone playing against your two best friends.
Now I believe anybodies first choice would be to add a GUI to handle this. I will go on about GUIs later, but short story is, I didn't want to add a GUI. They add a lot of complexity, and my development mood these days is to keep things simple and small in scope.
So I added little colored launchpads!
I think it is quite intuitive, you will instant...
Read moreI've never been permitted to register on their forum. No clue why. I register and never get the confirmation email, not even in my spam and junk folders. I stopped bothering after the third attempt. If they can't be bothered having a working forum (or responding to the email I sent about it) then I can't be bothered to report where they expect me to. If they read this, fine... if not... oh well.
or responding to the email I sent about it
I reply to all emails, I don't see any from you about the forum registration, and if you do email I can manually activate your forum account.
Removed core lualib util.encode() and util.decode()
Why was this done out of curiosity? Also was the PVP scenario updated to not use them anymore? Last I knew it made use of these two functions.
There is the new game.encode_string() andgame.decode_string(), which replaced their functionality
Ryzen 7 3800X 8-core, CL 16-16-16-36 3600MHz, Base clock 4.2 GHz
stevetrovs_10K_mega_belt_base.zip
- Performed 1000 updates in 12077.453 ms
- avg: 12.077 ms, min: 11.287 ms, max: 28.803 ms
The new poison cloud looks really nice!
Now if you can apply the same love to the fugly beacons, we can call it 1.0 and move on. :P
We are applying love to the beacons, but they need a lot of it, and they are very important to us, so we are really taking our time with them.
One improvement I would like is high resolution icons throughout; some of them now look a bit 'basic' for a 'complete' game.
(The fact that this is my biggest gripe shows how polished the game is).
HR Icons is on the TODO for 1.0 :)
It's just me or the fight robots should kinda shutdown like its batteries ran out (then crashing in the ground) instead of exploding like they were destroyed by attacks?
In the gif they were killed by damage, so they explode and die catastrophically.
When expiring there is no explosion and they fall more calmly.
I noticed the robot death animations have velocity, will they inherit the robots velocity if it's moving? Would look pretty odd if they died and suddenly went the opposite direction lol.
nope, death particle velocity is not affected by the speed of the robot
Scrolling on the map view of steam turbines or nuclear reactors seems to crash the game in this version. Don't know which of the two yet.
/edit: Crash also happens when zooming on a furnace-array, so might be something to do with the particles or clouds of those buildings.
Also found a crash case when opening a blueprint, working on reproducing it rn.
whoops, hotfix incoming
I think it would be cool if there were mining robots you could research. They would not by flying robots, would work within a ground range of a robo port, deposit into the logistics network, and need to recharge in a similar way to flying robots.
The pros would be very little pollution (equivalent to hand mining) and very little infrastructure (no belts, power poles, miner machines, etc.. just a robo port).
The cons would be that they can't increase productivity in the same way that mining productivity improves the electric miners, and speed could only be increased with worker robot speed / cargo size.
They would be useful for midgame outposts, allowing for simple setup and giving off little pollution, but later game the regular miners would be favoured again.
Like these guys: https://mods.factorio.com/mod/Mining_Drones
Thanks for the feedback, I will take a look at the scenario again before 1.0, so this post is quite useful
Problem with using Space Exploration is that Earendel marks any kind of teleportation mod as conflicting. Even if it's not in the conflict list, there's code to stop the game from loading if any mod has 'teleport' in the name.
There is one exception to that check: https://mods.factorio.com/mod/Teleporters
Are you on the latest version of the mod? please report it on the mod page
It does not from the description.
There is a technology to unlock the MIRV item
There is literally a widely used standard for versioning designed precisely with dependencies in mind
Oh well would you look at that:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Maybe I missunderstood it, but from reading the FFF I got the impression you would introduce major API changes (for example due to GUI changes) in going from 0.18.23 to 0.18.24, as a made up example. Is this not so?
I know it's tricky to make everyone happy, but such big changes should really be more than a minor patch number increase.
It would not be 'major', it would be things like:
- removing the logistic slot technologies
- removing API methods related to reading and setting the slot count
- removing old GUI styles
- changing some GUI style definitions
Why not simply make a 0.19, 0.20, 0.21 etc then? I don't see why you have to go from 0.18 to 1.0 in one go.
Then all mod authors will need to update all their mods all the time, rather than a few mod authors having to update on the rare occasion that during the experimental release of our unfinished game a piece of the game data or API has changed to make their mod not load.
With this in mind, it wouldn't make sense to mark 0.18 stable before most of the above is finished. We made 0.18 a major version because it will break mods with all the changes we are making, and while initially it hasn't broken that much, many things to come will have a bigger impact, such as the Character GUI.
As a software developer and game programmer myself, surely this is the antithesis of the version system
1.2.3
1) most major of content changes, Will quite certainly break derivative works
2) Major content changes, including new content, will quite often require refactoring of derivative works
3) Bug fixes, content balancing, derivative works safeI suppose I am somewhat prone to forgetting that factorio isn't at "version 18" but actually "0.18", but would still expect mod breaking changes to tend to get restricted to level 2 changes, where not absolutely necessary.
That said Unreal Engines build pipleine complains at me every time I compile that my SDK version is (numbers just for example) 1.2.3.0041 and it wanted 1.2.3.0001
Unfortunately the ideals of our versioning system don't always align with the practicalities of shipping a game.