Jump to content

hyperion

Community Members
  • Posts

    894
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by hyperion

  1. An enet package might be much larger than the MTU, then fragmentation is done based on MTU of both peers (server/client).

    11 hours ago, Norse_Harold said:

    We can iterate through all of the elements of the m_Host->peers array and adjust the MTU before the peer structures are used for actual connections.

    That would be futile as it won't update the MTU on the side of the peer.

    11 hours ago, Norse_Harold said:

    longsentenceasname, who was unable to stay connected in the past was able to stay connected and play a complete team game hosted by me

    Given the information in this thread so far the issue is not on your end, but you can ofc fix the issue on the other end if it's mtu related by lowering your enet mtu at the cost of possibly making all other connections less efficient at the same time.

     

    Attached a cleaner patch without sanity checks that allows setting mtu in config or via command line, ie. pyrogenesis -conf=network.mtu:1392

    Anyway not yet convinced that this is the actual issue, yes might be, but still waiting for the output of the original ping command from @Helicity to confirm.

    enet-mtu.patch

    • Thanks 1
  2. 6 minutes ago, Norse_Harold said:

    Someone else will have to help with that test, because if I ping myself then it just sends the packets over the loopback adapter.

    Well, you could ping play0ad or whoever instead with the above arguments. In case you are the bottleneck this would suffice. 1400 should work with a vpn but yours might cut it further than strictly required.

    11 minutes ago, Norse_Harold said:

    My VPN interface has MTU 1420 bytes on wire.

    Meaning "ping -M do -s 1392 play0ad.com" succeeds.  If so there is supposed to be no issue on your end and the enet default of 1400.

     

    11 minutes ago, Norse_Harold said:

    I want ENet to use a lower MTU, such as 1392 data bytes.

    You shouldn't unless required but if you want, there is no config in 0ad so you have to patch the code. Just set it right after enet_host_create on the returned struct, then let it run as usual.

    • Thanks 1
  3. 1 hour ago, maroder said:

    No, that part was relatively clear to me, I'm rather thinking about how to handle the sub-menus. I.e would you want them just on the right hand side as it is the case with the current menu? Because that would look a bit unbalanced imo.

    On the other hand, one could possibly still have a drop-down, that just overlays the button beneath it. Not quite sure how that would look like.

    To the right, maybe a different page would make sense as well. Covering existing buttons I'd say is bad practice.

    • Like 1
  4. 1 hour ago, Stan` said:

    Yeah Titles are a bit dangerous for me, for its extra moderation. Some of the matches name in the mp lobby are pretty bad.

    Not sure how I'm gonna tackle tags though. I was thinking of doing it through the interface with a curated list one could choose from

    A somewhat valid concern. Using the match title in the lobby is unsuitable as likely you want to name it after the game and it should also support single-player matches. For tags I'd go with free form first. If it becomes an issues it's still not to late to not show them or even filter them using the service.

    Also you haven't mentioned GDPR yet :)

     

  5. On 19/02/2023 at 4:26 PM, maroder said:

    Should be possible with some extra work (one would need to implement a specific timer first) but I agree with @vv221 that this might be a bit too much.

    The only reason I see to use more than one background is one can't bear to remove the others. It's certainly better to stick to one from an UX point of view and change it only on new release.

    ---

    As for vertical orientation of main buttons, I'd place them roughly where Athena upper body is in the above screenshot, just in case you are still brooding this question.

  6. 1 hour ago, sternstaub said:

    ?

    42 ... , well this question doesn't have enough meat for me to answer. :)

     

    1 hour ago, Stan` said:

    As long as you have the commands.txt it's fine. I just assume one commands per subfolder. 

    That's because the game creates folders like that. 

    Commands.txt have a unique MatchId, which is shown on one of the screenshot, you can turn the timestamp into a date aswell.

    Gamenumber doesn't really make much sense since it depends on the machine.

    Well, I only have ever seen 2 users generating replay archives indicating they are aware of the specifics involved and so making it possible for others to just unpack those. (I'm only talking about solving the sharing of replays P2P via forum, mail etc without any dedicated service here)

    Developing a service in tandem or first may not be bad tho, as it may highlight additional requirements (title and tags were mentioned already) for a potential pyroreplay format.

  7. 14 minutes ago, Stan` said:

    Well MatchId is supposed to be unique. If that proves to not be enough we can add the timestamp.

    Not using the service but the current approach of zipping and unzipping with "date-gamenumber". Also people use arbitrary root, wonder whether they need metadata.json and so on.

     

    18 minutes ago, Stan` said:

    Yeah export would be nice inside the game but adding something to save files anywhere from JS is a can of worms I suppose. Same as exposing a curl api.

    Those things would have to be done by the engine (c++) ofc. The UI just calls into the engine.

     

    10 minutes ago, sternstaub said:

    Would it not be possible to link the replay folder to a visible location like ~ at some point, maybe on game start or installation?

    You can simply create a symlink to the replay directory at any time, no need for the engine to know about it at all.

  8. On 27/02/2023 at 6:34 PM, Genava55 said:

    There is a huge gap in the required skill between simulating a disconnection and extracting compiled information from JS

    Autociv or @Yekaterina own gui mod are "exploits" on another level as they give even more advantage than this disconnect trick to see stats in competitive play. About disconnect, whether intentional or not, the important bit is to communicate to fix you network if you have issues. In the maybe 200 to 300 games I played over network I have yet to see this issue even once. So the attitude of it's normal to have such issues bugs me.

  9. One of the things I had in my mind as nice to have. Just I'd start with an export / import replay feature in-game. There are many who struggle with exporting manually and we see formats like 7z, rar and what not. Also there are possible file collisions with this approach. So having a standardized replay file format (pyroreplay ?) taking care of all such nuisances would already much improve the replay sharing situation. Once in place this format would then be the basis of such a service.

  10. 50 minutes ago, MarcusAureliu#s said:

    Especially when it comes to pausing this should clearly be a bug ???

    Of course, but that's not what happens with vanilla 0ad. I can't reproduce it. The stats are only ever shown if the game is considered finished. It's trivial enough to change the code to always show it if people want to cheat.

    About connection issues, the threads listed by @Genava55, we have driver bug and powersave issues. Anyone playing competitively is expected to fix or workaround such issues. In fact everyone who drops every ten minutes and isn't inclined to fix it is an annoyance for other players. So yuo may call it sarcastic, but for me this belongs into the realm of netiquette.  

  11. 1 hour ago, Yekaterina said:

    I think not, because it could be a technical error, e.g. program crash, network problems etc. No one wanted to quit at this point, and the player who disconnected wants to come back and finish the game. But having this summary menu unintentionally benefits the player who disconnected, even if they don't know about the exploit or isn't willing to use it. 

    It's fine to continue to play a game that is considered 'finished' for the fun of it but the rating points should be issued based on when the game was considered 'finished' first time.

    PS: Just a guess, technical error, e.g. program crash, network problems etc would be come a lot rarer if they wouldn't help avoiding point loss ;)

    • Like 1
  12. 3 hours ago, sternstaub said:

    Right, of course, the backend.@farima4if you are on an old machine, you might also want to test it out with the new alpha (A27, but it is still pre-release) for vulkan backend

    If it's really old hardware as stated Vulkan won't be available, and the userreport_hwdetect indeed suggests this to be the case.

    • Thanks 1
  13. 10 hours ago, Stan` said:

    Not just us but other to have trouble making a decent mod interface as well :)

    Anyway, I had in mind things like loading the correct mods on joining a game / starting a replay, fetching mods or fetching content from host on demand etc. All those perks I see as a requirement for splitting mods as one pleases. That isn't trivial and also touches on the topic of security.

    Having the editor mod only depend on mod mod is probably the right choice.

  14. 9 hours ago, sternstaub said:

    1) pyro engine - game logic.

    The game logic isn't meant to be part of the engine, sure the engine sets some limits as to what a game can do and the engine can offer some routines for some performance critical aspect to be handed off as well.

    As for 0ad aka public, sure splitting off or splitting the mod itself (a la 2-4) might make sense if there where a better dependency/mod loader, see the mess the community mod created.

    The all as a block situation isn't ideal for people to get started.

×
×
  • Create New...