Leaderboard

I put slinger anims in the title, but its just the one in Balearic style. Not quite sure where these go just yet, it doesn't look like the new meshes are in until we complete the animation roster. I want to get all different styles for different cultures because that would be awesome, but that will probably take a lot of time. Have a go, then

Oh, there's an easy way to take the rotation that will have in the game into account while you're on blender!! -Select the sling armature, go to the "constraints" tab. -Add constraints of "Copy Location" and "Copy Rotation" -Select the UNIT ARMATURE as the target, and choose the Bone that you want the sling to be "spawn on" (literally, is like prop-pointing in blender) This example is how the head is propped in blender: -Finally just animate both at the same time (the unit and the sling), and when you're done and ready to export, just remove the constraints and it will "snap" back to it's origin point, ready to get exported

Working with this blend file is fantastic, all the handles cooperate and everything! I'll definitely be jumping on the animation wagon every once in a while. Brilliant work Enrique

I want to talk about some problems with pathfinding for large armies and proposed solutions. I would implement these solutions and submit a patch. If you have a big group of units gathered together with no formation, and select them and click for them to move somewhere across the map (or even relatively nearby), two things happen. The units in front start moving immediately, but it takes a long time before the entire group is moving. The group narrows into a single-file column as each unit tries to follow exactly along the planned long-range path. Neither of these things is what the player wants. The army would get to the destination faster if every unit started moving immediately, and it would be more effective once the fighting starts if it stayed together as a clump. The more spread out the army is, the more vulnerable it is. I want to pause here and say that I don't intend to do anything with formations. These changes can be accomplished through individual unit pathfinding alone. I want to compare this to other RTS games such as Starcraft II. In Starcraft II, if you have a clump of units and tell them to move, the entire clump instantly start moving, and stays together as a clump. You can see examples of Starcraft II pathfinding here: https://www.youtube.com/watch?v=x0gSVKVZ4YU. Throughout the video, notice how units stay in tight groups, even as they move around and change direction a lot. If they split up, that's generally because the player manually split them up by telling part of the group to go one way and another part to go another way. Starcraft II has no formations. So how can 0ad work like this? I plan on the following changes. For reference, this is the current pathfinder doc: http://trac.wildfiregames.com/browser/ps/trunk/docs/pathfinder.pdf Add additional information to units giving their expected direction. This is a vector saying where and how fast the unit is probably going to move in the next turn. It doesn't have to be perfect. If you give a unit a walk order, its expected direction would be immediately set to be parallel to the long-range path to the destination. Otherwise, a unit's expected direction would be set to the direction it moved in the previous turn. This information would only be updated once per turn. For the purpose of short-range pathfinding, units ignore units whose expected direction would move away from them fast enough that there is no expected collision during the next turn. This should solve the issue where it takes a long time for a group to get moving because of units treating units in front of them as obstructions. As a side benefit, this would improve performance because the short-range pathfinder would have fewer edges to consider!! After short-range paths have been selected for units, units with short-range paths that are nearly parallel to allied units adjacent to them, should have their paths adjusted to be exactly parallel. This would prevent units from converging into a single-file column over long distances, by keeping a group moving in a parallel direction. A unit is considered to have passed a waypoint (but not a final destination) if the closest point on the long-range path is at or beyond the waypoint. This is necessary in combination with change 3, to keep units from insisting on stepping directly on every waypoint even when other allies who were going in the same direction are in the way. edit: After further examination, I see there's another major reason for why groups of units take a long time to fully start moving. Units ask for a new short term path as soon as they encounter an obstacle, even if the obstacle is moving. Asking for a short term path causes the unit to stop for a bit. You can see this by ordering a cluster of stationary units to move with the speed set to Turtle (0.1x). You can see units freeze in place for a second, waiting for a path, before starting to move in a direction perpendicular to where they were ordered. To fix this, units should keep trying to move for a short period of time if they were obstructed by a moving unit, and only ask for a new path if this doesn't work. This would be in addition to the other changes. As it would result in fewer calls to the pathfinder, this would also improve performance. staticsliding.diff

Wow. That looks really great man! I'm glad the trick helped you. Using that setup you can safely import the props you need to take into account in the animation and get the exact same result of the engine. I'd say it's good enough. But if you want to go even further, the only detail that catches my eye is the rear foot. It looks very natural until the guy barely lifts the back foot from the ground because of the rest of the body inertia. Now it looks a bit like the foot gets stuck in the ground.

edits, built to the prop_weapon_right

that would have made my life so much easier earlier, such a simple fix too dangit, shame on me for not trying to resolve that issue sooner, haha. Of course you didnt try uploading it into the engine every single time to see if it was pointing the right way!

some edits

Wow that's a very good job for a first animation pass LordGood!! I would forget about the shield performance on the free arm. The main reason would be that they're going to be firing from a distance most of the time, so I think it'll be better for the flow of the animation to use the other arm to counterweight and add dynamism to the animation. We will be able to use the same animation for non-shield slingers too. We'll make use of the "realist shield combat" for melee units. If you find in your tests that the animation goes too quick, we could sacrifice one windup to shorten the frame count. Suggestion: Use the free arm/hand to catch the sling at the bottom after firing while returning to the start position. Like a hint at reloading. Question: How did you animate the sling? Different armature or you used any already existing bones? It looks really awesome! We might have some problems figuring out how to make the prop catch the same animation variants as the parents, but it sure will make room for great details like this one.

I think using actual Gallic will be very difficult, because we only have a few fragments for it. I think using Gaelic as substitute for Brythonic and Brythonic as substitute for Gallic would work. I'll dig up the translations and have a go at recording them with a mix of Scottich and Irish accent.

I totally started a slinging community here, I break slings constantly so I make sure I have surplus. Beverly has some amazing stony beaches for slinging Though gravity should remain constant, it would help simulate wind resistance if there was a play to it on different projectiles, I would think. Since there are no other possible forces acting on projectiles other than starting velocity and trajectory

Are you quoting Lindybeige here, or did you start a slinging community at your school? The range attack has a way to set the projectile speed. I'd guess this influences the trajectory. For a ballista, the speed is set to 300, while an archer has only a speed or 28. Deeper in the engine, the gravity can also be set (but I think this should remain constant).

The shield of Erik the Red has a serpent/dragon

I actually have a patch that will set game speed on -autostart but I was also trying to figure out how to accomplish this w/ hotkeys, something like: <object hotkey="speed5"><action on="Press">Engine.SetSimRate(5);</action></object> It would seem like this would be possible. +1 for hot keying speeds. Edit: attached a small working mod for #4 (POC) ... 0ad-speed-mod.zip Edit: also adding the -autostart patch, was rather interesting watching this situation unfold as a test ... pyrogenesis -autostart="random/continent" -autostart-speed=1000 -autostart-ai=1:petra -autostart-ai=2:petra -autostart-aidiff=1:0 -autostart-aidiff=2:5 0ad-autostart-speed.patch

@LordGood @Enrique For some reason when enabling advanced graphics horse_a.Xml is crashing the game, any ideas ?

I've seen all of Lindy's videos (I'm pretty sure), he's great to listen to, very persuasive too. My technique's gotten a lot better since that last slinging video I uploaded, perhaps I should record myself again? I know certain length slings are better for certain ranges, and certain slinging styles are better for different length slings. Also, there are many overhanded and underhanded styles, and those differ from region to region. Different cultures would throw different weight stones, for instance Greeks tended to throw smaller standardized stone ammunition than the Persians. Of course, these would demand different styles to keep the inertia from tearing up your joints, and proper follow through. I hear underhand was popular in the near and middle east, and would probably allow for throwing larger stones (the size of a man's fist, according to Xenophon(?)) short distances. Its not like the Persians have slingers anyway, but the Judeans probably used it similarly I've managed to hurt myself pretty bad overswinging, tearing up my rotor cuffs and whatnot. The power in this is in your core muscles, which i tried scrunching up as much as I possibly could here. I'd train sitting down to get them strong enough. If you guys don't sling, I would highly recommend it. It's super fun and you don't have to worry about carrying arrows whenever you want to shoot, or a bow for that matter. Sling fits nicely in your pocket, or makes a nice belt... or headband.... And to think, I thought guys throwing rocks in battle was silly not two years ago. Now I'm starting a slinging community at my school! I've brought out about 18 people who've given it a try, actually trained 5 fairly well, one of which is heading the group after I leave. I even got one of my professors to give it a try. He seemed pretty enthusiastic about it Also a shield tends to do its job best in front of the guy using it. (https://www.youtube.com/watch?v=GjZ6qWSenqI) Perhaps I'm taking the historical accuracy part a little too seriously, but I tend to agree with Skall on this point. all said, this gif is a bit choppy, and will likely be playing faster in game; though we need to coordinate with the balancing team, because some of these attack cycles run so quick they ruin the animations...

Oh right then it's perfect Maybe you could make a variant with no shield ?

Performance shouldn't differ a lot, but if there's a difference, technologies should be faster. That is because auras are not permanent (can disappear again), so the cache format for techs is more simple. Team bonuses need auras though, as alliances can change throughout the game, so they must be undoable.

Still working on this. So far I have implemented the following changes: When a unit tries to move and is obstructed by another unit, instead of stopping and asking for a short-range path, it will just walk all the way up to the second unit. From there it will attempt to "slide" along the side of the other unit's obstruction square. This "sliding" allows units to walk around each other without having to invoke the short-range pathfinder, which means they don't have to stop and can keep walking. Units only ask for short-term paths if the "sliding" is failing to make progress (unit is stuck and cannot slide). When a unit is following a long-range path, it only attempts to move parallel to the path instead of passing through every waypoint. This reduces the tendency for groups of units to travel single-file over long distances. Units will still follow short-range paths exactly, and will travel to the destination exactly. The combination of these two changes allows groups of units to get moving faster, and as they move they group together much better instead of narrowing to a single-file line. It also improves performance, because the "sliding" dramatically reduces the number of calls to the short-range pathfinder. I tested performance in the "combat demo (huge)" scenario. There are also some bugs where units get stuck - I've been working on figuring out how this happens and preventing it. It happens rarely. There's another issue. The groups of units are still not sticking together closely enough for my liking. They still bump into each other and don't all start moving instantly. To make units move together as closely as Starcraft marines, it will be necessary to have the units in front of the group move first, to open a space so that the ones behind them can walk forward without bumping into them. My plan for that is to let units wait for up to one other unit before they start moving. Here's a scenario illustrating how it would work. Unit A wants to move If A can freely move, it does so, and is finished for this turn. If A is obstructed by a unit B, and B is moving but has not yet moved this turn, then B remembers "A waits for B." Then A is done for now, but will try again later. Now unit B wants to move If B can freely move, it does so. Then B remembers "A waits for B" and tells A to try moving again. Unit A tries to move again (on the same turn, because B told it to try again). If A can freely move, it does so. If A still can't freely move because a unit C obstructs it, then A just moves as far as it can. It will not wait for C; it may wait for only one other unit per turn. However, I don't know if this kind of detailed ordering is possible with the component message passing framework. There is an alternative, which would be to sort units by their distance from the goal, and have units that are closer to their goal move first. However, that has its own problems and might be slower because it's O(n log n) instead of O(n).

Enemies! Sound the alarm!