--- Clone carriage from the old.
-- @tparam class<Carriage> old_carriage
function Carriage:clone(old_carriage)
local restore = function(e)
-- @todo more accurate and flexiable is to check unit_number in CarriageDoorManager
if e.source.name ~= "player-port" then return end
local old_doors = old ...

/c
global.entity = game.player.selected
game.print(global.entity.valid) -- true
game.player.selected.destroy()
game.print(global.entity.valid) -- false


If you store anything in global, you must always check .valid because something else destroy it.


thx your reply.
should i consider like ...

I'm still confused for this valid property.

How, when, what trigger this property to be false and luobj is still not nil ?

As i discovered, when deleted a surface in one event, the surface will be actually destroyed in next tick. It seems this will happen. (I did not test it)

1. undentify entity -> search in one table table[id] -> get data to indentify role. flat strategy. but all roles in one table
2. undentify entity but has a private field, string -> split into parts, get role info -> then push into role table


Stringly typed system. But what is the difference ...

then, find all doors
you iterating all over this table ?


Now you are shifting onto a different problem. First one was to convert entity into data held in mod context, that can be done using unit_number or the backup one using registration. Second one is a different problem to solve. If you ...

I have a global.by_id that maps any entity unit_number I'm interested in to my internal data for that entity. If the entity name isn't enough to figure out the role then my internal data has a type field.

So it's always simple to do stuff:


local data = global.by_id[entity.unit_number]
if data ...

This would increase memory usage
If store the private data in global, is also consuming memory. That's the same.


Please read more careful. If you have 1000000 entities on map (lets say, trees, belts, biters, everything), adding 16 extra bytes to every entity would immediately give 16MB of ...

Unlikely to be ever implemented. This would increase memory usage for every entity or would require separate map implemented outside of the entity itself. There would be also issue with lifetime of such variable (if it would go over single tick, would need to be save/loaded) and would have to be ...

In some cases, I need a property to temp store plain value. For example

Surface clone area will trigger on_entity_cloned.
if the origina entity which i used for a door or portal. I need listen this event to compare a cache table to find the cloned entity.
doors, a cache table , store all door ...

serpent.block is trying to avoid writing variables it already printed in case of cyclic or multiple references. In that case, it will print a placeholder value - here it will be "0" - but due to the nature of serpent.block, it will not print the fixing part that links all the references (it would ...

using serpent.block, dump this
["facto.train.carriagefactory"] = {
instanced = {
["31"] = {
factoobj = {
__self = "userdata"
},
order = 1,
train = {
carriages = {
0
},
factoobj = {
__self = "userdata"
},
id = 2,
surface = {
__self = "userdata"
}
}
}
}
},
["facto.train ...

You guys focus the details. That's not what I cares about so much.
I just tell a very simple basis, a very simple diagram, a very simple mechanism to clear when, where, how will cause desync problems . Even somewhere i guessed wrong.
Thanks all of your reply. 不要太杠精

Avoid desyncs by avoiding to do anything the manual tells you to not do, and don't do anything that gives defferent clients different states for the same tick. You don't have to figure out what clients are doing what etc, because then you are doing something wrong. You don't think about ...

Avoid desyncs by avoiding to do anything the manual tells you to not do, and don't do anything that gives defferent clients different states for the same tick. You don't have to figure out what clients are doing what etc, because then you are doing something wrong. You don't think about ...

Why I seperately reposted this content. I think, lots of new moders have the confusion about the desync problems. New does not mean has no any programming experience. Like me, I have engaged in programming at least 25 years. Even this, only depending on read offical doc, you can not fully understand ...

Avoid desyncs by avoiding to do anything the manual tells you to not do, and don't do anything that gives defferent clients different states for the same tick. You don't have to figure out what clients are doing what etc, because then you are doing something wrong. You don't think about ...

Another mentioned here. ramdom() function ,if facto rewrites this method using game.tick time. that will be no problem for player A and player B
I just gave an example. random things always can he happened.

1. Game saved. With a gameState = N
2. One player A join -> download the save with gameState = N -> in his client on_load event triggered => Pass gameState into script => This is point
3. Player A going to play -> triggered M*event -> gameState changed to X, at this time another player B join
4 ...

1) If every time on_load triggers you always do game_data = global.facto and never assign anything else then that works fine (unless the game says you can't).

The important part is that after on_load all players must have the same game state. And only the newly joined player runs on_load afaik ...

mrvn wrote: Wed Aug 12, 2020 1:06 pm

kendoctor wrote: Sun Aug 09, 2020 11:37 am thx, actually , i want a proerty of entity to store this data.

Can't. That wouldn't be stored in save games and therefore lost when you load it again.

thx your reply. In old vb programs, mcrosoft using this tech for vb objects to store private data. That's why i ask this question