
phosit
WFG Programming Team-
Posts
129 -
Joined
-
Days Won
2
phosit last won the day on December 1 2023
phosit had the most liked content!
About phosit

Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
phosit's Achievements

Duplicarius (4/14)
70
Reputation
-
phosit started following Observation on Diplomacy , AMD Vulkan issues , Victory Conditions Ideas and 1 other
-
Did you instal vulkan-icd-loader and vulkan-radeon?
-
Sorry if it was already proposed: Asymetric victory conditions For example on "White Cliffs of Dover" the invading units have to build a settlement. Instead of conquesting the Britons they could prove that they have a stable settlement by building a wonder. The condition would then be Team 1: conquest the invadors Team 2: conquest the Britons or build a wonder When "Asymetric victory conditions" would be in place it would be easy to build a tower defence scenario. Team 1: keep the wonder for x time Team 2: destroy the wonder Should something like that be in 0 A.D. or should it only be in mods? Is there already a map which does that?
-
Is this still a problem? I haven't seen such a report in a long time.
-
I'm not working on it.
-
Could you attach the replay-file?
-
PR for validating game engine and mod versions
phosit replied to roflson's topic in Applications and Contributions
I forgot about it. I accepted it and will merge it tomorrow.- 1 reply
-
- 1
-
-
I'm in favor of XMPP We already have a server. Compared to Matrix it's is wider supported. (more clients) Compared to IRC it supports group chats, it allows async comunication and it doesn't tell everybody when I'm online.
-
Should we go towards less units on screen (but keep similar gameplay)?
phosit replied to BeTe's topic in Gameplay Discussion
That would have more or less the same effect as halfing the popcap. (The other way around: When doubleing the cost player will just increase the popcap. So there is litle difference in unit count) I think it would be better if there is no hard popcap but a penalty for players having many units. -
The x-axis of the right chart is time. The frames are ordered chronologically. The right chart are the frames ordered by time. No I only tested it with multiplayer with a single client that worked. I also get OOS with multiple clients when entering the command during a game. It worked when entering the command during the loadscreen. In a replay the turnlength is the same as in the game it came from.
-
For the first part: Yes it would be good to implement that. There is a ticket: #5323 For the second part: There is also a ticket #3752 Most computation isn't executed every turn (or in a constant turn interval), like a builder deciding what to do when a field is placed. Still some computation does that, like the AI deciding what to do. IIRC An AI only executs each 8th turn. With more frequent turns the constant-turn-interval tasks could be spaced out more. So the average computation is roughtly indipendant of the turn length. Engine things (rendering, network...) Isn't done per turn but per frame. In a cpu intensive game there is a turn every frame. So engine things could be seen as constant-turn-interval tasks. (This entirely refutes my previous argument ) There isn't one magical thing which makes the game run fast (in a single thread (multithreading really is magical (that's a joke magic doesn't exist ))) If you only care about game speed (your complain 1) you want do as few constant-turn-interval tasks. Thus longer turns. If you only care about a responsive UI (your complain 3) you want to do as few sim-things per frame as possible. Thus shorter turns. About your 2. complain: I think in such a situation the fast clients repeatetly have to wait for the slowest client. When a fast client ends it's turn it has to wait's for the slow client to finish the turn. In this time the fast client shows an interpolation (IIRC 5 frames) to the user. When the slowest client is really slow thous 5 frames aren't enough. A solution (which just came to my mind, it isn't elaborate) would be to space thous "interpolation-steps" out, like one interpolation-step each second frame. The interpolation-step / frame ratio should be dynamic to the expected speed of the slowent client. Maby also the interpolation-step count could be dynamic. (I'm just thinking loudly at this point) We head in the direction of decreasing turn length even more: Hosts can already specify the turn length by typing `Engine.SetTurnLength(100);` in to the js console. (yes the feature is hidden) I'd like to see the results of your experiments .
-
There is a fix but there is little activity so i don't think it will be commited soon.