Page 1 of 3

Friday Facts #84 - The wedding day preprations

Posted: Fri May 01, 2015 11:24 am
by kovarex
No, no one from the team is getting married yet :) https://www.factorio.com/blog/post/fff-84

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 11:39 am
by keyboardhack
Really looking forward to those optimizations! Optimizations is the best kind of updates :D
That electric beam is just pure awesomeness and i can't wait to melt biters with it.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 11:40 am
by McRib
Still kovarex, the point behind pay mods is that the dev and valve get a lot more money from mods than the modder do. That is why people dont like pay mods because we dont pay the modders we pay the dev and/or valve for this mods. That is just greedy. So a donation button for example is much better. Also they are no ways to prevent plagerismen on this mod once you bought it. I mean you can just simple reupload them this is already a big issue. Because there is no way to remove this mods from the workshop.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 11:46 am
by kovarex
McRib wrote:Still kovarex, the point behind pay mods is that the dev and valve get a lot more money from mods than the modder do. That is why people dont like pay mods because we dont pay the modders we pay the dev and/or valve for this mods. That is just greedy. So a donation button for example is much better. Also they are no ways to prevent plagerismen on t hismod once you bought it. I mean you cam just simple reupload them this is already a big issue. Because there is no way to remove this mods from the workshop.
I understand. If we ever do paid mods, it would be outside the workshop on our own mod db page, the modder would get most of the money, and the plagerism could be simply avoided by having manual review of every paid mod submission. But please, this is just a speculation, I'm not saying we will do that.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 11:50 am
by McRib
kovarex wrote:
McRib wrote:Still kovarex, the point behind pay mods is that the dev and valve get a lot more money from mods than the modder do. That is why people dont like pay mods because we dont pay the modders we pay the dev and/or valve for this mods. That is just greedy. So a donation button for example is much better. Also they are no ways to prevent plagerismen on t hismod once you bought it. I mean you cam just simple reupload them this is already a big issue. Because there is no way to remove this mods from the workshop.
I understand. If we ever do paid mods, it would be outside the workshop on our own mod db page, the modder would get most of the money, and the pagerism could be simply stopped by having manual review of every paid mod submission. But please, this is just an speculation, I'm not saying we will do that.
Im fine with that. I was only pointing out that the issue is not that we need to pay for mod it is more like we pay the wrong people for that. A tax for the server and transaction is fine as long still the modder get some momey out of it and dont end up get 25% where still tax need to be pay for income (in german you need to pay tax on income)

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 12:50 pm
by nours77
can t wait to play a finish stat of factorio... starship already in finish stage ?

Give money for a mod. well, it s not a good idea for me !
In first because the game is not belong to modder, and the owner maybe not like if mod make more money than the game...
In two because many system already exist like patreon.com (but it s donate) and steam just want make more money with anything. Modder should stay where they are, game lovers and no change to dealers...
In end, i will not paid for a mod, i prefer use my money to paid anothers games, i think it s better. I have not a lot of money to spend in my hobby. It s better play lots of various games (more fun for me).

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 2:12 pm
by Acetylene
Really loving the new look of the combat drones and the beam effect. Speaking of bots, do you still have plans for this feature you talked about on the main website?
RTS elements
In the late game you have this monstrous factory full of machines, trains and flying robots. But you are still a guy running around on your own. Wouldn't it be cool if you could get into your command center and just give orders to your building / combat drones?
Also, I really like how much is going on visually with the world in the screenshot you posted on blog post #54 (http://assets-factorio-com.s3.amazonaws ... lebots.jpg), sometimes I feel the game world can feel a little bit barren compared to that. That's part of the reason I think adding simple cliffs similarly to how they are done in Command & Conquer 95 (http://paulthetall.com/wp-content/uploa ... nshot2.jpg) would bring an interesting visual and gameplay element. They look great and add another level of consideration to base design I think novice and experienced players would appreciate, but could also be knocked down (or built!) as the player needs. Although this is partly playing into my desire into building a base that makes me feel cosy.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 2:15 pm
by Smarty
no pics about the behemoth biter or spitter?

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 2:24 pm
by quinor
About that lighting: what about physically accurate lighting simulation rendered to beam animation?

http://gamma.cs.unc.edu/FAST_LIGHTNING/ ... g_2007.pdf

It would look triple awesome!

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 2:39 pm
by Gandalf
Smarty wrote:no pics about the behemoth biter or spitter?
Yeah, that sounds like "big" news to me. :D

@kovarex I was wondering if all the optimizations are gonna impact the game's realism?
As I understand it, factorio started out by simulating everything individually, every tile on a belt, every solar panel, every steam cloud, etc. It seems in order to optimize the game you are now going further in the direction of what games like Sim City are doing, where you just have a theoretical value that is used in calculations, while all the visible instances in the world try to behave sort of appropriately to that value. That approach obviously leads to some discrepancies in what's visually happening in the game.

So for example with tiles on a belt, in a true simulation I can rely on every single tile being exactly where it appears to be. If you take the individual simulations away, doesn't that change the apparent behaviour, too? The greatly reduced amount of collision checks must mean that certain collisions are simply ignored.

Maybe a better example: Does the bundling of accumulators mean they no longer have an individual charging state? So if I add a new accumulator to a network with several fully charged accumulators, will it no longer know which of the accumulators needs to be charged? It'll just know that there's one accumulator worth of un-filled capacity in the entire network. So if you were to quickly add and remove that accumulator (because you misplaced it) that would reduce the overall charging-state of the network, if all accumulators are treated as one unit.
I hope somebody gets what I mean. xD

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 2:52 pm
by kaldskryke
I'm excited for bigger enemies! Biters and Spitters in this game die way too quickly. If you blink, you will miss them. For a game as thoughtful and "slow" as Factorio, the combat is very fast. It's a big contrast that feels very jarring. Bigger, slower biters that live longer but do more damage sounds like it will help. I still think Factorio needs a combat balance iteration, but behemoths will help.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 3:05 pm
by Xterminator
This is so exciting to me! I love the new electric type combat robot, I think it will be a very good addition. Also, the news of a 4th and stronger biter just made my day. :D This will add a new element and challenge to the game that I think it really needs! I hope they are a lot harder to kill, so you actually have o worry about if your defenses are strong enough.

And of course, all those optimization improvements are always great. You guys are doing a great job, and I can't wait until the first 0.12 version is out!

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 3:18 pm
by Legoman165
3 times bigger factories here I come! Super excited for such an amazing game to be super efficient and not resource intensive at all. I have this on my asus t100ta (transformer book) and it runs fine! U guys might want to think about making an app for tablets with them getting more and more powerful factorio could run on tablets!

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 3:20 pm
by Alekthefirst
Legoman165 wrote:3 times bigger factories here I come!
you stole my relpy :D :D :D :D :D

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 3:28 pm
by Legoman165
Alekthefirst wrote:
Legoman165 wrote:3 times bigger factories here I come!
you stole my relpy :D :D :D :D :D
FIRST!! :P

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 3:58 pm
by kovarex
Gandalf wrote:
Smarty wrote:no pics about the behemoth biter or spitter?
Yeah, that sounds like "big" news to me. :D

@kovarex I was wondering if all the optimizations are gonna impact the game's realism?
As I understand it, factorio started out by simulating everything individually, every tile on a belt, every solar panel, every steam cloud, etc. It seems in order to optimize the game you are now going further in the direction of what games like Sim City are doing, where you just have a theoretical value that is used in calculations, while all the visible instances in the world try to behave sort of appropriately to that value. That approach obviously leads to some discrepancies in what's visually happening in the game.

So for example with tiles on a belt, in a true simulation I can rely on every single tile being exactly where it appears to be. If you take the individual simulations away, doesn't that change the apparent behaviour, too? The greatly reduced amount of collision checks must mean that certain collisions are simply ignored.

Maybe a better example: Does the bundling of accumulators mean they no longer have an individual charging state? So if I add a new accumulator to a network with several fully charged accumulators, will it no longer know which of the accumulators needs to be charged? It'll just know that there's one accumulator worth of un-filled capacity in the entire network. So if you were to quickly add and remove that accumulator (because you misplaced it) that would reduce the overall charging-state of the network, if all accumulators are treated as one unit.
I hope somebody gets what I mean. xD
I know exactly what you mean. You don't have to be afraid, the algorithms are made in a way, that they keep the complexity of the game. The accumulators for example are merged only when they have the exactly same charging state, in other words, from the external point of view, the should act the same.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 3:59 pm
by kovarex
kovarex wrote:
Gandalf wrote:
Smarty wrote:no pics about the behemoth biter or spitter?
Yeah, that sounds like "big" news to me. :D

@kovarex I was wondering if all the optimizations are gonna impact the game's realism?
As I understand it, factorio started out by simulating everything individually, every tile on a belt, every solar panel, every steam cloud, etc. It seems in order to optimize the game you are now going further in the direction of what games like Sim City are doing, where you just have a theoretical value that is used in calculations, while all the visible instances in the world try to behave sort of appropriately to that value. That approach obviously leads to some discrepancies in what's visually happening in the game.

So for example with tiles on a belt, in a true simulation I can rely on every single tile being exactly where it appears to be. If you take the individual simulations away, doesn't that change the apparent behaviour, too? The greatly reduced amount of collision checks must mean that certain collisions are simply ignored.

Maybe a better example: Does the bundling of accumulators mean they no longer have an individual charging state? So if I add a new accumulator to a network with several fully charged accumulators, will it no longer know which of the accumulators needs to be charged? It'll just know that there's one accumulator worth of un-filled capacity in the entire network. So if you were to quickly add and remove that accumulator (because you misplaced it) that would reduce the overall charging-state of the network, if all accumulators are treated as one unit.
I hope somebody gets what I mean. xD
I know exactly what you mean. You don't have to be afraid, the algorithms are made in a way, that they keep the complexity of the game. The accumulators for example are merged only when they have the exactly same charging state, in other words, from the external point of view, the should act the same.
The transport belt movement is changed a little bit, but I believe that it is better as the transport belts are much more predictable and bug free now.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 4:12 pm
by McRib
Kovarex i found this news:
https://steamcommunity.com/games/SteamW ... 5253244218
at last valve is not so pigheaded at all.

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 4:15 pm
by kovarex
McRib wrote:Kovarex i found this news:
https://steamcommunity.com/games/SteamW ... 5253244218
at last valve is not so pigheaded at all.
I know, this is why I wrote: "It had been cancelled already."

Re: Friday Facts #84 The wedding day preprations

Posted: Fri May 01, 2015 4:19 pm
by infogulch
Smoke simulation optimisation
Usage of the formula lets me know the position of the smoke without the need to update it every tick.
If you keep a position (and maybe velocity) history of smoke-emitting items, you could change smoke to be an exclusively render-time object. I.e. if it's not showing on screen it doesn't even exist! Then as the viewport moves into an area with smoke, it calculates the expected position of each smoke particle based on that saved history and renders it with your formula.

The history could be implemented as a very efficient circular buffer just long enough to render the oldest particles before they disappear.