Development: Scarlet Sea [campaign]

[pyrophorus]

Hi !
Just a word about your code: I don't know if you plan to use a lot of [special_menu_item], but (you know it or not), it's not obvious to use more than seven in the same campaign. I had quite a hard time on this topic ! Ask me more if you want.

I'm going to work on scenario two now.
Besides that, I have the feeling you decided to have Ceres working on the abilities and spells, and I on the scenarios. Correct ?

Friendly,

[battlestar]

What do you mean by "it's not obvious to use more than seven in the same campaign"? set_menu_item or special_menu_item?

Yeah, Ceres had some interest in the spells and abilities.

[pyrophorus]

Hi !
If you declare more than seven special_menu_item with different IDs, the eighth one will never show. The trick is these menus are not a dynamic list but a limited array of seven slots: all you can do is to modify existing slots, overloading them using the same ID you used in your first definition.
That's why this code alerted me:

Code: Select all

      [set_menu_item]
         id=valia_transformation_menu

If you plan to define a different ID for every set_menu__item you use, this will not work. Individually, all these menu will work, but not together, or more accurately, the first seven ones will work, and not the further ones, in whatever order you add them. They shall be silently discarded.
This is puzzling, because, obviously, you shall investigate why this [censored] menu don't show in your own code and the problem is elsewhere.
I can give code examples if you want. I encountered the problem in my campaign.

Friendly,

[battlestar]

Yeah, I've considered about the 7 limit menu thing. Just to clarify, for spell casting heroes, those abilities need to be converted into the same format as other spells, where all effects (like converting to a gryphon and converting back) would be controled from the spells sub-menu in the menu system shown in http://forums.wesnoth.org/download/file.php?id=56039 (You've probably already seen it), instead of independent menus.

There should be a maximum of 2 menus active at a given time: One from a hero (or a unit with an ability that requires a menu), and the other is saved for environmental interaction. In other words, one set_menu_item slot is for the menu system that covers skills/spells/etc, and the other slot is preserved for scenario purposes.

An example of what I mean:
-When right clicking on Skarbod, only Skarbod's menu is seen. Skarbod's menu would cover everything he needs for his skills, spells, and stats. His menu would also share some submenus such as the help submenu with other heroes.

-When right clicking on Valia, only Valia's menu is seen, with similar contents to Skarbod's menu except geared towards Valia.

-When right clicking on a non-hero unit with Gryphon Form ability, right clicking it would only bring up the one option to change to gryphon/change back, and a menu like what Valia/Skarbod have does not show.

So again, at any given time, there would be a maximum of 2 menus active. But, there would definitely be more than 7 menus throughout the campaign. I didn't think that would be a problem, but if it is, please expand more on it.

Thanks for bringing this up, it's something important to be clarified.

P.S. Personally I prefer this way to keep each menu specific to each intended unit:

Code: Select all

				[set_menu_item]
					id=valia_menu
					description= _ "Lists Valia's menu"
					[show_if]
						[have_unit]
							id=Valia
							x,y=$x1,$y1
							side=$side_number

						[/have_unit]
					[/show_if]
					[command]
						{VALIA_MENU}
					[/command]
				[/set_menu_item]

[pyrophorus]

Hi !
About set_menu_item. I'll try to be clear and accurate:
When starting a campaign, you have seven empty unlabelled slots for the right-click custom menus.
When using [set_menu_item] you can either:
- use an empty slot if any, which will be labelled after the menu ID you specify.
- overload an existing menu if and only if their IDs are the same.
- be sorry if none of previous case apply (no empty slot, not same ID found). Then, the instruction has no effect, and you wonder why.
These menus definitions persist *all campaign long*, and there is no explicit way to clear a menu slot or even a menu. You can only overload them.

So, if there is more than seven menus in the campaign (even if they're not active or visible at the same time), you must, sooner or later, reuse an existing one.
This can be done only using set_menu_item with the ID of an already existing menu.
This is the first problem. IMO, this imply to use a global set of menu IDs (for instance menu_1, menu_2 etc...) which will label the slots uniquely in all the campaign and set/modify them in scenario files only (this to avoid two events in units or spell definitions modifying blindly the same menu slot). Maybe we should agree on this early.

The second problem arises when modifying an existing menu. As you know, you can specify a [show_if] and/or a [filter_location] as well as a [command].
All of them are kind of slots too. In other words, if you overload a menu previously defined with a [show_if] condition with another one with a [filter_location] condition only, the [show_if] condition is *not* erased as we could expect. It remains there and is ANDED with the new one, so most probably the menu won't show. So, to make things work in any case, you probably should always specify the two conditionnals when defining a menu:

Code: Select all

[set_menu_item]
	id=menu_{MENU}
	description=_ "Cast a spell."
	[show_if]
		[have_unit]
			x,y=$x1,$y1
		[/have_unit]
	[/show_if]
	[filter_location] # this always true condition is here to overload a previous one which would prevent the menu to show
	[/filter_location]
...
# Mirror example
[set_menu_item]
	id=menu_{MENU}
	description=_ "Drop a bomb."
	[show_if]
		[have_unit] # this always true condition is here to overload a previous one which would prevent the menu to show
		[/have_unit]
	[/show_if]
	[filter_location]
		[filter_adjacent_location]
			[filter]
				{UFILTER}
			[/filter]
		[/filter_adjacent_location]
		terrain=W*
	[/filter_location]

# and this macro can disable a menu you don't need any more.

#define SSC_DISABLEMENUSHOW MENU
# -- This macro disable the menu item MENU setting a "never" condition
[set_menu_item]
	id=menu_{MENU}
	description=_ "Never show."
	[show_if]
		[have_unit]
			id=SSC_Nobody # this unit never exists, as its name implies.
		[/have_unit]
	[/show_if]
#	[command]
#	[/command]
[/set_menu_item]
#enddef

You can note in these examples the menu ID is a macro parameter. This allow to put a menu item in any existing slot, in other words, the same functionnality can be installed in different slots during the campaign. Since the id never show to the user (only the description) this is not important.
I hope I've been clear enough on this difficult topic. Feel free to ask more examples.

[battlestar]

I think I get what you're saying, which is there are a total of 7 possible set_menu_item id slots in a single campaign. That's pretty weird, any idea why it was made this way?

Anyways, though that's the case, I think we'll still manage just fine. We should set away the first slot for the main menu system with all the spells, skills, etc etc (by taking advantage of [show_if] within [option]), and leave the remaining 6 to scenarios (and be applied like your example). I'll do some further tests to see how it would work.

Since Ceres is doing the main menu, I wonder what his thoughts are on this matter.

[Ceres]

IIRC the 7-set_menu_item-limit was to avoid cluttering up the right-click menu. Yes, I'd also prefer to keep the number of items low and put things in [message] submenus.

[battlestar]

I still need to collect the sprites.

Here's the updated scn-2 script after re-reading through the whole thing. Pre-scn story and A-K events were updated, and 1-15 events were unchanged.

scn2 script.zip

(24.83 KiB) Downloaded 252 times

@ Ceres: The skills were still inside the scenario file. In the past, I had trouble with having macro in separate cfg files and had to keep everything inside a single scenario file. These macros haven't been separated out yet since my problem with separate cfg files was resolved.
You probably already have this file:

06_village_of_the_damned.cfg

(72.3 KiB) Downloaded 166 times

Terrifying augmentation adds to weapons a special that when the hit lands, there will be no counter attacks. It is under the macros of:
#define WEAPON_SPECIAL_NO_COUNTER
#define SET_WEAPON_SPECIAL
#define TERRIFYING_AUGMENTATION
#define WEAPON_SPECIAL_NO_HIT

Elemental weakness was an old piece of code, its effects are permanent. That is a bad thing for this campaign IMO.
#define ELEMENTAL_WEAKNESS

Hysteric vengeance causes double retaliation dmg that last 3 turns with cost of 2 pips
#define WEAPON_SPECIAL_VENGEANCE
#define HYSTERIC_VENGEANCE

Plague mist turns any fresh-kill adjacent to the caster into a zombie, with success rate of 40%.
#define ABILITY_AURA_OF_REANIMATION
#define AURA_OF_REANIMATION_DEATH_EVENT # ### must be at the end of the scn or it high-jacks death events!

[Crendgrim]

I think I get what you're saying, which is there are a total of 7 possible set_menu_item id slots in a single campaign. That's pretty weird, any idea why it was made this way?

See the documentation of [set_menu_item]:

Note: Due to limitations in portable devices where there are no scroll bars for context menus, there is a hard-coded limit of 7 custom WML menu items. If you really need to have more than 7 menu items, try combining some of them in a submenu.

[battlestar]

Thought that was talking about simultaneous display of maximum of 7 menu items since the reason given was lack of scroll bars.

If that's the reason, wouldn't it make more sense to lift the limitation on how many menu items can be used and leave the responsibility to the campaign creators for limiting how many are simultaneously displayed? Just display the first 7 if there are more than 7, and leave a warning in the wiki.

But I digress. We're here to work with whatever is available to us in this campaign.

[pyrophorus]

Hi !

Prologue-2.cfg.zip

(1.94 KiB) Downloaded 175 times

A scenario -> in scenario folder, and a new menus.cfg -> utils folder.
In this scenario file, there is a suggestion for menu and sub-menus. I hope this will fit your needs, but I'm not sure, because I don't know how you will build your spells submenus (static or dynamic). There is a generic spell menu which don't change and displays specific submenus for each hero character. Since the submenus are enclosed in events, these can (and must) be defined at scenario scope, not full campaign scope, which is easier to manage I think. If you already have some example of working spells, it would be fine to try them here.
Besides this, I added an "help & hints" right-click menu. It's a suggestion. I think it's more user friendly than a walkthrough, and the feedbacks on my campaign showed that many players use them.
Friendly,

[battlestar]

Excellent, I've made a few additional changes, made options character dependent, combined everything into one set_menu_item, and incorporated an up a level system I learned from Boldek.

Include the following to a scn file:
{SSC_MENU_HELP_BS 1}

and the attachment:

menus2.cfg

(3.73 KiB) Downloaded 149 times

Please take a look and let me know what you think.

Hope our codes would be of help to Ceres.

[The_Other]

AMLA system for the heroes is done (mostly).

Known issues

I haven't yet done the XP-setting formula, hopefully I will get it done tonight but I haven't really done much math in WML before so it might take me a bit of time! A side-effect of this is that characters' level does not increase when they advance (XP-setting needs both 'before' and 'after' values, so it makes sense to me to apply the increase within that script rather than in the AMLAs themselves)

Leadership is a custom version - standard type seems insane when characters can reach level 25. I just guessed at how it should work (15%/30% bonus regardless of relative level), but this can be changed if it's not right.

Currently the Quick Action ability doesn't work, and I can't see why. For debug purposes, it was supposed to show a message when the 'die' is rolled and another if the roll is successful. Neither one comes up, and nothing ever happens (I've now commented the messages out, but that's not the problem!)

All the abilities related to spells and runes are dummies at present, as I don't know exactly how spell-casting is implemented. For the same reason, I haven't written the AMLAs for the 'Talent' abilities, as I don't yet know how approach it.

[battlestar]

Thanks! I'll look through it asap.


For leadership, sorry I didn't make it clear: Please make it leadership lvl3, definitely don't let it get to leadership lvl25

Yeah, changing the max exp with an [event] that follows level up makes more sense than having it in AMLA.

Quick action: I'll take a look at the codes ASAP and think of something.

Abilities related to spells and runes: Please just leave them (such as "talent") as dummies, they'll have to wait for the spell and skill system to take shape.

[The_Other]

I know why Quick Action isn't working, but I'm not on my own computer so I can't do anything about it...
The event (in the AMLA utils) needs to be defined as a macro and called from elsewhere (scenario or unit file - use Valia, if she is in every scenario, or else every hero). I even thought of this while I was writing it, but wasn't sure if it was necessary or not.
In this case, Training probably doesn't work either for the same reason. I will fix this, and change Leadership as requested, later on tonight.