Jump to content

elexis

WFG Retired
 View Profile  See their activity

  • Posts

    3.644

  • Joined

  • Days Won

    59

 Content Type 

Posts posted by elexis

  3. TSL Headshake not Verified

    in Bug reports

    Posted

    Disabling TLS also means disabling encryption, so it would be better fixed.

    You happen to be on Windows 10?

    Did you succeed to connect via TLS (in a23b) before?

    Did you install or configure some networking software (VPN, firewall) (since then)?

  5. Isometric View Option

    in General Discussion

    Posted

    2 hours ago, wowgetoffyourcellphone said:

    I wonder if we can make custom configs into mods somehow. I know we can't currently, but perhaps with some changes.

    When I first saw the fake ISO view I wrote #4638. One can hack such things by replacing default.cfg until the aspired implementation is deployed. (Ideally every mod could introduce custom config options without having to overwrite what exists, so that two mods can be launched simultaneously without breaking.)

    • Like 1

  8. ERROR: JavaScript error: gui/session/input.js line 799 ReferenceError: g_DeveloperOverlay is not defined

    in Help & Feedback

    Posted

    I couldn't reproduce the issue without mods and I don't see in the code how it can fail as it is initialized in the init function.

    As reported on IRC:

    Quote 
    
19:48 < ANYONE@#&#036;%INGTH> bb: I just started a match
19:48 < ANYONE@#&#036;%INGTH> happens in any match I start
19:48 < bb> you have a mod enabled?
19:52 < ANYONE@#&#036;%INGTH> yes
19:53 < ANYONE@#&#036;%INGTH> rise of the east (or whatever its called now)

     

  12. Is alpha 24 coming soon?

    in General Discussion

    Posted

    To answer the question, a lot of the alpha 24 work is in private github branches of different Wildfire Games members for the reason fatherbushido has posted. It's sad to see people decide to try to make Wildfire Games obsolete. I would have wished to continue to cooperate together, but Wildfire Games has a 20 year history, has created this very software and the online platforms and to me this is a value byitself to maintain rather than to actively help tear down. So I have to support Wildfire Games and 0 A.D. at the pice that I will have to pay for that.

    • Like 2

  17. VFS Error while trying to read a file (JavaScript)

    in Game Modification

    Posted

    Wasn't the file truncated to zero bytes and then deleted or something? Like that being two steps that can be affected by concurrency, not only one?

    4 hours ago, ramtzok1 said:

    We dealt with that problem where there was a data race between Python and the game where they both tried to access the same file. We added exceptions handling on the Python side and making sure no other process is using the file.

    I don't think the Python script is related to that problem any more. 

    It does speak of a different process though. And once python opens file access (regardless of exceptions), 0ad can't open that file for that time, no? It sounds like you dealt with the problem where python tries to open it when 0ad has it open already, but not the other way around.

    • Like 1
    • Thanks 1

  19. Could we make catapults less frustrating to use?

    in Gameplay Discussion

    Posted

    6 hours ago, Boudica said:

    To me the ability to cancel packing or unpacking instantly doesn't make sense. The idea is that the packing process takes time. How is it possible to go from a 99% packed catapult to an unpacked one instantly, while from a 100% unpacked it takes a few seconds? So what follows is simple. We only need two icons: one for getting the catapult to a packed state and another for getting it to the unpacked state. If the packing process is in progress, the process just changes the direction as appropriate (0% is packed, 100% unpacked). If all catapults in the selection are in the same state, the icon can be grayed out. 

    Maybe that would be more logical indeed.

    6 hours ago, Boudica said:

    OK, so that was mostly for the UI design. But what is the single thing that makes people lose catapults and rage quit a game? It's the automatic unpacking and the weird behavior when trying to move the catapult. When enemy units get in the range, the catapult starts unpacking. That sounds about right. Except that at this point that process can't really be cancelled by the cancel icon as it just starts all over again instantly (there are still targets in range, right?). You first have to change the unit stance to passive, otherwise the cancel icon is just for frustration. Then you order the catapult to move and what happens? It continues to unpack, just so that it could start packing up again for moving.

    March 2018:

    • rP21630 Fix UnitAI behaviour inconsistent with its stance for packed units and set default stance to standground for packed units.

    April 2018:

    • rP21784 Fix a couple of packing problems from rP21630
    • rP21786 really fix packing problems reported in rP21630

    May 2018:

    October 2018:

    So perhaps the fix to #5091 should be different, I didn't want to get involved with that mudding, but the unpack-loop issue remains reported and is put into the scheduled list #5328 (which means there will be at least three clicks being spent on the issue).

    6 hours ago, Boudica said:

    moving the catapult would mean ordering it to change to a packed state (as explained) with the move command chained

    (Already the case?)

    6 hours ago, Boudica said:

    automatically cancel the ongoing unpacking

    #4015 and D1520 as FeldFeld pointed out.

    5 hours ago, Feldfeld said:

     Edit : Also, when a catapult targets a unit that goes out of range, it will pack and try to follow it, which can be annoying when we intend to use catapult against army, we would just want it to switch target. 

    Standground?

    4 hours ago, Boudica said:

    I'm not sure what your reasons are to keep the cancel command in place.

    Simulation commands are orders. The user sends an order so as to start a process. UnitAI has an order queue and performs that one step at a time. Orders can be cancelled by removing them from the queue. So it's logically consistent with the UnitAI in general, but this packing AI may be unique and warrant some different behavior. Reverting to 0% slowly seems sound to me instead of instantly jumping to 0%, which indeed would justify considering to replace the cancel command with the pack/unpack command, and account for that somehow in the packing part of UnitAI. Sounds like invoking spaghetti code but, maybe inevitable.

    4 hours ago, Feldfeld said:

    Without the cancel i would have to stay frustrated with needing to wait for the catapult to unpack to pack it again

    But that's the weakpoint of siege engines, they should be and remain that vulnerable during that stage, no?

    4 hours ago, Feldfeld said:

    I don't want to have a game 100% realistic in situations like this anyway. 

    Agree, it must be fun to play. That proportional-progress proposal is possibly still the right thing to do, depending on expectations of logic and gameplay design.

    3 hours ago, wraitii said:

    Catapults try following their target when it gets out of range, i.e. automatically packing and then trying to move 

    • This sounds broken to me in all cases
    • We could do it only for forced orders, never on its own for unforced orders.

    For aggressive stance, and for forced attacks in any stance it sounds reasonable to follow the attacked target. I suppose it's important to satisfy the definition of an order. If there is an order to perform X, then by definition X is ordered to be performed, and that means doing the preconditions like packing to achieve that. So one could introduce an order type (such as ground based attacks) where the siege engine attakcs units in the target area without implying that a specific unit should be attacked (thus not providing reason to have it unpack at any time). Dunno.

    7 hours ago, Boudica said:

    I initially decided to write this all up because I was looking for a smaller issue I could work on myself. But I guess some things need to be fixed in the development process first before I could contribute anything? When I first worked on something here, elexis helped me with everything I need. I heard him say that he'd like to invest a lot of his time into the development again. But guess what? He's been incredibly frustrated with the situation that has been around here recently. 

    I don't even know who I'm talking to now. I just wanted to show that there are now more people that want to invest their time to make the game better but they can't. And I had the feeling that there is a lot of useless ego involved in this. Could you just put the ego behind in the name of making the game better? I'd personally be glad if elexis got more power in what gets into the game and if we listen to him more. He has incredible knowledge about the code and he puts great effort into making his contributions the best they can get. People from the player community would probably vote for elexis to become the next project leader. Or I sure would. 

     Please unfrustrate elexis for me and let us work together. 

    Images may vary slightly from actual product. There are many ways to skin a cat. Doesn't require hierarchical force to commit a catapult AI fix. But for my review I need a decision whether I want to be frustrated by throwing or riding the bomb.

    Spoiler

     

    riding_the_bomb.jpg

     

    • Like 1
    • Thanks 3

  20. Alpine Mainland 4v4 - _kali, Lodbrog, nigel87, M.T vs. zoro_, snelius, elexis3, PhyZic

    in Alpha 23

    Posted · Edited by elexis

    As per @snelius request, here the replay of this Alpine Mainland 4v4 today:

    Quote

    zoro_  (1654)

    snelius (1600)

    elexis3 (1180, I only played 3 1v1s)

    PhyZic (1694)

    vs.

    Quote

    _kali

    Lodbrog (1503)

    nigel87 (1582)

    M.T (1807)

    It was a long, balanced and entertaining team game.

    2019-06-17_0002.zip

    screenshot0458.jpg

    Former remains of my city in the center, rebuild and _zoro_s base squeezed together at the top.

    • Thanks 2

  21. Borg Mod Documentation Project

    in Game Modification

    Posted

    The software license relates to redistributing possibly modified copies, the implicit or explicit usage rules enforced by moderators determine what conduct is permissible on the service.

    Performing a review is not necessarily harmful but can be benefitial if it happens in an acceptable or tolerable tone.

    In this specific case, there is the question as to which parts of the mod borg- would not disagree with to have in a24 of Wildfire Games.

    There were some thoughts by online players and even WFG staff members to adopt some of his work (that ought to be the task description if one has a review queue I suppose). From my side hard-counters were a thought I had that should be explored to make the gameplay less linear. borg- did explore that, it's his full right to do so to take it into any way he imagines, and good that he did explore things in general. Also good that he tested it with other human players. The real problem is the interaction between the developer that may have the thought to adopt some of the work and borg- exploring more things before getting one thing into a24 at a time, if he wants to take something into a24. borg- also repeated to me multiple times that multiple changes combined are necessary to actually test this. So I suppose it's really, well, a distributed problem. It's also my problem because I mentioned that I had some interest in seeing that patch, or the explanation of the conditions to having patches submitted for review to Wildfire Games. And the problem of others too who didn't provide borg- the feedback that he could use to become even better at what he is doing. All of that was called review work back in the day. Considering and testing the game with AI players is one of the areas subject to a review. So that particularly isn't bad to have done and reported. The question is really the one about dedication. Should this mod be reviewed for Wildfire Games or not for the purpose of adopting parts of it for Wildfire Games? Then it would meet the primary objectives of the organization, if the tone is acceptable or tolerable. If there is no wish to have the mod reviewed by Wildfire Games, then the claimed purposes of the thread would be less relevant.

    The discussion usually would take place on Phabricator, where a specific coherent feature would be taken out of the mod and analyzed for their impact on the game. If this discussion would be on Phabricator, there at least wouldn't be a discussion as to whether a review of the features makes sense or not. If I had finalized some dedication to a software repository decision we'd also have a different discussion. @Loki1950 say the line!

    • Like 3
×
×
  • Create New...