By making the roads single-direction and roads owning the movement, I think it’s been made equivalent to a conveyer belt… which means factorio’s conveyor belt optimizations might be relevant.
Eg storing the delta between items rather than tracking position directly, because the distance between cars is static for the length of the road, except during compression, insertion or removal of a car
Factorio is such a great example of how different the visuals can be from the underlying datastructure. Conveyor belts look hugely complex / heavyweight - if you consider them as individual items each with an x/y position that needs to be updated every tick. But if you see them as a linked list with only a distance and it becomes a lot simpler.
This post also explains why compressed belts are better for performance on very large bases. But despite 1000+ hours in the game I never reached a point where performance was an issue.
That’s the compression, same story in factorio. Before/after compression it’s static, so you can avoid having to update any value.
The main difference from factorio belts I think is actually in the insertion — if there’s no room in the belt, insertion is blocked; whereas I’d expect a car to “slip in”.
But I think you can still say that maintains the property that a compressed belt will always be compressed, excepting insert/removal; and insertion/removal just requires updating a static number of deltas (2, in the middle of the line, 1 at the end of it)
And Factorio belts can have stuff added or removed, also.
The thing is a belt is modeled in terms of deltas rather than positions--there is no need to move each object each cycle. An object has a distance from the object in front. When the belt moves forward this relationship does not change--no need to update every pointer (and there can be a *lot* of belts in the game!) If the head of a belt can't move you only need to update one delta--the gap between the first free item and the stuck item in front of it and that value can already be known, no need to search. If you move the free item up against the stuck item you walk down the belt to find the new first free item.
You only need to modify the belt model if something is either added or removed from the belt. Objects get removed only by inserters, inserters examine only one cell of the belt, grabbing anything in that cell that matches what they are willing to grab (if they are feeding a machine they will only grab what the machine wants, otherwise they'll respect the filter list assigned to them.) When something gets added to a belt you add it to the list and update the delta of the object behind. No general update of the belt is needed in any situation, any more than you need to do anything to the items in a queue as you add and remove items.
Factorio is a game about optimization and the developers did a very good job of applying that idea to the game math. That is, until the masses of asteroids in the Space Age DLC.
I don’t know if it anyone was really making bets around it… it’s just kind of individually meaningless to implement support for until it’s already popular, because you still have to support IPv4 in full until the day you can remove it entirely
Per the article, it’s new to browsers, not compression generally, due to the lack of standardization. the future is already here, just not evenly distributed.
If you're on a desert island and you have 2 watches instead of 1, the probability of failure (defined as "don't know the time") within T years goes from p to p^2 + epsilon (where epsilon encapsulates things like correlated manufacturing defects).
So in a way, yes.
The main difference is that "don't know the time" is a trivial consequence, but "crash into a white truck at 70mph" is non-trivial.
It's different because the challenge with self-driving is not to know the exact time. You win for simply noticing the discrepancy and stopping.
Imagine if the watch simply tells you if it is safe to jump into the pool (depending on the time it may or may not have water). If watches conflict, you still win by not jumping.
I mean daemon was the previous winner before agent, and that had a solid mystical-djinni element to it. Monkey would have naturally gone the way of the daemon, as software development “matures” and undergoes corporate sterilization
If you discard the human-readability component of it, JSON is an incredibly inefficient choice of encoding. Other than its ubiquity, you should only be using JSON because it’s both human and machine readable (and being human-readable is mainly valuable for debugging)
The SQL standard defines more of an aesthetic than an actual language. Every database just extends it arbitrarily and anything beyond rudimentary queries is borderline guaranteed to be incompatible with other databases.
When it comes to procedural logic in particular… you have almost zero chance you’re dropping into that into another database and it working — even for rudimentary usage.
SQL-land is utterly revolting if you have any belief in standards being important. Voting for Oracle (itself initialized as a shallowly copied dialect of IBM SQL, and deviated arbitrarily) as the thing to call “standard” is just offensive.
From-before-select has nothing to do with composition as far as I can think of? That’s to solve the auto-complete issue — put the table first so the column list can be filtered.
Things like allowing repeat clauses, compute select before where, etc are what solve for composition issues
That page has a reasonable re-creation, with trivial usage at call-sites, of each missing feature though? The only one that looks a bit revolting is the large pipe example
Eg storing the delta between items rather than tracking position directly, because the distance between cars is static for the length of the road, except during compression, insertion or removal of a car
https://www.factorio.com/blog/post/fff-176
reply