Development: Scarlet Sea [campaign]

[Ceres]

Here they are. They might be a bit outdated, because I didn't want to overwrite possible modifications I did to them to ease testing.

[battlestar]

Thanks, I think these will help me figure out what's going on.

[battlestar]

@Pyro:

Corresponding SVN updated for relevant files.

The following changes were not made:

- #10 in script, If the chained man was rescued and subsequently defeated in scn-2 part isn’t incorporated yet.
- remaining necromancer skills
- Resurrection of the same destroyed skeletal dragon after 4 turns?
- your idea for the fog besides incorporation of what you already had. I really like them and looks promising. Even if it end up not being able to replace the original fog, we could at least keep the "shadow bomb" as a special attack for second necromancer brother, and black cloud when any necromancer teleports.
- I couldn't get the towers to convert to side=1 for some reason, though they still function OK.

Thanks, and happy holidays!

[battlestar]

@ Pyro: I've been looking at Crendgrim's rpg campaign and his inventory system in particular. When the inventory is opened, the entire map is replaced with an "inventory map", and when the inventory is closed, the entire map is restored. This means it would have to interact with each scenario intimately. Could you help me brain storm a bit on potential issues in connecting his inventory system to our scenarios?

1) The map and terrains
- Closing inventory needs to restore current terrains in scenario, especially if there are any terrains have been modified mid-scenario (ie. ice freezes over river).

2) The image and halos
- Restoring current images and halos (I suppose they are the same thing), especially to make sure they would still be animated after restoration

3) The Units
- Restoring units on the map as they were (think store and unstore would work).
- Doesn't affect events that involve units (I don't think there should be a problem as long as variables in units stay the same).

4) The events
- I foresee that this inventory system would affect events that involve locations. And extra care would be taken to make sure events only be fired when inventory is closed.
- Doesn't affect any other events (any other situations to consider?)

Thanks, and input from anyone is welcome.

[Crendgrim]

If you manage to convert my system to work with your campaign (or re-implement it in a similar way), you won't have to care about all these points, as I already dealt with them. I am storing/unstoring the current map with all images, halos, and units. For events, you could just use a variable "in_inventory" and some [filter_condition] tags in the events.
I know you asked me for help porting the system, and I apologize for not finding any time for WML during the last months.

[pyrophorus]

Hi !
First of all, I think you correctly listed all the "difficult" points of such a system.
I don't know the Crendgrim system, but, as he said, everything can be managed. I don't wonder how. I wonder how it can be used in scenarios without turning them into a gas plant.
There are two not obvious problems:

• saving and restoring the map changes.
• disabling and enabling 'moveto' events.

This imply the scenario is specially written to manage these (this add complexity, i.e. increase development time and bug probability). Crendgrim suggested something correct to deal with 'moveto' events, but this means the condtion must be added at least to all 'moveto' events, and maybe more (we could have interactions with 'die' events too).
If I had to develop such an inventory system, I would not use any unit or unit moves on the inventory map (to avoid the 'moveto' problem) and use only items and right-clicks on them to manage the inventory. AFAIK, other authors did develop an inventory system: Heindal in Five Fates, Artisticdude in Aeranor Book, and maybe Bob the Mighty in Atlaz Mariners (I don't remember if ii is a special map or only a message/option system). I would suggest to look at them too. It could save a lot of work, not only in the system itself, but in scenarios too.

Friendly,

[battlestar]

Initially I did think about a message based system as in Five Fates and Aeranor Book, both of which are well developed message/option systems. If we end up going for message/option I'll try to implement Aeranor Book's. I'll look into Altaz Mariners when I install the required Wesnoth version.

I like Crend's setup because it's very straight forward to operate compared to message/option systems. It also makes interaction with shops and chests more natural. Though I think Crend's inventory pretty much bases on unit and unit moves, and that's partly why it's easier to use.

Your suggested solution with right click operation is very good, it's just that I don't think I have the capability to make that kind of alteration to his codes (within a reasonable time frame - big learning curve for me because most of his codes are in lua, and we'll need extra codes to deal with item sorting within the inventory if player has no direct control over where items are placed in the bag).

Though this is probably not the best form, but here's my idea for solution (incorporating what Crend said):
- Keep an "in_inventory" boolean variable in each scenario
- make a macro that contains [filter_condition] for in_inventory, and keep it in our "syntax.cfg"
- Place this macro in all events except for ones that are obviously non-conflicting (this way we won't have to think too hard about whether the inv interferes with each event)
- I don't think this will significantly adversely affect the game play.
- If you think it could work, you could either make future events with the said macro, or do as you've done before and I'll add it later when I'm testing the events.
- Don't worry about the completed events and I'll take care of those.
- If not, let's talk more about alternative options.