Wesnoth 2.0

[silene]

Basically I want it to be more like Javascripts document.write()
So that it's easier to write subtags and all the attributes.

This feature is available since 1.7.0, except that it's not the Javascript syntax, but the Lua one.

[Gambit]

You really want more of us to learn lua don't you...

And it's not that I want to create a new tag as in the LUA tutorial. It's that WML should be able to store large pieces of WML in variables and then conditionally add them to the .cfg file. The [insert_tag] tag can do this already. It just can't do it well for any tags with subtags (i.e. [message], [option], [show_if], and [command] all nested inside each other). Or if it can, it isn't described in the wiki.

Perhaps this should be split. I'm trying to shake my "thread derailer" rep.

[ancestral]

I was talking to Aethaeryn and he and I agreed how incredibly awesome it would be if we could read and write a small amount of data to a file in the scenario or campaign's data folder, like a preference file.

[Gambit]

Indeed. There are many possibilities to such a feature.

[silene]

And it's not that I want to create a new tag as in the LUA tutorial. It's that WML should be able to store large pieces of WML in variables and then conditionally add them to the .cfg file.

You are misunderstanding me: I'm not suggesting the creation of new tags; I'm just saying that Lua can be used to create the WML code of your scenario on the fly. For an example, you should take a look at the data/ai/scenarios/scenario-AI_Arena_small.cfg file (disclaimer: I'm not its author, I didn't even touch it). Among other things, this scenario generates a [message] tag with [option] and [command] subtags depending on the value of some variables.

[Aethaeryn]

Indeed. There are many possibilities to such a feature.

Other possibilities (they're not CABD, because all of these are done across multiple tries of the same scenario/campaign or even across different scenario/campaigns):

• When you play a scenario a second time, it automatically detects that you play it before and alters/shortens the opening sequence, or alters it in some other way to make your experience unique without true random generation.
• When you return to an RPG, having not done a sidequest before to save the blacksmith's daughter from outlaws, the blacksmith doubles his prices on you.
• You could have a bonus scenario (or even part two of a campaign) unlocked after completion.
• You could have the AI gold dynamically adjust based on a multiplier that goes up when you win and down when you lose.
• You could carry over armies or units from one campaign/scenario to another.
• You could have something in a scenario or campaign similar to PS3 trophies or Xbox 360 achievements (I'd recommend the name "runes")

The only issue I can see is "security," but if you restrict it to being able to write variables on one preferences file, I think the only problem would be overwriting existing variables. That can be bypassed by adding a prefix, perhaps even based on its textdomain (for instance, "thunderstone.blah=" instead of "blah="). Please tell me how restricting it so you could only write things like thunderstone.difficulty=150 (in the case of the dynamic difficulty gold multiplier suggestion) or fooRPG.blacksmith_like=50 (in the case of the blacksmith sidequest) would be a security risk?

This kind of improvement would truly give enough different UMC worthy of a 2.0.

[Gambit]

The entire addon server is a security risk. Threat is in the eye of the beholder.

[fabi]

Since Wesnoth 1.0 was a feature complete game my opinion is that Wesnoth 2.0 should go in the same direction.

That means all old style portraits should be replaced,
winter terrain in every case it makes sense,
and all sprites in same quality/style,
only to mention the art issues.

There is much work to do to reach that goals what delays Wesnoth 2.0 to a time that it is pointless to discuss a release time for it now in my opinion.

Greetings, Fabi

[Max]

my wish for bfw 2.0:

documented source code, at least a couple of lines for each module. although something like that would be awesome: http://www.wesnoth.org/wiki/SummerOfCod ... _uml_model

[grrr]

I don't think comments would help much, and honestly, this UML diagram reads like a big red warning to *not* touch the code =)

[Sapient]

I don't think comments would help much, and honestly, this UML diagram reads like a big red warning to *not* touch the code =)

You have been warned.

[Max]

And it's not that I want to create a new tag as in the LUA tutorial. It's that WML should be able to store large pieces of WML in variables and then conditionally add them to the .cfg file. The [insert_tag] tag can do this already. It just can't do it well for any tags with subtags (i.e. [message], [option], [show_if], and [command] all nested inside each other). Or if it can, it isn't described in the wiki.

you can already do this with [set_variables]:

[value]: the WML inside the [value] tags will be stored in data, variables will be interpolated directly, use $| in order to escape the $ sign, you can store arrays of WML by supplying multiple [value] tags.

see data/scenario-test.cfg for an example...

[Gambit]

see data/scenario-test.cfg for an example...

Oh that's bad***. Thank you so much!

[Elvish_Hunter]

Well, it's clear that Wesnoth 1.8 will be shipped with 15 campaigns. Now, we started with 1.0 having 4 campaigns (plus TDH), then 1.2 had 6 (3 new, TDH and SotBE removed), 1.4 had 13 (6 new plus SotBE again added), 1.6 has 14 (1 new) and 1.8 will have 15 (1 new).
For 2.0, considering that from 1.4 to 1.8 only 2 new campaigns were added, my proposals are:
- to have loyal units marked with a bronze or copper ring as in Dead Water (yes, I know that this have been discussed before, and can already be done with WML, but I mean being added to mainline/core, as fabi writes: this hasn't yet been officially approved or rejected, AFAIK)
- (this one is a joke, but feel free to take it seriously) maybe have Mountain Pass and Valley of Statues added back in HttT?

Games like Fire Emblem get away with full version numbers for not-that-many changes in the actual gameplay. So just make 4 new campaigns and call it Wesnoth 2.0

- and to have 20 campaigns. This will mean having 5 new campaigns. So, what will be the 5 new campaigns to add? Please post your opinions (you don't need to specify all 5 campaigns, however).

[ivanovic]

Since I should have a good idea when 2.0 is "ready" (hey, I am the release manager...) here is what I think will be required before we can seriously things about getting 2.0 out (the list is by no means static or complete):

• Rewrite of the new GUI/theme engine done. Mordante is working on it for some time now and it should help making the GUI better scalable for small and big resolutions. This task will take some more time. Don't ask how much, it is a serious amount of work...
• FormulaAI stabilized with some more options and all the likes. Over SoC this year really much was accomplished in this area, but many further improvements are still possible and going to happen. This will help campaign designers with making the AI better in specific scenarios and it can maybe improve the general AI "brain" a lot, so that it acts a lot less stupid in some specific situations.
• Rewriting the tutorial. This is a huge task and on our list for some time already. We had some complaints (okay, many...) that the tutorial is not perfect and it is on our list, but this will take lots of time, too.
• Artwork basically completed. Of course there will always be changes and improvements. But currently we are getting closer to several points here. For example we are close to "every unit has a portrait" (though sometimes it is "just" for the unit line, which is still a lot better than just the plain old unit image). Beside this the sprites for unit lines should be in one style possibly with "complete" animations. A current example where it is not done yet, but work is currently in progress are the Drake Flare, Drake Flameheart and Armageddon Drake. They are not yet switched over to the new style that the other units in the Drake Burner line have.
• Good support for cooperative campaign play and maybe at least one example directly shipped with mainline. One step in this direction was completed over SoC by rewriting savegame stuff since this was a real blocker for making (real, perfectly working and well integrated) MP campaigns possible. Currently some kind of MP campaigns are possible, but the content creators are not yet able to use the same stuff as singleplayer campaign creators. Having feature parity here (without reducing singleplayer features!) would probably a nice thing to have.

The real changes that result in naming a release 2.0 are basically the internal things like the GUI rewrite. A lot has already changed since 1.0, but there is also a lot that we are currently working on. As you might know from reading the changelogs we are really getting into the direction that the points I listed above are done. Basically I think that we will *not* have something along the lines of "before we release 2.0 we have to include 20 campaigns" or anything like this. The real reasons to name it 2.0 are mainly technical, often plain internal and maybe not even directly user visible.