Add [chapter] to [campaign]-tag

[Ravana]

It works exactly because you read it all to memory at once.

[Aldarisvet]

It works exactly because you read it all to memory at once.

So what is the problem?
For example To Lands Unknown have the size of 62mb space but still it is not devided into parts.
Grnk the Mighty have the size of 0.62 mb space and is divided into two parts.
I see no real memory problem here. I see that authors spilt their campaigns because of accessibility problem not because of memory.
Is this rather connected with the number of scenarios than with the size of campaigns?

I do not remember having any problems with memory on my Android device with HttT or TRoW which has around 25+ scenarios. This device is a smartphone with 1GB RAM (really old 4 year ago bought shockproof smartphone).

[gfgtdf]

Images and Music are usualyl loaded on demand, on the other hand in wml which is loaded one start even a code that is relertiveley small on disk can reult in high ram usage and loading times if done wrong e.g. massive use of macros to dublicate code. So there is not really a relation between the disk size of an addon and the ram usage it has.

Mainline scenarios are usualyl relertiveley simple compared to some umc content plus their wml code were rewieved by multiple wml coders, so you can usualyl asume that they do not have notiable perfoamnce problems.

[Nobun]

Coming back to the original idea, perhaps I have an idea about how to find a way to realize it without adding too many problems about memory consuming.
I don't know if the hint make sense or not, but I will try to show my idea.

Assume we have a campaign "Massive Campaign" composed by 5 parts

-------------------------------------------------------------------

Addon1: MassiveCampaign_part1, _main.cfg

Code: Select all

[campaign]
 	id="MassiveCampaign_part1"
 	name= _ "Massive Campaign (part 1)"
	define=CAMPAIGN_MASSIVE_CAMPAIGN_1
	first_scenario=...
	abbrev=...
	difficulties=...	
        difficulty_descriptions=...
	end_text=...
        hide=1
[/campaign]

And so on for part2, part3, part4 and part5.
As you can notice, all "parts" of the "Massive Campaign" are actually a separated campaign, wich will loaded separately.
Unlike 'standard' campaign (with no chapters) we will use less parameters on [campaign] tag inside the _main.cfg
Infact we dropped those parameters:
- rank
- description
- icon
- image
Becose those parameters will actually used only by the 6th addon (the container) wich we will discuss later
(And probably we could drop abbrev, but I don't know how and when it is used)

And we added an extra parameter:
hide=1

The extra parameter is intendent to HIDE those five campaigns (wich are 'part' of the global 'massive campaign) from the list of the selectable campaigns (and possible from the list of downloadable add-on).
Those campaigns, infact, will remain isolated each other, but will be not directly selectable.

---------------------------

After developing the 'parts' of the 'Massive Campaign', the UMC developer will need to add an extra add_on with only the _main.cfg and the images needed to show the general informations about the whole campaign

Code: Select all

[campaign_container]
 	id="MassiveCampaign"
 	name= _ "Massive Campaign"
	abbrev=...
	rank=...
	description= _ "..."
	icon=...
	image=...
        [chapter]
           chapter=1
           id="MassiveCampaign_part1"
        [/chapter]
        [chapter]
           chapter=2
           id="MassiveCampaign_part2"
        [/chapter]
        [chapter]
           chapter=3
           id="MassiveCampaign_part3"
        [/chapter]
        [chapter]
           chapter=4
           id="MassiveCampaign_part4"
        [/chapter]
        [chapter]
           chapter=5
           id="MassiveCampaign_part5"
        [/chapter]
[/campaign_container]

The new "campaign container" tag will work as campaign, but will drop:
- difficulties
(difficulty settings will be available within every 'chapter', wich are the actual campaigns)
- diffucilty_description
(difficulty settings will be available within every 'chapter', wich are the actual campaigns)
- first scenario
(this is a container of sub-campaigns, not an actual campaign)
- define
(not needed... for the same reason as before)
- endtext

It will have instead:
- rank (the idea is to have only a rank value for the whole "Massive Campaign")
- [chapter] tags

---------------------------------------------

In this way the user will select the whole campaign from the campaign list, only viewing the 'container' wich will show all the parts available for that campaign.
Then the player will select the part he wants to play, and the system will load only the selected sub-campaign as it was selected from the list.

NOTES:
1) Container can be translatable, but the translation will be apply only to the elements actually defined by the container itself (campaign description and so on)
2) All chapters works exactly as any other 'isolated' campaigns: wich means, for example, that every chapter will use his own textdomain wich must be different than the textdomain eventually used by the container.
3) When a player reach the end of a "chapter" he probably will have to select again the "Massive Campaign" and choose the following chapter manually.
4) Some parameters I 'dropped' for chapters, probably can be still required for a good appearance. The only parameter I am almost sure it is useless for a "chapter" of a "Massive Campaign" is the 'rank' parameter, wich - imho - should be used only in container
5) The idea on using hide=1 on every "chapter" is also related (if possible) to add-on download. The idea is to display only the WHOLE campaign as a single item. But, when downloaded, add-on manager will download every 'chapter' and the 'container' in a similar way like happened when an addon requires another addon.

[Pentarctagon]

Wouldn't it make more sense to organize by category? For example, add another column "Category" to left of the "Play a Campaign" column on the campaign selection UI, and only campaigns that matched the category selected would appear in the "Play a Campaign" column. Campaigns could then have an additional "category" attribute, which would be a comma-delimited list of which categories they should appear in. So if the categories were: humans, elves, dwarves, undead, mainline, addons; then The Hammer of Thursagan would appear if either the "mainline" and "dwarves" category was selected.

Ideally the categories would also be dynamically created, so that add-ons with multiple chapters could just put themselves in their own category.

[Aldarisvet]

I really like that "dummy" campaign idea by Nobun. But as I can see, this will not be fast to implement, at least 5) seems as a problem.
And about 3) - If it would be possible to run a campaign from another one (from "dummy" one), then there should not be a problem to send a player back to the "dummy" campaign after ending of the real campaign.

EDIT: Actually 5) is not a problem if you mark campaign parts as Resources (required add-ons), not as Campaign, and mark "dummy" campaign as Campaign. So there would be no need to hide anything in add-ons server, because users often filters by Campaign.

[Nobun]

@Pentarctagon: Your idea is nice The reason why I suggested a 'dummy campaign system' is to allow more customization. The idea is to find a way to be sure that the chapters are surely shown in the right order. Adding a category parameter will not allow to specify what is part 1, what is part 2 and so on... So, using your idea, they will correctly grouped in the right category, but it can be happen that, for example, Part 1,2,3 will be showed in the wrong order in some situations (for example part 1,3,2)

@Aldarisvet: thank However the idea of using dummy campaign to download all the parts from the add-on server is an optional feature (I said 'possibly' becouse, it could be a nice feature to have, if it is possible to implement it )