DewyB wrote:This may be a noob question, but this is one way to learn. The above post says the Windows download is (369.6 MB)When I start the download, it says XX.XX/352MB XX minutes left

Is there a discrepancy here? The reason I ask, I have tried to download it twice, both packages were different sizes upon completion, and neither worked (would not even open).I've had an issue with dropped packets before, but that is supposed to be resolved. Hasn't been an issue recently, but certainly seems to be an issue today.

The thing is, there is disagreement about what "mega" means. It can mean either 1 000 000 (10^6) or 1 048 576 (2^20). We have listed package sizes using the smaller of the two, SI mega. Your browser instead uses the computing mega; with that unit, the Windows installer size is 352,48 MB. So, no, there isn't a size discrepancy.

That's not a disagreement, that's one using the incorrect term. A MegaByte (MB) is 10^6, while a MebiByte (MiB) is 2^20.

99 little bugs in the code, 99 little bugstake one down, patch it around-2,147,483,648 little bugs in the code

Celtic_Minstrel wrote:The reason it's deprecated is that there's now new WML tags for looping constructs - [repeat], [for], and [foreach]. FTR, the {FOREACH} macro is now implemented in terms of [for].

Yes, but writing a [for] cycle is still longer in WML tags than with macros. No matter how specifically designed for this purpose, it will add at least two lines, doubling its invocation's length. WML's problem with massive line counts has been one of the main reasons to use macros.

Not sure how those numbers work; the way I use them, a {FOREACH} macro would have two lines plus the body, while a [for] loop would most likely have five lines plus the body. It doesn't really matter, though; the {FOREACH} macro is deprecated, and it will almost certainly someday be removed, so if you really prefer using a macro for looping, I would suggest you find time to write your own version of the {FOREACH} macro. There's no hurry, mind you — {FOREACH} won't be going away anytime soon — but in my opinion it's probably better to stop using it sooner rather than later.

Not sure how those numbers work; the way I use them, a {FOREACH} macro would have two lines plus the body, while a [for] loop would most likely have five lines plus the body. It doesn't really matter, though; the {FOREACH} macro is deprecated, and it will almost certainly someday be removed, so if you really prefer using a macro for looping, I would suggest you find time to write your own version of the {FOREACH} macro. There's no hurry, mind you — {FOREACH} won't be going away anytime soon — but in my opinion it's probably better to stop using it sooner rather than later.

I can create a macro for that, but what I fear is the phase just before the macro is removed - deprecated things tend to make big warnings visible to everyone. 1.12 still prints very annoying messages about deprecated ability formats that will not be supported any more in 1.12 (which is simply not true) instead of simply not supporting it and showing slightly weird formatting, becoming almost the only reasion why the usage of old 1.10 saves is annoying.

Dugi: I've considered adding a "addon developer mode" option in Advanced Preferences which will enable the showing of deprecated messages (and possibly other things) which currently are just dumped to chat for everyone. Would that help with your complaints?

Celtic_Minstrel wrote:Dugi: I've considered adding a "addon developer mode" option in Advanced Preferences which will enable the showing of deprecated messages (and possibly other things) which currently are just dumped to chat for everyone. Would that help with your complaints?

Celtic_Minstrel wrote:Dugi: I've considered adding a "addon developer mode" option in Advanced Preferences which will enable the showing of deprecated messages (and possibly other things) which currently are just dumped to chat for everyone. Would that help with your complaints?

I'd also like to have some new mode, that is not exactly debug mode but rather some limited debug mode that can be used for both playing and debugging. That is, you have lua-console, debug consolde commands, deprecated wanrings etc, but no other things that spoil your game experience like 'all side visible in side overwiew', 'the messy right-click menu' or the game config reloads due to DEBUG defines. Maybe this could be combinated without your 'developer mode' idea.

Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

I'd suggest "Debug mode" simply enabling a "Debug preferences" dialog.Then you can enable or disable the various options, as needed; or trigger certain events.That way each developer can have a default setup which suits their general needs, and quick access to features they rarely use.

gfgtdf wrote:I'd also like to have some new mode, that is not exactly debug mode but rather some limited debug mode that can be used for both playing and debugging. That is, you have lua-console, debug consolde commands, deprecated wanrings etc, but no other things that spoil your game experience like 'all side visible in side overwiew', 'the messy right-click menu' or the game config reloads due to DEBUG defines. Maybe this could be combinated without your 'developer mode' idea.

What I described would be independent of debug mode; you could have either or both enabled as you see fit. It could be used by addon devs, but also by the more dedicated beta testers for example.

I'm not sure what it would do besides increasing the verbosity of diagnostic messages though. (That is, including deprecation and other warnings along with the more-fatal errors.)

This is UtBS:A_Subterranean_Struggle. After killing the last leader, you get this error. It sounds like next_scenario is not recognized. Is this just a bug, was it removed or renamed intentionally, or am I misunderstanding the message? (Since [endlevel] doesn't work, the scenario doesn't end.)