Charles Dang comments

Results 128 comments of


                                            Charles Dang

[wip], use to/from_chars in attribute_value and lexical_cast

FTR, it used to use (in most cases) lexical_cast_default, and it seemed to make sense to have an API which used `optional::value_or.`

[wip], use to/from_chars in attribute_value and lexical_cast

Currently this code will fail if added to the tests: ```cpp c["x"] = "9.87654321"; BOOST_CHECK_EQUAL(c["x"], 9.87654321); ``` saying that `check c["x"] == 9.87654321 has failed [9.87654321 != 9.8765432099999995]`. I imagine...

Better indicators for multi-turn moves

Absolutely agree, those footstep graphics are currently so outdated. The proposed UI would definitely be a good start.

Add core (add-on with id="mainline") to list of installed add-ons

I agree this is an odd fix. What code looks for "mainline"?

Show dates in the campaign selection screen?

I don't think that's a great idea. Without a frame of reference, the average player would have no idea what those numbers mean (or even what YW means).

Show dates in the campaign selection screen?

It could be done, same as any other dialog that has column-based sorting, but I think it would just clutter the UI more.

Lua API: add padding option to add_overlay_text

Hmm, good point. I guess I was thinking `padding` makes more sense if you're going to treat the padding as part of the bounding box, but I can change it...

[multplayer_side] random_leader= is ignored if leader= has less than 2 values

What is the expected behavior here? That random faction selection also chooses from `random_leader`?

[modify_unit] advances_to is not saved without C stack overflow

To clarify, the first time the event is run, the modification does not apply to the unit? - that is, the units should advance to Armageddon Drakes, but don't?

[modify_unit] advances_to is not saved without C stack overflow

Hmm... why does it work at all without `[not]`? The Inferno Drake does *not* advance to the Armageddon Drake by default, so the event should never even fire in that...