Yuoki Industries - Informations, Suggestions, Questions

[YuokiTani]

okay i experimented a little and looks okay so it's maybe a good idea ...


this allows some interesting new gfx for experiments.

[Neotix]

Looks very promising
With that I will be able to build paths without that annoying poles everywhere and lamps with collisions. Just nice looking patch with lights powered by sun.

[YuokiTani]

Looks very promising
With that I will be able to build paths without that annoying poles everywhere and lamps with collisions. Just nice looking patch with lights powered by sun.

i'am not sure if collision-free possible, but the spot is 1 pixel, and if you run agianst, you automaticly slided around.

[Arch666Angel]

Looks very promising
With that I will be able to build paths without that annoying poles everywhere and lamps with collisions. Just nice looking patch with lights powered by sun.

i'am not sure if collision-free possible, but the spot is 1 pixel, and if you run agianst, you automaticly slided around.

try collision_mask = {"ghost-layer"},

[nastyslave]

Hello dear YuokiTani !
Can I hear your opinion about my little optimisation work with your mod's graphics? --> viewtopic.php?f=70&t=30591\

I write here because I can't sent you a personal messages... because of some limitations here for new users i think..

[YuokiTani]

try collision_mask = {"ghost-layer"},

this works - so next version will include a variant

Hello dear YuokiTani !
Can I hear your opinion about my little optimisation work with your mod's graphics? --> viewtopic.php?f=70&t=30591\
I write here because I can't sent you a personal messages... because of some limitations here for new users i think..

good idea - and much work (personal i would be to lazy to do this ^^)

[Mooncat]

Hi Yuoki,

I don't know whether this has been suggested before, forgive me as I can't search through the amazing 99 pages! (Will this make it 100 pages? )

Do you think it is a good idea if I request the devs to implement something like Fluidbox Category and Fluid Category?

The proposal will be like this:

Different types of fluidboxes are grouped into different categories, for example:

• normal-fluidbox-category
• mechanic-fluidbox-category
• god-fluidbox-category

And fluids are also grouped into categories, for example:

• normal-fluid-category
• mechanic-fluid-category

Then, each Fluidbox Category can work for zero (for whatever reason) to multiple Fluid Categories. Only fluids in any of these categories can be stored/transmitted in these fluidboxes, or you can say, fluidboxes can only store/transmit fluids whose Fluid Category matches their Fluidbox Categories.

The data structure of Fluidbox Category will look like this:

Code: Select all

{
    type = "fluidbox-category",
    name = "god-fluidbox-category",
    fluid_categories = {"normal-fluid-category", "mechanic-fluid-category"}
}

So Pipes/Storage Tanks which have fluidbox of this category can store/transmit fluids of normal-fluid-category or mechanic-fluid-category.

I had this idea because I saw your Mechanic Power and the blue and red shafts. Their appearance suggested that Mechanic Power should only be transmitted with the shafts. But without the categories, we can't add this restriction. (Or have I misunderstood something?)
If you think this is a good idea, I will propose it to the Factorio devs.

[YuokiTani]

ehm, yes ...
it would be helpful but it's in a light version included, because if a recipe not need water the entity will not accept water.

more confusing in my opinon is i cant rename temperature to pressure, rpm, torque or something different. it will always say temperature - this destroys more the illusion of a hydraulic-fluid or a shaft with rpm and torque.
you need a lot of fantasy to imagine 15 °C equals 15 bar and 400 °C = 400 bar MF - or before gearbox 15 rpm in and 115 rpm out ... this would also nice explain the old behavior of overload and stop the turbine ^^ ... but it is how it is

no, it's how you thinked ... blue shaft for low rpm/torque/pressure and red shaft for high rpm/torque/pressure
now the blue ones only need to break on overload if you apply a high rpm/torque/pressure fluid - of course same for turbines that don't accept high rpm and you missleading some fluid

[Mooncat]

ehm, yes ...
it would be helpful but it's in a light version included, because if a recipe not need water the entity will not accept water.

more confusing in my opinon is i cant rename temperature to pressure, rpm, torque or something different. it will always say temperature - this destroys more the illusion of a hydraulic-fluid or a shaft with rpm and torque.
you need a lot of fantasy to imagine 15 °C equals 15 bar and 400 °C = 400 bar MF - or before gearbox 15 rpm in and 115 rpm out ... this would also nice explain the old behavior of overload and stop the turbine ^^ ... but it is how it is

no, it's how you thinked ... blue shaft for low rpm/torque/pressure and red shaft for high rpm/torque/pressure
now the blue ones only need to break on overload if you apply a high rpm/torque/pressure fluid - of course same for turbines that don't accept high rpm and you missleading some fluid

Oh, about the recipe, I had an idea after I turned off the computer last night.
Fluidboxes don't necessarily need any category in prototypes. If no category is defined, the fluidbox can store all fluid categories. So, for assembling machines, their fluidboxes can have no category. It will make no sense if they can produce or require water but their fluidboxes don't accept it.
This can also increase mod compatibility. But I think fluid should have one category so the game engine can group the fluids based on their categories.

About naming, maybe I can also propose an additional property there, so we can replace "Temperature" by other strings. So the data structure will look like:

Code: Select all

{
    type = "fluidbox-category",
    name = "god-fluidbox-category",
    fluid_categories = {"normal-fluid-category", "mechanic-fluid-category"},
    localised_temperature = {"fluid-pressure"}, -- This is the locale key.
}

Thanks for the info on the blue shaft and red shaft. I thought the color difference was for decoration only. Maybe we can create two categories, one for low pressure and the other for high pressure, if the idea is implemented by the devs.

[Fatmice]

I don't think devs will implement such idea. Fluid will undergo some major revision in 0.14 and from what I recall from talking to Rseding, fluid will cease to "flow" and instead will have bulk behavior. Regarding fluid category, I've never heard of such thing nor seen any prototype with such thing. There is crafting category but not fluid category. The fluid boxes take the first fluid type that enters them. From then on, they take only that type until they are recreated or emptied.

[Mooncat]

I don't think devs will implement such idea. Fluid will undergo some major revision in 0.14 and from what I recall from talking to Rseding, fluid will cease to "flow" and instead will have bulk behavior. Regarding fluid category, I've never heard of such thing nor seen any prototype with such thing. There is crafting category but not fluid category. The fluid boxes take the first fluid type that enters them. From then on, they take only that type until they are recreated or emptied.

The fluid category is a part of my idea. Bulk behaviour!? Do you know what's that?

Edit: oh hey~ page 100

Edit2: anyway, I have submitted the idea to the devs (here) with some adjustments, like putting the localised_temperature into fluid prototype because it seems more suitable.

[Fatmice]

The bulk behavior means fluid act like a line segment, having an input and an output. The segment is a stretch of pipes. Fluid in that segment of pipes do not flow but have animation for the "flow." The visual will stay the same. The amount displayed will stay the same. But the underlying code is different. If you pinch the pipe and make some intersections, that action will create more segments. Physics or fluid dynamic will be computed only on the end points and nowhere in between. That is what I understood of bulk behavior. Things may change.

[Mooncat]

It sounds like an optimization for better game performance and is very reasonable, just like the work mentioned in FFF-148, grouping transport-belts into segments. I think my idea can still apply. It just affects whether new segment will be created according to whether the pipe can handle the fluid. Let's give it a try.

[afk2minute]

hi, are you planning to add some tech-tree to the mod?

[YuokiTani]

hi, are you planning to add some tech-tree to the mod?

no, not in the near future - the current research-system doesn't fit my playstyle and expectations.
but a very-lightweight system is in the mod itself - production/use of different signs, special materials and vanailla research dependencys.
(in my opinion better as any xxx-blue flask consume research to get something you already know)

if it will be possible (but it will never) this would my research-solution ...

steam-engine + tech-coins(science) -> improved steam-engine in kW-output
steam-engine + green-coins(science) -> improved steam-engine with lower pollution/fuel-consumption
steam-engine + blue-coins(science) -> improved steam-engine with higher efficency of used fuel
steam-engine + yellow-coins(science) ->improved steam-engine in strength and lowered water-consume

so a improved assembly would always need a standard assembly + faster inserters or speed modules or gears or chests + tech-coins to research a better specific improved assembly.

now its, throw 10K iron and 10K on belts and in some time you have all researched without using your brain ... it's unnessessary to think about research (in my and most-let's plays always something in research was started only for keep research something and turn the research-tab into green icons - independed if this needed or not) - the current research-tree and system feels not natural to me, and most playvideos shows that players are confused about research the next step. but i understand the need for a structural step by step item-release.

I did not want to write this much ^^ - but it looks like research is a good troll for me

[afk2minute]

ah ok, i see your point.

Maybe you can try to make some scenarios where tech is locked until you do some objective, that will serve the purpose (introducing mod to players slowly) but without any need for science.

Anyway, thanks for the mod, i liked it alot.

[Mooncat]

steam-engine + tech-coins(science) -> improved steam-engine in kW-output
steam-engine + green-coins(science) -> improved steam-engine with lower pollution/fuel-consumption
steam-engine + blue-coins(science) -> improved steam-engine with higher efficency of used fuel
steam-engine + yellow-coins(science) ->improved steam-engine in strength and lowered water-consume
...
now its, throw 10K iron and 10K on belts and in some time you have all researched without using your brain ... it's unnessessary to think about research

I think I may (or may not) understand what you meant.... how about a modded GUI that let you choose what you want to research?
1) There will still be technologies for unlocking YI items, but they are all hidden by default.
2) To unlock and research these YI Technologies, a custom entity will be involved. It will be our YI Lab. But its prototype is a chest, to let you put research materials into it.
3) When the lab entity is selected, a custom GUI of YI Technologies will be shown. There will be many categories to research.
4) For example, if you choose to research "Steam Engine", then a tech-tree of "Steam Engine" will be shown.
5) There will be 3 branches, each for one of the improved steam-engines. After you have selected one, it shows what materials you need to provide.
6) After you have put enough materials into the chest, click 'Start". The materials will be consumed immediately, and the research will start.
7) Wait for the research to complete, i.e. wait for N ticks.
8) Once the research has completed, the corresponding Factorio technology from (1) is unlocked and hence the improved steam-engine is also unlocked.

It is doable and sounds fun to play with. But I am just not sure whether it is what you want.
If so, I will find some time to make a prototype next month.

[YuokiTani]

ah ok, i see your point.
Maybe you can try to make some scenarios where tech is locked until you do some objective, that will serve the purpose (introducing mod to players slowly) but without any need for science.
Anyway, thanks for the mod, i liked it alot.

yes, this would allow some corrections to the search-system - like - you have slaugthered 100 Aliens, it's time to improve your gun - or - some of your walls are broken by enemies - why you do not make a research to improve ? - or - "so many repairs - you should develop a better repair-tool" etc.
but these type of triggers needs code, but gives a little better guide and reason to do some research or improvement.
(my favorite would be ... this research was a failure - but at leat you learned something [this item combination was wrong]) ^^

If so, I will find some time to make a prototype next month.

don't waste your time, the next update possible breaks your code.
i think many player like the current system, and a changed or different system will confuse players even more (beside from MF, needed Water-Temperatures or not deployable cyborgs ^^)

i also like the Steam-Coins (a while ago i planned also diesel-coins and future-coins) - but it would be perfect if you can build a small-steam-locomotive and you will get these coins from driving around. and with this coins than you can make research and improve your steam-locomotive designs or release new recipes

the ideas maybe only suitable for me - but i also see factorio not as game - i have bought a game-engine like unity (with basic functions) - and now i need add content to get a game that i like to play ^^ - this leads also to some experiments and stuff, confusing modded-parts, strange machinery and not factorio-universum related includes.

[Mooncat]

Actually, I like this idea too. Although Factorio is about automation, it will be fun to have something that needs to control manually, especially for things that decision making is involved, like Research. And I will make it an optional mod so players can still choose whether they want this research style.

don't waste your time, the next update possible breaks your code.

I don't afraid of that.
I think I will just use item names and recipe names to construct the tech trees. And the mod will start in a very small scale first. It may have only 1 or 2 categories. Each tech tree may have only 2 to 3 levels. About 10 items/recipes will be involved.
But these are still ideas, I need to finish the update of my mod first before I can implement them.
I believe this will make YI much much much cooler and can remove the only shortcoming of it, making it the perfect mod. So, no one can stop me now, unless someone implement this before me.

[YuokiTani]

okay - good luck !

(for now, i have no major changes planed in the next time)