Jump to content

Atrik

Community Members
  • Posts

    798
  • Joined

  • Days Won

    41

Everything posted by Atrik

  1. https://gitea.wildfiregames.com/0ad/0ad/issues?labels=-24 Here you go
  2. Exactly. For a game overlay, they are the worse thing possible.
  3. If you are referring the @Thalatta's last mock, then the dead space would always be less then current ModernGUI layout (10 slots vs current 12) but it's a bit closer to screen center which might look worse as said above. Your other points I acknowledged them in the last comment, so agreed but you always have to make compromises, goal is to make the best ones. We're back to first exchange : too much clutter, too much space used. The second option is just slightly better enough to make it interesting.
  4. I think I'll consider this proposed layout, I see a some benefits. One of them might be an option to hide it as some players like myself already know each unit command hotkey. I also like that you get 10 slots for unit commands which is the exact number to not have any overflow for single-type selection even including new capture button (the 10th is "back to work") but doesn't have much dead space. The overflow in multi-type selection (worker + building) will overflow but that's somewhat fine, not worth adding space for this. About the construction panel layout, it's not worth pursuing your attempt to order building, in my opinion. Due to the fact that the list of construction is very variable : across civs, mods easily add some, and in a multi-type selection (if any of the selection is a trainer, a researcher or can be upgraded) then you cannot keep the ordering. Also on your mock the order isn't even done by any entity classes that would make it possible.
  5. I like the gain in clarity and the attempt to normalize panel's heights. There are a couple reasons why I still couldn't go for this. Lateral space is already scarce in ModernGUI if you don't have a big screen Although your suggestion takes as much total space as what's implemented in the mod, it adds the clutter a bit more to the center of the screen. For users that use hotkeys for unit action anyways, or at least for myself, this is not desirable (maybe it's just something you could get used too idk) Contrary to what you say, the placement is logical. All possible actions are on the right side, all attribute-like options on the left (formation stance..) Currently the single selection detail panel wouldn't be able to shrink down height without losing something. You are basically saying the wording "turret point" is confusing but you aren't suggesting anything.
  6. Have to say you are right. Hardly a bug. But it's confusing game-play choice (in fact, just a left-over from old wall towers being able to shoot). I have a pending patch were I replace garrison for turret points on wall towers.
  7. The absence of a bug is generally less noticeable then when it's here
  8. Vanilla UI doesn't have space to display all unit action button, so it doesn't show it. You can use the hotkey as an alternative. I can also recommend using ModernGUI as others and myself contributed to fixing bugs and limitations of the game UI. There are at least 100+ bug fixs like this in the mod. You can also choose to wait a few decades for them to be addressed in vanilla (no sarcasm, just a extrapolation of the time to get one item merged), staff and contributors do whatever they can to make it happen but the process is slow by nature.
  9. Yes it does, but in the videos, this opposite force is just not applied as it should, so the effect is less then its supposed to be.
  10. So for the explanation again, we could now plug any force that could contribute to unit motion and we just sum up the vectors. So it's almost free there, when calculating unit motion. Maybe excepted we still have to check for collisions. The rest of what makes the unit motion looks realistic is inertia, which is also just a ""force"" vector that carry unit velocity over the game turns. Calculating the forces themselves is generally making some dot products and sometimes maybe some trigonometry (kept as minimum for angle of impact etc) so also possible to be kept very cheap. For the current demo of the boat we use 1 trig function which seems reasonable.
  11. Atrik

    Mod request.

    So much quality content about this topic
  12. It does in the video, but there are reasons why it end up just slightly slowing down the attacker. Now taking a step back from what I did empirically and reading the comments, I might just rethink some aspects that would address some defects like this one. Would be very nice, yes more realistic movements and collisions would make a boarding mechanic interesting.
  13. We use one trigonometric function to determine the hit angle and deduct the amount transferred as angular velocity and add the force to right direction. It's a really nice suggestion that I like, I don't know how animating "choppy oceanic water", it would require to implement a terrain-dependent bonus or effects, then adding the force would be easy now. However i like it, not sure about what would be the timeline to even have the features enabling this.
  14. Noted but for the videos, the unit template parameters are for the "demo". The balancing of it all will be a task on it's own , my focus at the moment is to put the features out there as most of them would be optional (so disabled/absent from unit motion). It could be possible with not too much work on the code side, now that a lot of the structure is already there. But it also require a proper animation, else would look too weird. So that's for another time.. You can note that the boat receiving the blow in the video almost seems animated here but really it's just "hacked" with some rolling motion.
  15. These are videos from a current work in progress to implement different forces into unit motions, like inertia, knockbacks and charge attacks! The values would be very customizable in unit templates for mods too! Screencast+from+2026-06-04+23-57-24.webm Screencast+from+2026-06-18+18-01-22.webm Screencast+from+2026-06-18+17-53-13.webm
  16. But how does that look in 64px?
  17. @AmericanDream7, @Akentas, sorry you guys had to face this. Indeed you should not hesitate to mute and ban from your games, players that seemingly just want to harm. In most cases they, themselves believe you did something wrong and their answer is to be toxic, which is obviously them not being reasonable. For my take on this, I certainly don't want to push toward having more policing, but we should work toward having more efficient tools to blacklist-whitlist players. (See this opened ticked)
  18. Best would be to add a poll to the thread @Baelish
  19. Pretty important info you forgot to mention is how to config. For example instead of local rating weight i wanted to use openSkill so i had to change this in config: localratings.general.ratingsystem = "openSkill"
  20. If you don't have it yet @Emacz you can try update ModernGUI to display the capture rates of buildings in tooltip. Yes
  21. Using @ffm2 last upload, I've added fixes for : Minimap expand should now works as expected Should open lobby page and return to gamesetup without issues GUI scaling for the stat overlay should now work (probably that was your issue @SadRdz) KDR display fixed autociv.zip
  22. Thanks @ffm2 for working on this. No, the StatisticsTracker works correctly, as you could attest for being able to see kills in the summary. The problem is in GuiInterface where autociv tries to use the depreciated unitsLost.total stat. But it have been renamed unitsLost.Unit. I already had this very bug fixed when I ported autociv back then for A27, but it got lost somehow.
  23. Atrik

    OOS report.

    ok for reasons the oos_dump i have isn't the lastest one I experienced with you @ffm2. Mine OOS turn 142 so idk why. I opened the dump just after the game and no other OOS happened. No clue wtf, sorry we'll need to have another shot to make proper compare.
×
×
  • Create New...