This does sound like a 'core' c++ feature to me, but having a JS implementation first and then possibly porting it to C++ sounds like an interesting approach to me.

Care to do the siege units as well? If not, I'll un-request changes.

Open question for other devs: don't we already have a patch for trample damage somewhere?

k, now I understand the problem, gaelic hardcodes that 1 and 11 must always be the singular form, however that isn't the case in this string.

Patch still applies correctly, reads correct, front doesn't fall => accept

Given that the statement m_SpeedRatio = is only intended for the switch fallthrough cases and not MT_Deserialize the basis for my suspicion fall away.

So if you want to keep the statement that is a null-statement in the MT_Deserialize case in order to minimize the code, okay.

I'm wondering the real usefulness of the bolt shooter vs stonethrower templates also. It seems to me basically all "shooter" siege engines of the time were torsion engines, which could fire smaller or bigger projectiles and arrows or stone sort of indifferently.
The main difference was mostly whether they could shoot precisely (aka be used as a marksman's tool) and mostly horizontally to target enemy units, which was in general a factor of size it seems.
Might be more interesting to have a "light" and "heavy" variant or something. Or just merge them and specialize derived templates since siege engines were kind of civ-specific beyond rams.

In D1840#75567, @wraitii wrote:

In D1840#75562, @elexis wrote:

If the value that SetSpeedRatio computes differs from the serialized value, by definition it's OOS?

Yes.

However, that value can only differ if m_SpeedRatio > std::min(ratio, m_RunSpeedMultiplier).
Which is impossible because the only place modifying m_SpeedRatio is SetSpeedRatio, which does m_SpeedRatio = std::min(ratio, m_RunSpeedMultiplier).

consider modifiying m_RunSpeedMultiplier too, which is only done on ownershipchange and valuemodification (afaik), where we set the value too

In D1840#75562, @elexis wrote:

If the value that SetSpeedRatio computes differs from the serialized value, by definition it's OOS?

If the value that SetSpeedRatio computes differs from the serialized value, by definition it's OOS?

when someone decides to have something other than a grain field, one can always change it in the parent.

In D438#75552, @elexis wrote:

(See also comments in rP22197.)

But m_SpeedRatio is serialized and then replaced by m_SpeedRatio = std::min(m_SpeedRatio, m_RunSpeedMultiplier);.
This sounds like it would go OOS if that line changes the value,
or if the line never changes the value, is a useless line (misleading the reader to believe that it has use)?

See D1840, but this is only to check if the "new" m_RunSpeedMultiplier isn't actually lower than m_SpeedRatio, which can happen after an aura/tech/ownership change.
Deserialization actually uses this call solely to recompute m_Speed.

Successful build - Chance fights ever on the side of the prudent.

(See also comments in rP22197.)

Mhpf, you're right. Fix other whitespace in this file while I'm at it.

Successful build - Chance fights ever on the side of the prudent.

See D1840.

This code is safe.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

It appears an NDA can result in multiple states

For the deterministic automaton there is at most one transition for the current character of the word that the automaton processes.
For the non-deterministic automaton, there are zero or more states that follow for a any given character.
But every transition transitions between two states of the automaton.

Remove the helpers mock for now.

In D438#75520, @elexis wrote:

In D438#74992, @bb wrote:

(we also need to do an OOS test on this btw)
did a quick rejoin test, which did not oos

What does quick rejoin test mean? Which steps did you perform?

Host a game and join with another player (both with the patch ofc), load the game and move stuff around (in formation, guard, attack a deer, do a tech etc.), leave with the joiner, and rejoin. Now move some more stuff and wait a little.

UnitMotion cannot know if this speed is on purpose or not so always adjust and let unitAI and such adapt

Assume this comment is true,
then UnitAI changes the runmultiplier and it yields an OOS, correct?

How will UnitAI change the runMultiplier? it is a template value, maybe modified by some tech...

Isn't serialization of the run multiplier so that UnitMotion can know if this speed is on purpose?

Where is it serialized? It is desirialized such that the rejoiner knows that a tech is researched, further it is a template value.

Is the deserialized runmultiplier read from? It looks like it's overwritten with a different value before it's read from.

The only other place I see it is set, is the init, which should be earlier right?

In D438#74992, @bb wrote:

(we also need to do an OOS test on this btw)
did a quick rejoin test, which did not oos

Hopefully clarify comments.

About creating new files, Im skeptical if they are 120 lines short, since the other files are couple of thousand lines long

I noticed that some structures have smaller cost than loot, which looks a bit weird. Leaving that as is for now, this patch doesn't change this.

I'm switching from an FSM to a non-deterministic state machine so we could be in multiple states at once

Last time I checked, an automaton is always in exactly one state at a time, but a specific word that an NDA processes can result in one of multiple states, otherwise it would be a deterministic one.

Successful build - Chance fights ever on the side of the prudent.

Both hunks are Mac OS :) I was just stating that since we didn't remove it for Linux it wasn't an argument for doing it on Mac ;) I don't see a problem with committing this but since @wraitii seems to think this is not worth it I wanted to know why.

@elexis I'm inviting you to look at this, from playing around with it it feels much nicer to me.

Successful build - Chance fights ever on the side of the prudent.

More complete example of what I'm envisioning. We'd have possibly multiple "Input State" components that listen to events and possibly 'kill' themselves - so no transition from an input state to another input state except "no input".

Ok, so just commit the second hunk?

Perhaps my summary is a bit ambiguous, this allows a unit to have trample damage, so it can charge 'through' a formation of units whilst dealing damage. Useful for e.g. chariots, elephants, macadonian fire-raiser et alii.

Don't we have splash damage for it ?

In D1691#75466, @fabio wrote:

I said system, which got removed from Linux times ago, as I wrote here:
https://trac.wildfiregames.com/ticket/4362#comment:26
And which is removed in the second hunk of the patch.

I said system, which got removed from Linux times ago, as I wrote here:
https://trac.wildfiregames.com/ticket/4362#comment:26
And which is removed in the second hunk of the patch.

Yes, I mean the height maps in the maps/scenarios/ folder:

• Height Map 03.png
• Height Map Import Demo Image.png
• Height Map Import Demo Image 512x512.png
• Height Map Import Demo Image - Fractal.png
• Height Map Import - Four Oases.png
• Height Map Import - Oasis 12.png

It's about file names in the art/ folder; I thought of you because you mentioned the art design document today.

Successful build - Chance fights ever on the side of the prudent.

I don't really have the time now, sorry but maybe gallaecio does :)

opinion on renaming heightmaps

I thought you mean the heightmaps that were used: rmgen, but they already have that naming pattern. But you mean those scenario/skirmish png copies that are not used by the game? Perhaps just move to art_source? Just adding a comment and link to the XML file instead of a copy of the source? (And maybe a reference to the commit IDs so that people can click from one to the other to find the source)

@elexis Do you have an opinion on renaming heightmaps to match their map name ? I guess the only trouble would be what to do in case two maps use the same heightmaps.

Actually it was not removed, else I would have kept the previous diff :)

That's not currently the case, though.

Why not? system was already removed from Linux since it is no longer used, OS X should follow...

I feel extremely "meh" about this :p
Commit it if you want, don't if you don't. It's unlikely I'll do it myself is my point.

@Itms anything wrong with that patch ?

Well this patch is just disabling shadows if the user can't handle it because he doesn't have enough VRAM. Currently it only disables it but the user doesn't know about it.

I though Mac OS had a tendency to link dynamically when it could ? It isn't a big change, it more of a cleanup. If you have a good argument against committing it, I can just abandon the revision :)

Well heightmaps should have the same name as the map with a different extension ?

Wouldn't it be better to max(0, ...) the whole calculation? This is magic-graphical-code but you're changing behaviour a lot here.

Successful build - Chance fights ever on the side of the prudent.

Remove the "only if blocking pathfinding" because I don't see the point tbh.

Actually I think removing demo and Demo from file names won't be an improvement, because it would result in potentially confusing map file names, e.g. combat, multiplayer, territory, etc.

At this point it'd probably be usefully rebased on top of D1834... I'll keep this in my review queue as I might commandeer at some point in the future.

@Stan, perhaps you could review this? (@Itms seems to be busy.)