Crynux

Hmm, interesting points from everyone who's chimed in I think. I think the real question now is, where do we go from here? Personally, given the feedback and notes from everyone in this topic/thread, I'm thinking the following: We need an easy way to communicate things that have been completed, and/or progress on the project; since not all of it is apparent. Balance, somehow, needs to be more accessible to the communty; and changes to balance need to be added to the primary 0ad repo, not a fork. Some level of direction is needed; I'm probably out of the loop, and way off base with this, but it seems that the project is kind-of just "going" ... but not necessarily towards a specific destination. We REALLY somehow need to improve morale in the community ... honestly these posts seem to be quite a downer. We have to get over this rut and move forward with a positive outlook. The community, and internal view of the project very much dictates external impressions; at least in my opinion it does to some degree. If anyone has any adjustments/additions to that list ... please make mention and number them accordingly. Of course, if one of my numbered items there, seems invalid, we can just delete it and consider it not a priority. So now ... I have a proposal! The proposal is ... If you post a problem, post a solution. If you don't have a solution, state how you imagine things would be if the problem was solved; as that would at least give us a destination, but not how to get there. So to practice what I preach ... here's some possible solutions to the points above: Further breakdown project milestones/versions (for example A27) into subprojects. There are a couple options here ... we could have an overarching goal for the milestone (for example, "Refactor rendering to remove nvtt and make way for vulkan support"; completely guessing here lol). Then during A27, the majority of work would be on that. Another option could be to have subprojects for the milestone; for example, Art could have a goal, Balance could have a goal, etc, etc. Then once they're all complete, A{n} is complete. Another possibly better option could be to have alternating milestone focus. So for example, in the case of A27. Maybe A27.0 could be focused on getting balance stuff in (maybe it's only a 1 or 2 week sprint). Then after that A27.1 would focus on non-balance related things. This would give time for the devs to do what they want, while also dedicating some time to balance issues. With solution 1 there ... there are some things that could help this. Alternativelty, if balance is just mostly xml configurations ... there could be some functionality added (idk if it's already there), to allow people to merge balance configurations. So for example, have a balance menu in-game where they could select the xml to load settings from. Then optionally, have an in-game balance vote (for example after a SP or MP game), on what the players thought of the balance. This would give some real feedback on each balance configuration, and differences/implications could be drawn when comparing concrete versions of the settings. It would give balance people and programmers a better technical understanding of what setting influences balance the most, or at least is the most controversial. Direction can come with the solution in point 1. Honestly ... my thought is that having a stream if tickets isn't the best solution for projects goal-wise. It doesn't give a clear outlook of progress (in my opinion). Having smaller goals would give a better sense of completion. Seeing those goals accumulate will give a better sense of success. One idea here would be to adopt something with some kind of project-based progress bars. The visual feedback of it is amazing in my mind. For example, there's this https://github.com/opf/openproject With it you can do progress bars like these: Of course, this is just an example, there's probably other software out there that does the same. Maybe gitlab does this? (just checked, it does, here's a screenshot) Ultimately, if we can have something like this on the homepage, that could be cool too! It could be a point-of-interest for anyone looking at the project ... if they're interested in helping, having current workings, or areas of real need posted publicly would be a benefit; and I think would draw in more people. Part of increasing morale is not to focus on the problems, or negatives, but solutions. That's part of the proposal above, and what I'm trying to do in posting these ideas. I REALLY want to see this project succeed and grow. Part of making that happen is being the change I want to see. So ... that was a bit of a brain dump lol. Thoughts? @Stan`I know (or at least it seems) much of the management side of things is on your shoulders. I'd be happy to help with project management where needed. I'd even go through the trouble of building a project management solution for the team if it's needed (I've honestly wanted to for a while lol ... but never had a specific target in mind); but that might be extreme. On a side note ... personally, I've worked for a few companies in the past years (not boasting or anything, don't take it that way ... I'm just using it as my reference of experience) ... all of which had some critical issues with project management. Unfortunately in my position(s) at the time ... I wasn't able to do much to change the management practices for the better. Here ... I'm starting with throwing out some ideas; if people like it, good, if not ... then we can adjust/delete/create/adapt as needed. To some degree, yes. Too much openness is bad, especially when no-one is declared the final decision maker. This is true in many cases. One that comes to mind (I've been watching a lot of Gordon Ramsay lately lol), is in businesses like hotels, restaurants. With a group of "owners", if there's no-one who has a final say, decisions rot. Part of what Ramsay does is instill a position of power in a single person ... that changes the entire organization, and how it runs as a whole. Maybe having a elected "official" would help the project. Alternatively ... we could also adopt a voting system of sorts, where solutions are presented, and voted on with a deadline within the community. Of course, there's a ton of ways about this. We could also make the project configurable by default. So like ... at any point if there's something that's a core concern, or clear divide in the community ... make a checkbox for it ... then we get BOTH those sides remaining interested, while also satisfying their personal needs/opinions. As always ... everyone please post ideas/feedback, thanks for reading my rambles!

I saw there was a mod menu in the game ... but to be honest I opened it and had no clue how to use it lol, so I closed it. Part of the assumption (which may be a my-bad) that I was making in my response was that, it seems maybe the existing mod loading solution isn't 100% there yet? Idk, just a guess; but it also follows that there's a few sources around here (and in to code too, if I remember correctly from when I was reading yesterday), that seem to indicate there's more work needed. Hmmm ... I just think it's something that has had too much thought put into it tbh. I'm pretty sure it was a topic of discussion when I last dropped in here 3 years ago. It shouldn't take that long to make a decision. I was also under the understanding that many of the devs that left would have preferred the project being on git ... I take that as an insight to the views of possible future contributors. If past devs prefer git (in any adaptation/implementation), then I have a feeling new people would prefer that too. Hmm fair point lol. I just think modern tools are better; especially if anything that's being used is no longer maintained, I'd take it as an opportunity to improve dev experience. I like the breakdown there actually. Thanks for that! Looked up the link there ... it says it only applies to late projects ... this one is in alpha, but has been going on for years lol idk if it's late or not to be honest! That's a lot of balancing, actually a surprising amount lol. I think it falls back to one of the things that every gaming community encounters ... and that is, there's TONS of people with ideas, but only few who know how to actually implement those ideas. Part of my point that maybe I haven't really made yet is that git is more mainstream, or at least seems more mainstream in recent years. For example, in all of my web and software dev jobs in the past ... 7 or so years, everything has been git, or moving to git. Because of that, there's a familiarity with it. If people already know how to use the tools - then the project becomes easier to navigate, therefore easier to contribute to. On github discovery ... I actually have found tons of things on there recently, and way more easily than using a search engine ... since it's focused. There's a lot of awesome- lists out there for every topic. Even programming-language specific, engine-specific, etc. Check it out here for example: https://github.com/topics/awesome-list There's lists like this: https://github.com/awesome-selfhosted/awesome-selfhosted (which may actually be of use for some 0ad self hosting stuff) There's more to github than a UI, it's a matter of preference of course ... but tbh I've never used gitlab, so maybe gitlab has some cool stuff too? Github has sponsors and stuff built in as well ... people can sponsor a project (100% contributions go to the org/dev/team/whatever if I remember correctly). Also I think there's less restrictions on github for open source stuff ... but idk if it's substantial. I forked the mirror yesterday and built from it ... the clone took forever, but I know there's ways around that using git ... so not too worried about it. I hear svn is worse lol. All in all ... I don't mean to argue with anyone or like make anyone's ideas or whatever seem bad. I'm just completely neutrally discussing things. Sometimes intent can be lost in text, and I just want to be clear. Anyways ... I'm pro git. I think too much balance up-front is bad, especially if it's still alpha. IF balance is that much of a concern, then maybe there should be focus on making balance adjustments easier (or built in using options or something), so they can continue as their own "balance module" of sorts. Idk ... just throwing out ideas! I guess (and I think I read this somewhere on here too), some contributors will be focused on balancing. Devs, however, may not care (I know I wouldn't care much ... I like making systems, rather than configuring systems) ... so I think it's possible the balance-focused people feel ignored (just guessing), when really the devs are just doing what they enjoy, which happens to not be changing a few numbers to make a thing work a bit different. If that's the case ... then systems supporting balance changes or configuration independent of compiled code changes may be worth looking at (if this already exists, please ignore me lol), or improving. Ok I'll stop rambling now lol ... Thank again all!

I tend to agree with the speed of it to be honest ... and from what I've heard, there seems to be even less developers on the project today then there was even a few weeks ago. Accelerating game development, in my mind, would be a really good idea. One step towards that goal, would be to increase accessibility of the project. At the moment, the development and source management tools are somewhat archaic; or at least they appear that way to me. (not to mention I think some are just dead? as in the main creator/maintainer no longer creates/maintains them) There seems to be a huge resistance to moving to github, which is unfortunate, but I hear there's another option in the works. To be honest ... I think the project should just use github and move on; the visibility it'd get from it would be priceless. (Having a mirror and requiring people to then take their "patch" and make a request against the main noise ... doesn't fit the use case of improving usability and access to the project). Some sort of package manager type thing would be cool, for mod management. The details of implementation depend entirely on how complicated we get with it ... but to be honest, even a simple zip file with a config/metadata file in it would be suitable. I think the blocker for a proper modloading solution at the moment is decoupling the main "mod" from the game (If I understand correctly, anyone feel free to correct me; I've been away for a while). On a side note, with regard to github resistance ... I honestly don't get what the problem is. So like ... it's an open source project, so they can't really steal the code. In addition ... saying "oh what if they close / delete the repo?" well ... that's what having a proper infrastructure (including backups) helps prevent entirely. If we always have multiple sources of the code ... then we really can't lose it. I honestly think with just a few steps/actions/decisions, this project could skyrocket. The game as it is ... is really great (even though I last played it like 3 years ago lol) ... we just have to do what's best for the project, instead of our own opinions/desires. Of course, people can still work on the project in the way they do currently ... but I believe opening it up to others should be the priority at the moment. If the reason why something like github is opposed, is because they don't want others in the main (0ad/wildfire) codebase, then maybe those people should just fork it and work on it themselves, rather than hold everything back. Or in contrast ... we could just work around possible conflicts, and evolve as a team to having more hands on deck; tbh the forks kill the project. Every fork indicates effort lost on the core of the game, in my mind at least. -My 2 cents ... don't mean to offend anyone at all. This is meant entirely as observations of someone who has been monitoring and/or contributing (minorly) to the project since about 9 years ago (first added a save menu thing lol ... was mostly xml). Thanks!

Hi all, haven't been around here for a while ... just started reading some of these posts; do I smell the need for a modloader? I'd be interested in working on something like that. Edit: Wanted to reply to Stans initial post (parts shortened/made point-form to make this post shorter): I do remember getting a PM/DM at one point ... but I was very much away from the project at that time. I do really appreciate the reach-out though. Thank you a ton for that! In-depth documentation doesn't work in "early" project stages (I know this project has been going on for a while, but it is still alpha, so I consider it early). The best that can be done, is to have clear generalized goals, and build from those once they become realized. That way the design can be done as-needed, rather than up-front when things may change in a week or two (or more). Shadows cause gossip and shut people out. In my mind it should be avoided at all cost, especially with an open community. It can be a difficult thing to do, because first nature is to create a "huddle group" and work with those individuals to fix/advance things. It seems though, that the creation of these groups can cause more harm than good. I would suggest completely transparent communication - and if a decision has been made, or something is stuck, bring that to the community for ideas. Sounds fancy ... but maybe too open. Community involvement needs to be guided, without community guidance, too many suggestions can pile up, and eventually things just stop. There's a number of solutions for this ... mainly thru the use of technology, but it takes some time to get right! Lock it and/or archive it I'd say. Reading the posts here ... it seems like everyone is in their own corner so to speak. Maybe I'm just picking up on the internal strife ... or just reading into things too deeply, but it does seem like there's a problem here. I know I'm just showing up out of the blue (literally googled open source games, a post reminded me of 0ad, and I signed in lol), but I'd be willing to help. I have some ideas on how we can get things moving again, if you're interested. Sounds like a prime time to re-gear so-to-speak, and tackle those nasties with a fresh outlook! As always, feel free to ping me or whatever; yalls have a Discord?

Hello! Thank you for the detailed response. I understand the concerns with an abstraction possibly introducing slowdown, but I do think if done right that slowdown could be minimal to none. Rather than creating an abstraction that forces Vulkan, OpenGL, or whatever else, to conform to it. It'd be best to create the abstraction "conforming" to our 2 or so favorable APIs. So, for example, It'd be created with Vulkan and OpenGL implementations in mind - minimizing the need to create workarounds in each. Where differences exist, some compromises may need to be made. But I think the benefit would be that even with this OpenGL/Vulkan abstraction, anyone else who comes along and would like to develop an implementation of it for some other graphics api, can then just conform to the abstraction spec - and not have to necessarily deal with how to build it into the game engine. If they satisfy the abstraction, then it should work. Either way, I do think some layer between whatever graphics APIs that will be used, and the engine, is important. For one, if we have a standardized interface, with that interface, unittests or function/feature-based performance benchmarks could be possible. So then technically, it would be possible to create a small separate application, that would for example, test one of the implementations in areas such as - rendering 500 units. Or testing the FPS impacts of effects. With these benchmarks you could actually see were each API struggles. In addition, it may provide an opportunity to add some kind of option to the game graphics menu, where it could choose the 'optimal api' for your machine, based on a series of small real-time performance tests (even if just a FPS comparison of a minute or to of each running a similar complex scene). Almost like a benchmark that determines your graphics settings. But with that being said, I do agree that 1a or 1b would be best. Relying on a 3rd party has more risks, even if it may be 'easier' (although sometimes it isn't, because then there's learning that 3rd party api). I also agree that an initial refactor would help greatly. As you say, if we get all the GL code in one spot - then that'll make replacing it simpler. Thanks! -Crynux

Yeah that's fair - "a bit more work", is more like "a lot more work" ... either way though, I think it could be done in steps. The first being making it an abstraction, then once we have a 'concrete' interface or whatever, other implementations would be simpler, as there'd be a better idea of what we need to create. With that being said, there'd need to be some thought into the inputs and outputs of the renderer to some degree (thinking somewhat abstractly here), like building some standard for objects to be passed to the Renderer. That way no matter the implementation - we can provide the same thing and it should be happy. My initial idea was that the renderer implementations could be their own separate thing eventually (maybe thinking too far ahead here). Having for example 'opengl_renderer.so' or 'vulkan_renderer.so', maybe with some version numbers in there as needed. Then the engine could look for the shared objects/dlls/whatever mac uses somehow and load them as-needed, providing a renderer option in the settings (possibly?). I've seen this in other games before... not sure how it was done though... but it's possible lol. I'm always aware of dependencies ... tbh even not knowing too much about the rendering code here, I think we have a really good base. It'd be a waste in my opinion to move away from it. From how it sounds, it just needs a little TLC. Interesting ... I may have to send a message, thanks for the heads-up! Thanks again! Crynux

Hmmm yeah that's true, instancing would help it seems in a lot of cases. I was just thinking that in the meantime, if we could reduce anything to increase render speed, it would help. On that note (models), are there any kind of stats on how many triangles we have per model 'class'? Like is there an average polygon or triangle count for 'normal' units like slingers, or one for 'houses', 'civic-centers', etc? It might be something valuable to have - then we could keep the counts within a certain range based on classification... a 3d resolution for lack of a better term. Yeah lol the case I was looking at specifically were a few archers that just seemed to fling the arrows wherever, they didn't even try... just a pile of arrows on the ground. As for justification - I think it's less the actual decaying, and more the implications of having the decay there. So like, having 230 units, and then killing all 230 units... it's the same amount of polys/tris when alive vs decaying, so there isn't much to be saved there. It's when you have 4 minutes of n units hiding underground, with the next wave of units fighting on top of it - then you get the performance decrease. I guess that could be called replacement rate? The units are replaced faster than they can decay, so it steadily increases unless battle stops entirely ... which usually never happens late game, unless someone gets destroyed. I mean, I like seeing the corpses there ... it makes the game feel more realistic, but I'd rather see no corpses than be playing a slideshow. If anything - I think the idea of having a slider in the Graphics menu or something - to multiply the decay by some factor, manually set the duration, or just disable it entirely, would be of value. On a side note, I just had another thought. Does anyone remember playing older shooters, where you'd shoot a wall for example, and the bullet holes would only 'trail' so far? Maybe we could do something like that - if your unit cap is 200 units, then you should only really be allowed to have 200 or so decaying. Along the same lines, I remember in those shooters as well, when you turned away, and looked back, sometimes the decals on the wall for the bullet holes would disappear. I guess it's a more harsh approach - as you'd only see corpses in-view, but if anything it's a possible (probably not favorable) solution. Thanks again! -Crynux

Hmmm, so there seems to be a bit of an improvement, there's still the usual unit stutter every now and then, but that might be the pathfinding lag. Overall I get a better fps that before it seems, spikes of 100fps, and lower-end values of 40 or so fps in 'populated' areas. I'll have to give it a try tomorrow in an actual game. I haven't taken a look at that mod yet ... I'll do that soon after. On a side note, I noticed in-game there's quite a few arrows on the ground (due to archers and such); so I figured I'd take a look at an arrow mesh to see how many triangles were in it; looking at props/weap_arrow_front.dae in blender, it looks like it has 62 triangles. I'm not a 3d modeling person by any means, but is that high for such a small prop? It just gets me thinking - these slowdowns I'd imagine are a result of the renderer being somewhat outdated, so any triangles we can trim would help. My concern with the arrow is that if you get a good few archers in some area, they can spawn triangles quite quickly. Very interesting. Thanks for the links, skimmed there quickly while writing this response ... but it looks like more justification is needed? Maybe I'll come up with some tests of sorts. Thanks again, Crynux

Interesting, I'll have to give that a try. At the moment I'm testing with the decay rates turned up a bit, and all the same... will see how it performs; large map, 4 AI's, unlimited units.

It does add some degree of lag - mainly in the form of rendering. In my tests, I could be on one side of the map getting 75fps, and on the other where there's a bunch of dead units, I'd get 20fps. So even if pathfinding does contribute to lag in late game, the increased render load due to having to render so many corpses (even when underground?) seems to have a negative effect.

Hi all, so lag has been a topic for a bit. I noticed in my rounds that in the beginning, I usually get around 60fps, with everything maxed. Late game can dip to about 15-20 fps (my most recent game did so; 'normal' map, 2 player vs 2 AI). Anyways, I decided to look into this. First, I went into the scenario editor, and spammed a bunch of houses and units on the map. Opened it up in-game, and there was very little difference. So then, I heard you can 'pit' AI's against each other. So I setup a tiny map, 4 AI's, and let'r rip on 20x. For the most part it was "OK". Then ... I slowed it down, because I noticed the performance dipping. To figure out what was doing this, I zoomed in as far as possible, and moved around the map. I quickly noticed that in the main city-centers of the AI's that weren't attacked, they were getting ~75fps (unlocked). However in the battleground ... it dipped to below 20fps. That made me think - maybe there's something we're not seeing... and that's the unit decay. So after some testing, it looks like the unit decay rate (at least for Slingers [I tested with those units only]) may be too low. The defaults that I can see in the template_unit.xml are as follows: <DelayTime>30.0</DelayTime> <SinkRate>0.01</SinkRate> <SinkAccel>0.0</SinkAccel> In game, a depth is calculated based on some bounding box (I assume unit height? This may be inaccurate as when a unit is 'dead' they're shorter than when standing - not sure if it accounts for that). That number happens to be 3.877156. With that, at a rate of 0.01, and 60fps, it'll take ~3.87 minutes for the unit to decay and be removed (not including the 30 second delay). Taking that into account, for the unit I tested with, to re-create one of them it takes 10 seconds. To create a batch of 5, it takes 30 seconds. So potentially in the time it takes 1 unit to decay, you could have replaced it with 38 - that's if you used only one barracks. With 2+ players and multiple barracks/unit types ... this can become a problem quickly. So my thinking is - in late game, part of the lag is due to all of these 'decaying' units all over the ground, which seems to only increase as time passes. Anyways, is there a reason for such a long decay time? I'm thinking to speed things up - it'd be good to either increase the SinkAccel value, or increase the SinkRate in general. Another option would be to have some code that could dynamically increase the SinkAccel or SinkRate values based on how many units are on the field. On a side note, it may be useful to have a setting in the UI as well, since if it does slow so much as I've seen - then it'd be good to turn it off in some cases, or at least have a manual throttle for it. Thoughts? Thanks in advance, Crynux

Hmmm interesting, thanks for the video link, etc. On the topic of graphics - I did a quick search thru the code for basically gl_ , and there were quite a few hits in many files. There were a ton in Renderer.cpp (as expected), but also a good few elsewhere. With that in mind, looking at Renderer.cpp, there's a lot of direct OpenGL calls; this makes me thing that maybe a first step in 'resolving' the issue of updating the renderer, would be to abstract it. Instead of having the current OpenGL calls directly in Renderer.cpp and friends, the Renderer should be an abstraction or interface, that is then implemented in OpenGL, Vulkan, or whatever else. The benefit to this - is that we'd have one 'set' of functions/calls that we'd have to satisfy whenever it came to supporting a new API. So for example, the existing code could be reworked into a Renderer interface (IRenderer, following the same convention as everything else [tbh I'm just assuming the I there means interface ... please let me know if otherwise]). Then the current OpenGL code could be implemented as OpenGLRenderer or something, and whatever else in their own implementation. The benefits of doing it this way would be: Requirements for the Renderer (thru the interface) would be clear. OpenGL, Vulkan, and whatever else code would be contained in a single location. In theory we could package it so that Renderers are easily changeable. We still have control over the rendering part of the engine. Downsides would be: It's a good bit of work With that in mind, I do see the value in using some other third party rendering stuff - but I think for every third-party dependency added, it provides opportunity for the project to be stuck with no alternative. Say we pick up some library to use for rendering, if that is no longer maintained, then we'd either have to find another, or maintain it ourselves. Which really, only brings us back to the same position. So in my view, I think keeping as much as possible within the project is best - even if a bit more work. Plus we already have a working renderer - even if a little outdated technology-wise. Those are my thoughts anyway... open to counter-arguments/agreements! Thanks, -Crynux

Hello! Thank you for the detailed overview! After digging a bit thru the code today, I did notice the hierarchical pathfinder, and wondered a bit about its use; your post clears that up a bit! I haven't looked much at the AI stuff yet ... but since I'm already into the pathing, maybe I'll stick with that for a bit. I did notice some issue where units would continually try to go somewhere when they can't (for example, having a large group of workers go to an area without formation). They'll just continually pace around trying different angles to get there. I have some ideas on how to fix this ... just haven't gotten to it yet, since I've been working on / getting familiar with path-finding in relation to the extended corner idea. With that, I do recognize those concerns there, more vertices would slow it down, but it maybe a case where having those few extras are better - since if a 'successful' path can be found faster, then overall there 'may' be less computation. That bug you mention seems like it's the same thing I noticed (where they can't get somewhere, but keep trying). Maybe I'll give that a shot next. Aside from that, the OpenGL instancing thing mentioned ... is that just with regard to supporting older versions rather than updating?

Ah, ok cool! I started playing around with VertexPathfinder.cpp ... and came up with this: It's a little modified from the concept above, just extending the corners out, and adding those as extra vertices to be considered in pathfinding. The result, seems to be that units can get to their target a little faster, and actually seem to have access to more sides (that last lady there got a little confused, given she was on the other side of the building to begin with, that's ok I guess... but overall the rest were better I think). I might play around with these changes a little more ... just to see how it affects a long-term game. But from what I can see it looks to be some sort of improvement! What do you guys/gals think? EDIT: I changed how the new points are created, basing it off of the existing buffer based on unit clearance, and a constant. Also created a Diff for it (hopefully it's created decently well) https://code.wildfiregames.com/D1911. Thanks again, Crynux

Hmmm, thanks to everyone for the posts/pointers! I started poking the code, seeing what I can observe that 'may' contribute to slowdown. At first I enabled some code to draw paths - these are commented out by default, so I just commented them and enabled the overlay. From there, I started testing moving units around, and started playing with some 'usual' cases. What I found is that if you have a good few units tasked to an area (say 20 or so workers), and a building is parallel (with respect to it's bounding polygon thing [the blue lines on the overlay]), in some cases you'll get a "unit bounce", where they'll continually bounce around, looking for paths, since there's never a space within the 4 points available (the right two corners of the stone grid polygon, and the left two corners of the storehouse grid polygon). This can be seen here: By contrast if you rotate the building 90 degrees (excuse the rubble, had to try a second time since the first angle wasn't great), the points now being outside of the vertical (relatively) min/max of the right points of the stone, helps the units resolve their paths more quickly, since they can now access the bottom and top sides of the stone. As seen here: This may not cover every case of unit pathing ... but in cases where you get a good few units tasked to an area, and they just happen to line up, I could see how this could cause some slowdown. (sorry if the video too blurry... I made them small clips, and I'm not sure how to make them use their original size on here). With that in mind, I'm thinking a solution to this would be to add some "satellite points" of which the pathfinder could use to resolve the paths more easily around corners; maybe something like this (orange areas are where units would be expected to 'bounce' if no other point of path finding was available): Not sure how 'possible' that would be ... well, I guess anything is possible. But I'm not sure how well that would fit into the existing setup. Just an idea anyways. Thoughts on this? Thanks, Crynux