WFG Programming Team
  • Content count

  • Joined

  • Last visited

Community Reputation

630 Excellent

1 Follower

About wraitii

  • Rank
    Space Poodle

Profile Information

  • Gender

Recent Profile Visitors

1,034 profile views
  1. The fundamental problem is that our civilisations don't have enough units, on the whole, since not all of them have a basic spearman or a basic swordsman (and it gets worse when you consider champions).
  2. You still should reduce the water waviness Regarding the lag, it's not "normal", but it's to be expected for such a map. Sadly our engine is currently not very optimised for rendering a lot of objects, since it doesn't use a technique called instancing. This means that beyond a certain number of objects, even powerful laptops will start lagging. Furthermore, the gameplay itself is not as fast as it could be and on a large map with a lot of objects and 5 AI player, lag is currently qui unavoidable.
  3. Definitely graphics related. Are your drivers up to date?
  4. Yeah, fixed too.
  5. You're referring to the fact that units sometimes glide at the very end of their movement? If so yes it's a bug, and it's fixed/it will be fixed in my ongoing UnitMotion rewrite which will land whenever.
  6. You're correct afaik. I think we could also use a sphere/elipsoid bounding box, which would probably be best for a building such as this.
  7. I can confirm that I have the bug fixed on my end, I'm just waiting for a formal report from someone on Windows and *nix that it works and that nothing is obviously broken, and then I can commit it. I need to check for repackaging options. There might be an easy-isa option, or I'll need to repackage the whole thing.
  8. Regarding code and bridges: I actually believe a walkable mesh would be far easier to do than changing terrain. Changing terrain sports a number of drawbacks which I am very reluctant to get into. A walkable mesh would imply a new component, and tight integration to the pathfinder, but in itself nothing there sounds impossible, and would in theory allow ships and units. Since we cache the obstruction maps, nothing there is insane so long as the update isn't too difficult. We could also add gates to their sides and stuff. It would be a little slower, but it wouldn't be by that much. However, the pathfinding problems of gates still apply: closed bridges currently would be seen as utterly impassable. The feature is also not really that interesting, since most bridges won't be high enough to let ships through. Have to agree with draw bridges there (though how realistic are those for the time period?). I generally don't see handling height as relevant, that would just add passability classes for a super special case which is annoying.
  9. That is "normal", passable terrain is defined by the slope of the terrain and not the terrain texture - contrarily to most other RTS games (and to be honest maybe we should change it). In that case probably you are going over some impassable terrain with your wall.
  10. Hm, the water settings you posted above are good. I notice some artifacts in the reflections though. What map-specific settings do you use? Water waviness? Water type? This map looks like it would benefit from much smaller waviness and water type "lake" or "clap".
  11. Are you running the water on highest settings?
  12. How about "Vox Populi"? Kind of fits the FLOSS world.
  13. My chauvinism forces me to suggest Vercingétorix
  14. Hm, you guys were right, the code was completely bonkers. I should have fixed it by now, let me know after the auto build if you find bugs New format if you want props to sync with a main actor: <animations> <animation file="infantry/general/inf_02.psa" name="Death" id="death1" speed="250"/> <animation file="infantry/general/inf_03.psa" name="Death" id="anotherdeath" speed="250"/> <!-- ... --> </animations> To clarify: -no need to use named variants, just put all your animations inside one <animations> block. -"name" now must refer to an animation type (e.g. "walk", "death", "idle"). -You can use frequencies as before. -"id" is now the parameter used to sync across props. If an animation has an ID, all props will try using an animation with the same name and ID. You may have several animations with the same ID. I'll try adding tests for this later because it's quite annoying to check manually.
  15. Hey, thanks for your interest! This is planned, but it's not as easy as you'd think. That actually sounds like a pretty good idea. We've been thinking about this a little more, but I don't see big changes coming. We have been quite unable to figure out how to implement formations. Don't expect too much on that angle for now. This would be possible but there's a few limits: -size of the Javascript memory - some maps already run into this, I've been thinking about making it configurable for people that want more. -it would lag horribly. I don't think we can go realistically beyond 200/300 units because it would become unmanageable for the player.