Jump to content

Imarok

WFG Programming Team
 View Profile  See their activity

  • Posts

    992

  • Joined

  • Last visited

  • Days Won

    5

 Content Type 

Posts posted by Imarok

  8. ==[REQUEST] == Seeding animation

    in Art Development

    Posted

    29 minutes ago, Stan` said:

    @Imarok Thanks.

    It would seem that the current variants use 'Build_farm' instead of 'seed'. If you change that in the code and apply the following diff it should work.

      

    
Index: binaries/data/mods/public/art/variants/biped/build_farm.xml
===================================================================
--- binaries/data/mods/public/art/variants/biped/build_farm.xml	(revision 22869)
+++ binaries/data/mods/public/art/variants/biped/build_farm.xml	(working copy)
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <variant name="Build_farm">
   <animations>
-    <animation event="0.5" file="biped/citizen/build.dae" name="Build_farm" speed="100"/>
+    <animation event="0.5" file="biped/gatherer/seeding.dae " name="Build_farm" speed="100"/>
   </animations>
   <props>
     <prop attachpoint="shield"/>
Index: binaries/data/mods/public/art/variants/biped/female_build_farm.xml
===================================================================
--- binaries/data/mods/public/art/variants/biped/female_build_farm.xml	(revision 22869)
+++ binaries/data/mods/public/art/variants/biped/female_build_farm.xml	(working copy)
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <variant name="Build_farm">
   <animations>
-    <animation event="0.75" file="biped/citizen/build.dae" name="Build_farm" speed="70"/>
+    <animation event="0.5" file="biped/gatherer/seeding.dae " name="Build_farm" speed="100"/>
   </animations>
   <props>
     <prop attachpoint="weapon_L"/>

     

    That works, but it doesn't resolve the elephant issue.
    I guess they need a separate variant file.

    Edit: And I guess they aren't supposed to seed with a mallet in their hands, aren't they?

    • Haha 1

  9. ==[REQUEST] == Seeding animation

    in Art Development

    Posted

    1 hour ago, Stan` said:

    Add the code i'll make the variant :) 

    Index: binaries/data/mods/public/simulation/components/UnitAI.js
===================================================================
--- binaries/data/mods/public/simulation/components/UnitAI.js	(Revision 22862)
+++ binaries/data/mods/public/simulation/components/UnitAI.js	(Arbeitskopie)
@@ -2719,7 +2719,9 @@
 
 					this.FaceTowardsTarget(this.order.data.target);
 
-					this.SelectAnimation("build");
+					let cmpIdentity = Engine.QueryInterface(this.order.data.target, IID_Identity);
+
+					this.SelectAnimation(cmpIdentity && cmpIdentity.HasClass("Field") ? "seed" : "build");
 					this.StartTimer(1000, 1000);
 					return false;
 				},

    But this doesn't consider the elephant worker issue. And not sure if the name of the animation fits our schema ;)

  13. Why not moving to Git?

    in Game Development & Technical Discussion

    Posted

    6 hours ago, Andrettin said:

    GH is controlled by a private company, but AFAIK given how git works (your local copy has the entire repository information) that is not an issue, since if they change their policies to something intolerable, you can just move the repository to be hosted somewhere else.

    Yep, the repository itself can always be easily migrated. But we already offer a repository on github...

     

    6 hours ago, Andrettin said:

    I think it would be advantageous to host it in GitHub, considering the excellent UI it possesses (both in the desktop and web versions), which IMO makes development much more convenient.

    As said we already host a mirror of our repository on GH. But I guess you mean we should also use the "sugar" GH offers besides only hosting a git repo: pull requests, issues, CI, etc.
    But there we come back to your first point: all that "sugar" can't be easily migrated if GH(or M$) changes policy because those "sugar" isn't part of git.

    5 hours ago, Trinketos said:

    Where the source code of the svn version is hosted? 

    https://trac.wildfiregames.com/wiki/BuildInstructions#Acquiringthecode

    • Like 1

  14. Why not moving to Git?

    in Game Development & Technical Discussion

    Posted

    On 7/20/2019 at 8:08 AM, Andrettin said:

    Well, yes, but by making contributing less convenient (e.g. by not taking GitHub pull requests) then you turn away potential contributors.

    So you are talking about a specific platform now?

    You can use git without using github...
    (And afaik you can also use phabricator together with our github mirror)

  15. Sunday Pro Games League Fixture

    in Help & Feedback

    Posted

    On 5/6/2019 at 11:32 AM, Boudica said:

    We could probably extract the time of a resource share event from the replay file easily, but it could be more accurate to weight by the average economy strength or value of each resource at the given time. To get the whole context, it's probably better to just run the replay with some event hooks that update the score.

    The metadata.json contains a record of all scores (and kills etc.)  for about every 30 seconds of the game. So no need to rerun the replay. ;)

    • Like 1

  16. AI, Pathfinding and Performance

    in Game Development & Technical Discussion

    Posted

    7 hours ago, Crynux said:

    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:

    1. Requirements for the Renderer (thru the interface) would be clear.
    2. OpenGL, Vulkan, and whatever else code would be contained in a single location.
    3. In theory we could package it so that Renderers are easily changeable.
    4. We still have control over the rendering part of the engine.

    Downsides would be:

    1. 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

     

    I think that is exactly what @vladislavbelov is planning. :)

    Maybe he can need some help?

    • Thanks 1

  18. AI, Pathfinding and Performance

    in Game Development & Technical Discussion

    Posted

    12 hours ago, Stan` said:

     

    14 hours ago, Crynux said:

    On a side note, with conversion of some of the JS ai code to C++, has any design or some other outline of what 'needs' to be in JS vs C++ been outlined? I think it'd be valuable to set some rules or guidelines as to how much should be available in JS. To be honest, I don't have very much experience with AI programming, but at a glance, I believe any of the heavier computations should be strictly implemented in C++. An AI should really only contain decision logic... (I haven't looked thru the Petra code yet so if this is already the case, that's awesome!).

    I don't think there is such a plan. The AI was made JavaScript for moddability :) 

    Afaik everything that is too performance heavy in js should be done in c++ if it doesn't hinder moddability too much.

    • Thanks 1

  25. ===[COMMITTED]=== Persian Unit Texture Upgrade

    in Completed Art Tasks

    Posted

    3 hours ago, Sundiata said:

    I think the highly saturated player colour all over the place works well for games like Empires Apart, which is much more stylized and orientated towards fantasy-history, but it doesn't work so well for a game like 0AD that achieves a relatively high degree of visual "realism" for a game of this specific type.

    Visual "realism" is good but it's for the bin if you don't see ata glance to which player a unit belongs. 0ad is still a game and not a history simulation. (Of course we should aim for the best historical accuracy. But only as long as it doesn't hinder the gameplay too much)

    I know the view on this issue also heavily depends on whether you are more a competitive player or a casual. (Maybe we should just have an option to switch between two variatons: One with 100% accurate textures and one with accurate textures and distinguishable player color. Will be much effort and not sure how easy to implement ;))

    • Like 5
×
×
  • Create New...