| 1 | [quote]In gadget code all you'd have to do really is copy every unit/projectile/etc's position, velocity, etc in a table then load it from there.[/quote]That is just saving and loading, that is not the problem. But is not enought. | 1 | [quote]In gadget code all you'd have to do really is copy every unit/projectile/etc's position, velocity, etc in a table then load it from there.[/quote]That is just saving and loading, that is not the problem. But is not enought. | 
                
                    | 2 | In "your time" a unit might be [i]that[/i] position. | 2 | In "your time" a unit might be [i]that[/i] position. | 
                
                    | 3 | In "my time" a unit might be [i]this[/i] position. Or maybe the unit does not exist yet/anymore. | 3 | In "my time" a unit might be [i]this[/i] position. Or maybe the unit does not exist yet/anymore. | 
                
                    | 4 | That is not possible with spring. The same goes for projectiles and everything else. | 4 | That is not possible with spring. The same goes for projectiles and everything else. | 
                
                    | 5 | Imo there are three options and all suck: | 5 | Imo there are three options and all suck: | 
                
                    | 6 | 1) The "Lets' use spring but actually not use it" option. | 6 | 1) The "Lets' use spring but actually not use it" option. | 
                
                    | 7 | Only use spring for rendering, do not use any of its physics, do not use the command system, use it only for rendering things. | 7 | Only use spring for rendering, do not use any of its physics, do not use the command system, use it only for rendering things. | 
                
                    | 8 | Aka the technically correct answer to every problem ever. Sadly it is so theoretical that it is useless. | 8 | Aka the technically correct answer to every problem ever. Sadly it is so theoretical that it is useless. | 
                
                    | 9 | 2) Use multiple instances of spring that talk to each other. This allows different time-zones to be alive at same time. | 9 | 2) Use multiple instances of spring that talk to each other. This allows different time-zones to be alive at same time. | 
                
                    | 10 | This 
            is 
            maybe 
            doable 
            but 
            cumbersome. | 10 | This 
            is 
            maybe 
            doable 
            if 
            spring 
            gets 
            some 
            function 
            to 
            spawn 
            new 
            instances 
            (
            like 
            ~happend 
            when 
            spring.
            restart 
            was 
            bugged)
             
            but 
            cumbersome. | 
                
                    | 11 | 3) Divide the map into several identical areas. Each area is a different time-zone and stuff gets copied around and blabla and each player only sees his area. | 11 | 3) Divide the map into several identical areas. Each area is a different time-zone and stuff gets copied around and blabla and each player only sees his area. | 
                
                    | 12 | \n | 12 | \n | 
                
                    | 13 | None of that seems like a good idea. | 13 | None of that seems like a good idea. | 
                
                    | 14 | \n | 14 | \n | 
                
                    | 15 | @Shadowfury333 : Do you have a source/link for that? | 15 | @Shadowfury333 : Do you have a source/link for that? | 
                
                    | 16 | It reads as if they had to optimize everything to make it work with realistic hardware requirements. That seems bit strange. | 16 | It reads as if they had to optimize everything to make it work with realistic hardware requirements. That seems bit strange. | 
                
                    | 17 | Achron uses 1 GB ram or so,  that includes everything: models, textures, sounds, map etc. | 17 | Achron uses 1 GB ram or so,  that includes everything: models, textures, sounds, map etc. | 
                
                    | 18 | It seems strange that they would optimize to a level of only using 8 bits to store units health and could not fit other properties. | 18 | It seems strange that they would optimize to a level of only using 8 bits to store units health and could not fit other properties. | 
                
                    | 19 | If health and coordinates of a units can be stored then what prevents storing other properties? | 19 | If health and coordinates of a units can be stored then what prevents storing other properties? | 
                
                    | 20 | A few more variables per unit is only a few more bytes, even multiplied by 100 units and even storing it for every single frame (say in a 45min game) would only mean a handful more MB. | 20 | A few more variables per unit is only a few more bytes, even multiplied by 100 units and even storing it for every single frame (say in a 45min game) would only mean a handful more MB. |