Factorio Forums

ledow wrote:... but you also need an audit trail and an undo ...

Undo is never going to happen. It's simply not feasible with all the ramifications of what any given action can actually do.

There's the possibility to expand it in the future but right now you get what I talked about in the FF or you get nothing and nothing sounds far worse than what I talked about in the FF.

Awesome, thanks for the 0.1 version of factorio
Gave me another few hours of fun.

Too bad there's no achievement for this

Hey, one thing bthathas been kept are fish, the item looks the same

0.1 was a missed opportunity for the biggest April prank as release of 0.15.

liij wrote:Admin should be able to give player permission to only deconstruct buiduings(structures) constructed only by this player. That would be most anti grief practical thing ever.

Not sure if it was already said...but what happens when this player builds than an AtomReactor to destroy your base?

I love the Permission System...I will 100% use it giving Moderators the option to give Default playern builder permissions...no more grievers...oh damn cant wait for this to go live...;D

Rseding91 wrote:

ledow wrote:... but you also need an audit trail and an undo ...

Undo is never going to happen. It's simply not feasible with all the ramifications of what any given action can actually do.

There's the possibility to expand it in the future but right now you get what I talked about in the FF or you get nothing and nothing sounds far worse than what I talked about in the FF.

How about realising "undo" by applying the input action permissions system on the "catching up" and "replay" functions? And calling it "restoring".

A game would need to activate replay recording and when it gets griefed, it could be reset to an earlier save state from before the griefing started, and then the recorded input actions are applied on top of that saved state in the fashion of the catching up function, but with altered input action permissions to prevent the fraudulent actions. As state progresses differently then, many input actions might not get the original result or fail due to unfullfilled conditions. But I think in a griefed game, a state produced like this, is probably still prefered by many compared to the current griefed state or a reset to an earlier state. Since effective griefing remains undetected for a long time, the percentage of failed input actions by other players shouldn't be that problematic either. One might stop the "catching up", once a predefined limit of x percent failed input actions per player is surpassed in a time frame, as further progression might not be desired anymore.

Effectively that would mean allowing to backdate changes to the input action permissions system.

Me has a question.
Train question.

Will we get train schedules working like flowcharts? Like being able to write formula like "Go to A if (x), else go to B if (!x and y), else go to C" for every station?

POPISowyNumer wrote:Me has a question.
Train question.

Will we get train schedules working like flowcharts? Like being able to write formula like "Go to A if (x), else go to B if (!x and y), else go to C" for every station?

I have wondered about this too, but the actual implementation of it seems difficult. How do you, for example, Go to station B only if the chests at station A are full. You cant do it through the logistics network, as the train cant connect directly. Wires cant just be left trailing behind a train for eternity.

I can see 2 possible implementations:
1. You connect the circuit network to the stations and send the train signals through there, allowing an If, Then format within the trains gui. This does bring up the issue that the information can only be sent when the train is in the station. The state of the chests at station A may change drastically by the time that the train has gone to station B and back.
2. The conditions are sent through the logistics network, requiring research or something to acquire. Possibly a train carriage like a reciever needs to be added to any trains you want controlled. With this method, however, it would be quite difficult to do things like only go if the chests at station A are full, as the logistics network would probably only be able to send totals, not where the items are.

Neither approach is particularly good, however I would lean towards option 1, as it seems more useful. There are certainly more approaches that I haven't spotted though which may work better. I do like the idea of branching conditions for trains though and I hope it gets implemented at some point.

In electronics simulations you can name your signals and access them by their names. Named train stations, logistic towers or combinators/transmitters would fit that.

Do the buildings have some kind of age? We could then make destruction dependent on the age of the building.

For example: If it's younger than 5 minutes, everbody can deconstruct it.

steinio wrote:0.1 was a missed opportunity for the biggest April prank as release of 0.15.

I'm still waiting for the Factorio port on Android. So looking forward to the Pay 2 Automate concept https://www.factorio.com/blog/post/fff-132

judos wrote:Awesome, thanks for the 0.1 version of factorio
Gave me another few hours of fun.

Too bad there's no achievement for this

Now I see where that Laser Turret icon came from! However it is not relevant now so it should possibly be replaced.
And gratz on this 5 year anniversary! You have sustained a great path and I wish you can achieve much more!
Awesome job and keep it up! You are definitely THE BEST game developers I've ever met!

I look at 0.1 and I get the impression you guys have added tons of recipes but never gone back and reviewed them as a whole. I mean you're still using nearly all the same stuff from five years ago, much of it just doesn't fit with the current scope of the game such as tiers of machines that just get skipped and components that are used in two obscure recipes. As it stands you could drop wood from the game entirely, replace it with Iron Plate, and it wouldn't have any real impact. The best use it has is an early game fuel source and then it quickly becomes a nuisance. Even in speed runs it's only used to kickstart your coal miner a smidge faster.

IMO recipes need a huge clean up, the rest of the game is so tidy, refined and beautiful, this clutter in the crafting window really lets it down. I assume this is in the cards for 0.16, if not then it should be.

Будут ли новые достижения в 0.15 ?
Will there be new achievements in 0.15?

commandoby wrote:Будут ли новые достижения в 0.15 ?
Will there be new achievements in 0.15?

Nope

Floaf wrote:Have you guys given any thought about how the autosave works? In later gameplay it can take 15-20 seconds to save and if you autosave like every 2 minutes (since you are hunting biters) it get a little bit tedious.

Shouldn't it be possible to just make a copy of the game state and saving that state on a separate thread in the background? Of course it still may take some time to copy the state, but it should be much faster.

Just a thought

Saves on large maps even in vanilla are annoyingly slow. Mod free on a 3.7Ghz Xeon E5 and a Samsung 850 Pro SSD 2 minute autosaves become insanely aggravating. Even if it only takes 5 seconds (which is not uncommon for me on very large maps) it becomes like a regular 2 minute jolt that just rips you right out of the game. About the only thing worse is disabling or extending it and losing a ton of work.

I brought this up on a reddit thread, and kovarex actually replied with some interesting information here: https://www.reddit.com/r/factorio/comme ... s/d90yy8q/

I really hope this experimental saving method he mentions makes its way into the main game before 1.0. Seemless auto saving would be epic as hell!

MrGrim wrote:

Floaf wrote:Have you guys given any thought about how the autosave works? In later gameplay it can take 15-20 seconds to save and if you autosave like every 2 minutes (since you are hunting biters) it get a little bit tedious.

Shouldn't it be possible to just make a copy of the game state and saving that state on a separate thread in the background? Of course it still may take some time to copy the state, but it should be much faster.

Just a thought

Saves on large maps even in vanilla are annoyingly slow. Mod free on a 3.7Ghz Xeon E5 and a Samsung 850 Pro SSD 2 minute autosaves become insanely aggravating. Even if it only takes 5 seconds (which is not uncommon for me on very large maps) it becomes like a regular 2 minute jolt that just rips you right out of the game. About the only thing worse is disabling or extending it and losing a ton of work.

I brought this up on a reddit thread, and kovarex actually replied with some interesting information here: https://www.reddit.com/r/factorio/comme ... s/d90yy8q/

I really hope this experimental saving method he mentions makes its way into the main game before 1.0. Seemless auto saving would be epic as hell!

It's not going to happen.

MrGrim wrote:Saves on large maps even in vanilla are annoyingly slow. Mod free on a 3.7Ghz Xeon E5 and a Samsung 850 Pro SSD 2 minute autosaves become insanely aggravating. Even if it only takes 5 seconds (which is not uncommon for me on very large maps) it becomes like a regular 2 minute jolt that just rips you right out of the game. About the only thing worse is disabling or extending it and losing a ton of work.

I brought this up on a reddit thread, and kovarex actually replied with some interesting information here: https://www.reddit.com/r/factorio/comme ... s/d90yy8q/

I really hope this experimental saving method he mentions makes its way into the main game before 1.0. Seemless auto saving would be epic as hell!

Remember also that save file sizes should decrease by quite a bit in 0.15 with the changes to how decoratives are being handled. More info: https://www.factorio.com/blog/post/fff-157

I have to agree with giving ownership to buildings. It would have the added benefit of being able to have a console command that deletes all structures created by player X.