Hello,
We released 0.18.2 and 0.18.3 this week. In terms of major releases, this one has very few bugs, so we haven't had a lot of pressure to crank out the releases at lightning speed.
In the sound design department we have been hard at work to bring you a better gaming experience with the help of some new and improved sound effects. It struck me that the whole sound track used to have a lo-fi, almost 'dirty' feel, by which I mean the sounds were unclear, had a low resolution and possibly used recordings made with the wrong microphone positioning. So with Val's help we have set about improving some of these sounds. For example, there are new sounds for all the transport belts, they don't sound very different but they are smoother sounding and less annoying.
Mp4 playback not supported on your device.
Similar to the transport belts, we also have sounds for the combat robots that are designed to harmonise with one anoth...
Read moreAre 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:
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.
Read moreWith 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 p...
Unfortunately the ideals of our versioning system don't always align with the practicalities of shipping a game.
A heads up in case you weren't aware, the following are probably the two most popular ZFS automatic snapshot management tools that can also send:
https://github.com/jimsalterjrs/sanoid
https://github.com/yboetz/pyznap
The developers of these are active over at r/DataHoarder/ and r/zfs/ in case you have any questions.
I actually have my own that I wrote for personal use: https://gitlab.com/wheybags/zfs_scripts
However, we will probably just be using rsync for backups, since we still intend to use a pair QNAP nases as a backup targets, since we've got the hardware already. It's not ideal, but at least it's just for backups. And if one of them fails, we can still read the drives using the other one.
Early this week we pushed the deploy button on 0.18.0 (patch notes). This was quite a surprise to many of our players, as more typically the time between major releases and the scope of the release is greater. However this isn't like the old days, we are trying to keep the size of releases as small as possible (...
Read moreSorry. I'm new to this mod. How exactly do you get nukes like that? Is it the vanilla nuke recipe? Or is there a separate recipe? Thanks!
There is a separate recipe for the M.I.R.V item, you put that in a rocket
Lol. The file sizes we are talking about would be tiny. Honestly this pixel shader load could be run by cards that came out 14 years ago. And if you really cant run it toggling it would be a simple solution. This wouldn't be some crazy complex programming. This is a technique that was simple when it came out a LONG time ago.
The only real cost would be making the normalmaps in the first place as they would need to be generated and touched up for every object.
But as for the matter you and everyone else is talking about. Performance... I'm afraid that anyone who thinks this would be a performance related issue simply doesn't actually understand how this technique works in the code and hardware.
Having normal maps for all sprites would not be tiny
Factorio is always a cpu bottleneck. Most modern gpus would have tons of pixel shader headroom to handle this. You would get basically the same fps.
And all our players on laptops and older hardware would struggle with choppy gameplay, or not even be able to load at all depending on the VRAM requirement increases.
wait, 0.18 is out?
Oh yea
Sorry, but looks like simply reskined of https://mods.factorio.com/mod/Orbital%20Ion%20Cannon or https://forums.factorio.com/viewtopic.php?f=93&t=17910, even similar CnC effects
Probably some code stuff were improved, can be more balanced than anything from before, better scripted... effect looks very similar
It shares no code or logic from LOIC, and they work in fundamentally different ways.
devtrackers.gg