maroder

considering performance I think its not a good idea to attach an aura to every single unit. the other values could of course be tweaked.

really nice layout to introduce the new version congrats It sounds great and I will certainly test it when I have time.

Yes causal players are very much underrepresented here. But even if they would voice their opinions more publicly, the question is still if it is possible to find a balance between what causal players want and what competitive players want. Turn rates/ acceleration is just the tip of the iceberg.

Guess the problem is also that any balancing discussions only makes sense if the people actually test the development version. Discussing balance based on the last release is mostly obsolete and /or misleading.

I don't mind acceleration in general, but the problem is that the current pathfinding of large units and formations doesn't fit well to it. Large units are frequently obstructed by other units and have to stop and turn around and accelerate again and are obstructed again and have to stop... ect. For me, this makes them more annoying to navigate. This could however be mitigated if unit pushing would also include standing units, so that larger (heavier) units could just push obstructions away. And it's a similar story for acceleration and formations. If they would have a smoother movement and would shift less, the acceleration wouldn't be an issue for me.

One might also want to read the discussion/ watch the videos on the commit https://code.wildfiregames.com/rP25953

https://trac.wildfiregames.com/ticket/6189 @mysticjim

a bit too complicated to do this just for one map I guess

Sure, but on the other side you have the player being closest to the enemy which is also an disadvantage. And since its an equal disadvantage between the two teams I think it's alright. (But I also don't feel that strongly about it)

And that you have to use a formation. It doesn't work when not in a formation.

Idk. I guess I would have to try it out to find out how it works) fits into the game.

kind of like in real life I would say. And you can attack them with ranged units while they retreat.

just some ideas: they could stay in formation, but only the soilders from the formation can attack that are in range of the enemy. They get an increase in armor, but also a slower movent speed. For the testudo: makes the formation invulnerable to pierce damage, but they canot attack

I'm skeptical that with the small multiplayer base you would get anywhere near 1000 in donation and even if you did I'm not sure if this would be the best purpose of use. Secondly you have to keep in mind that the game is not really cheat proof. There are ways to get an unfair advantage that are not detectable and such an high prize money would just be an incentive for people with bad intentions.

@Stan` I guess this does not really belong in Announcements/News

I know, I just thought I chime in on the positive side of such a (possible) migration. Whether we like it or not, the non-opensource, big company owned GitHub is right now the largest source code host, both in terms of projects and active users. Which means that it's the place with the lowest barrier of entry for new contributors. Sure a self hosted Gitlab is also an option, but having a place to discuss tickets/ enhancements / code ect, where I guess most of the developers these days already have an account also has major benefits.

just switching to a wider known and used platform like github may already lead to an increase in visibility (And by that I mean active development there, not just a mirror). Very good article about the growth of Node.js : https://opensource.com/life/16/5/growing-contributor-base-modern-open-source And of course: going beta so people don't mistakenly underestimate how good the game already is

I think it defenitly plays a role to some degree, but I posted already enough videos feel free to investigate further tho.

did not test

And the other question is: would it really need a complete rewrite? From what I saw I would say that that the problematic part is the unit death / attacking combination and not all of the attacking routine. But I also would really like to hear what conclusions other people draw from the videos

Yeah, rewriting all that seems like a huge project, so I get that part of the argument, but personally I don't think the modability factor should play a role here (and I like to make mods). The question is who wants to mod a game that is not functioning correctly? not doing optimization only because someday someone might want to change it seems to me like a bad tradeoff. If there are ways to optimize the javascript part that should of course be preferred, but if the only way to fix that would be to reduce some of the modability, then that is the sacrifice that has to be done (imo).

I updated the post What I would conclude from all that (no guarantee on correctness) is that the main reason for lag (at least for me) is the overkill factor. So the engine seems to dislike it if the health of a unit is so much reduced that it dies, but there are still other attacks incoming, which are now targeting an entity that is already dead. And this happens much more often when ranged units attack vs when melee units attack. All other parts, be it graphics, short and long range pathfinder ect, seem not too bad from these tests.

Hey all, mostly out of curiosity I tried to simulate a few different scenarios to find out what parts of the code contribute the most to the lag and should be considered first for future optimizations. All this was tested with svn rev 25963 and about 500 to 600 units for each test. TLDR: Most of the things I tested worked better than I thought, but the main problem on my system seems to be unit death (and potentially overkill) and range queries of attacks and especially of missed projectiles. Also: the current AI implementation: See https://code.wildfiregames.com/D3769 _____________________________________________________________________________________________ 1st test: long range pathfinding with one type of unit result for me: not that bad actually very little lag 1/10 one_type.mp4 ---------------------------------------------------- 2nd test: long range pathfinding with multiple unit types (graphic influence) result for me: also good, very little lag 1/10 multiple_types.mp4 ---------------------------------------------------- test 3: melee combat with 600 units | result for me: noticeable lag 7/10 melee.mp4 ---------------------------------------------------- test 4: ranged combat with 600 units result for me: without having a good measurement I would say the most lag so far 10/10 ranged.mp4 ---------------------------------------------------- test 5: ranged combat with 600 units but emphasis on the projectile calculation result for me: nearly no lag 1/10 shooting.mp4 ---------------------------------------------------- test 6: ranged combat with 600 units but emphasis on the overkill factor result for me: huge lag 10/10 overkill.mp4 ---------------------------------------------------- test 7: gathering & short pathfinding result for me: nearly no lag 1/10 gather.mp4 ---------------------------------------------------- test 8: BuildingAI result for me: nothing 0/10 building.mp4 To gather all the information of this thread in one place: see explanation by @wraitii to why this may be:

I can't find anything in the mod.io docs about such an error https://docs.mod.io/#error-codes

Iirc the problems for them are mostly red and green. So yellow should be fine Edit: No they aren't. Here is a tool to simulate colorblindness: http://hclwizard.org:3000/cvdemulator/ But they actually already have an hard time between the red "you can't afford that" buttons and the green "this is produced" buttons Mhh not sure how to fix this.