forum.freeciv.org

An amazing approach! I myself am not great in scenario making but it's interesting to see how far you can get with what we currently have.

Yes, the lack of ability of setting the team of a player on creation is pitiful.

The diplomacy control (disabling for specific nations) happens on ruleset level, with "NoDiplomacy" effect, alas no way to record into a scenario without a ruleset attached.

But the other thing to control AI behaviour is player#.ai section in the savefile, each line related to another player: as long as "countdown" is negative and the diplomatic state is "war", the AI will refuse any meetings; though I am not completely sure can it be reset by some event. Positive value with no "war" says that a declaration is planned in that number of turns but it surely can be canceled if AI sees no good reasons to attack. "love" value (-1000...1000) shows affection level, with values over 700 it's really difficult to provoke an agression; it can be controlled by turns with "AI_Love" effect but alas still no API. Other data there relate to diplomatic meeting activity, I don't know what do they do. And, for sure, you have AI traits, they even have some API.

Thank you very much for the compliment! I hadn't thought about using the AI traits to try to influence tribe relations but I'll start by trying those since the ability to change the mod value is available via lua scripting. That was very helpful advice and much appreciated.

I've only just started on PacCampaign Level 2 so there isn't much in it yet but the file is attached.

I am planning the following for Level 2:

Pac will meet and ask of a settler to teach them how to form a settlement crew since Pac realizes that they (the Pac warriors) aren't settlers. The settler will agree, but only for 50 gold. I'm not certain if this is a good idea since it may give players who are new to Freeciv the wrong impression that warriors can become settlers. Perhaps bribing a Vampire settler might be better, but for that they need a diplomat.

The bonus/reward from the optional quest of staying to fight the barbarians on Level 1 will give Pac enough money to pay for the training.

The settler who trains Pac tells him a "good spot" to build (too close to the Vampires.)

Pac and friends then form into a settlement crew (a settler) and build their first town (preferably very close to the vampires town since I increased their expansionistic and aggressive traits after reading your post!)

Meanwhile, hopefully Pac will ally with the Werewolves. I think that I will increase their "trader" trait and maybe decrease expansionist trait.

Then WAR!

Forgot to mention: A survivor from the Vampire city on level 1, who had been outside the city when it was destroyed, fled to the west and informed the vampire clan there of the lost city. The survivor claims that he saw Pac and friends walking toward the vampire town and then the town was in flames a short time later. Vampire warriors confront Pac and crew, who deny having sacked the town, but the Vampires don't believe them and -state- that they are going to attack Pac ( <-- subtle method of trying to get the human player to attack the Vampires instead of accepting a cease-fire.)

Oh, and I used a Werewolf caravan next to Pac's starting tile to try to get the human player to cease-fire with the Werewolves immediately.


EDIT: Well, hmm. In several runs of all "A.I" controlled tribes on level 2 as it is, the "A.I." Pac allies with the Werewolves and goes to war with the Vampires every time, but the Vampires -also- became "helpful" toward Pac -every- -time- so it is still possible that a human player could choose to ally with the Vamps instead. So now I'm rethinking the whole storyline that I had in mind because it seems quite likely that a human player might make choices that would then make the dialogs seem ridiculous if I -expect- certain choices from the human. I think it would be better to have a storyline with -less- control by the scenario rather than more since I can't guarantee continuing diplomatic states among the tribes.

If I pre-select which tribes might be friends or enemies, then re-use those same tribes across levels, I also need to be able to force the same relationships to continue on the subsequent levels or it makes no sense - Werewolf allies on level 1 might go to war with Pac on level 2 if Pac allies with the vampires, and so on. Soooo, I'm now leaning toward not reusing the same tribes across levels which definitely limits opportunities for the larger storyline. Pac can't have long-lasting, on-going relationships with other tribes because I can't ensure that those relationships will continue to each new level. So when Pac leaves level 1, he -must- meet only new, different tribes on level 2, rather than the same tribes again. In which case, some of the things I set-up in level 1 like the destruction of the vampire city, no longer matter.

So I'm trying to come-up with a new storyline which works well with only Pac's tribe moving between levels and all new "A.I." tribes on each level. That shifts the narrative from the original long arc I had in mind to a series of smaller episodes. I think that that will be fine and it will also allow more variability within the game. On any level, whichever tribes Pac fights, or joins in an alliance will be completely up to the human player and those choices won't affect the next level. Quest results within a level can still be made to carry-over to the next level in the way that 2nd quest from level 1 results in a bonus on level 2. It's not perfect, but the only method of communicating between level 1 and 2 is through the human player, so hinting to the human on level 1, about a bonus on level 2 is the best carry-over method I can come-up with under the current circumstances.

• What I have learned about Freeciv Campaign creation so far:
• Using the "All" nationset with start position nations defined in the scenario file can be problematic. The "CORE" nationset avoids the problem but nation choices are far more limited. Setting the scenario "nationset" setting to ALL, then creating non-CORE tribes in the game via lua script seems to work fine.
• It's better to have only one player/nation specified in the scenario file (the nation for the human player) and then create other nations via lua script in the game so that the human can't possibly select the wrong nation when starting the scenario/level.
• Barbarians can be introduced into a scenario in multiple ways, through the settings in the scenario file, or via unleash_barbarians (random numbers of barbarians appear immediately, and more continue to appear repeatedly from that point on), or edit.create_player - all three methods have some issues. The edit.create.player method provides more control over the barbarians.
• There is currently no way to control the diplomatic relations between tribes either from the scenario file, nor from lua script. If the human player's tribe allies on level 1, then when the human plays level 2, the other tribe can't be automatically allied to the human player's tribe in level 2, and will greet the human's tribe as a total stranger which may be very confusing within a campaign. Using "saved games" or scenario files with players saved is problematic because the human player gets an option of selecting which tribe to take despite that in a scenario it is likely very important for the human to be only one specific tribe. Instructions to the player to select a certain tribe might work, or not.
• The only method of passing data from one level to the next is through the human player and that limits the style/type of campaign storyline. Telling the player, via pop-up message, something about the next level (where to find treasure, and so on), can work but is very limited. Directing the player to play "Campaign level 2a" vs. "Campaign level 2b" depending on outcome of level 1 can also work, and is also limited. For example, there is no way in the next level, to know how many units the player lost in the first level. So if level 1 begins with the player having 6 units, then 2 are destoryed by the end of level 1, level 2 would still open with 6 units since it can't know anything about what happened in level 1. Using lots of alternate versions of the level 2 scenario file could work there - "level 2a4.sav" = a indicates player won, and 4 indicates that 4 units survived but it could require a lot of files for every possibility which might seem daunting to a prospective Campaign player. It would be easier to begin every subsequent level with a message such as "A bunch of your friends showed up!" to explain why losses on any level don't carry over to the next.
• Simple, in-level quests are easy to set-up. Quests across levels/scenarios are possible but very limited due to the aforementioned problem of passing data between levels only being possible through the human player. (And there is -no- data input method to, for instance, give the player a code to enter at the beginning of the next level which could be decoded via lua script and provide data from the prior level (see inline pictures below.) Currently there isn't any method of user input except via "chat", but there doesn't seem to be any way of -reading- the chat entries by lua script.)

^ Fictional example of allowing Campaign scenarios to pass data between levels via Chat and lua script. This is not currently possible in Fc 2.6.x.

That would work -if- lua could read the last chat entry (which appears to be impossible currently.)

The fictional code explained: "0" is boolean value indicating player won the last scenario/level, and the second "0" indicates an in-level quest was completed in the prior level, "01" is unit type, "04" is quantity at end of prior level. "15" is the unit type for "Horsemen", "02" is the quantity.


EDIT: If edit.create_city is used to create a tribe's first city, it will not have a palace by default (at least not without "rebuild palace" enabled.) It seems easier to create a settler for the tribe and let them build the city.

EDIT 2: If you create caravans for a tribe, prior to their first city being built, the caravans aren't really caravans. No good for trade and can't even enter foreign cities.

I would much appreciate if you could formulate feature requests and/or bug reports to https://osdn.net/projects/freeciv/ticket/ based on you findings

^ I'm not yet sure exactly what I think would be the best option in every, or even any case. I'm still learning and more issues/options might yet arise and change my opinion of the best method of resolution for any situation. Once I am convinced that I've tried everything and know what is lacking, I will make an official request via the system. I'm posting as I go along in hopes that others might post their ideas and experiences too.

You may find these ones of the new 3.0 features useful once you update: ScenarioReserved player flag (makes player hidden / not selectable in pregame) and Stay unit flag (makes the unit unable to move, i.e., you can be sure that AI doesn't move it away from defending the spot where you set it)

^ Yep, I would've used that "stay" flag feature yesterday if 2.6 had it. Rather than blocking an "exit", I elected to disable the exit under pretext of it being closed for repair then when a particular quest is completed, re-enable the exit. The quest was for Pac to ally with any nation on level 2. Except then I realized that there doesn't seem to be any method to determine via lua script the diplomatic state between two players. Can't tell whether they are at war/cease-fire/peace/allied. So I'm leaning toward changing the quest to annihilating at least one tribe although that changes the "flavor" of campaign level 2 in the extreme... from Pac seeking peace, to seeking war.

I'm not much for early adoption of beta or even x.0 versions of software. I realize that someone ought to, I'm just generally pleased that I'm not one of them. I despise the "personal computer system" industry's "planned obsolescence for anticipated profit" leanings in general, which tends to make me least happy to use and support new versions of OS, for example, which drop support for prior systems/hardware etc. Not that Freeciv is in anyway culpable in that regard, but rather that the industry doing so has established within me an attitude and resolve contrary to fast adoption of anything "new".

EDIT: Thought about switching quest to "Establish trade routes with at least one other nation" but also doesn't seem to be possible, from lua script, to determine what trade routes exist, and between which cities.

An idea for v.3.1 data transfer, if we have no special tool for it then: just unzip level 1 final sav into level 2's luadata.txt. Actually, some way to load data from an arbitrary specfile (even better if not one per game) would be a great tool, and a really working one for this case if we could automatically specify the path. As I have speculated in the topic start, it would be currently difficult to do server-side, but for single-player campaigns we can load savs in a right and flexoble sequence from the client with rather easy mods.

An idea for current versions: cypher the key data in the final message of a level (space split+rot13 is enough), then pass them after loading level 2 in chat line with "/lua cmd campaigndata('paste_cypher_here')". campaigndata(cypher) is a function defined in each level sav to decypher data provided by the previous level.

^ File (and network) access are disabled for lua in Freeciv 2.6, for security reasons (there was a vulnerability at one time where anyone able to issue lua cmd's to the server could overwrite files.) I'm not sure that reading the final sav of the prior level would be worth the potential security fiascos that may result by enabling lua file access. But, if data could be passed -solely- via a persistent Freeciv server log file, then campaign scenario level 1 could write data to the log (using lua log.normal() for instance), level 2 could ask Freeciv app (via a "built-in" function) to hand-over as a string, any/every line of the log file beginning with "PacL1:" from dates 10/[1,2,3]/2021 (or maybe just within the last X number of log entries. Or maybe only the last matching line if all needed data for the next scenario can be combined into a single line?) Then lua still wouldn't have file access, only the Freeciv app would (as it already does), but data could still be passed through the log file.

I thought of a way of handling Jericho, for your campaign idea - but it needs the ability to change terrain tile type from inaccessible to desert (sand) which is available in Freeciv v3 but not in 2.6, which answers my original question "Why wait?"

EDIT: It just occurred to me that it might be possible (in v3) to use the terrain change feature to completely change the entire map in a scenario -- transform the original level 1 map into a level 2 map in the same scenario without having to load a separate level 2 scenario. Just loop through all lines and all tiles in each line and change each until the map is completely different. Then an entire campaign could be a single scenario file. I tried to find any info on maximum string length in lua and couldn't, but did find a wiki article stating that lua can process strings greater than 230,000 characters in length (they were using lua to edit wiki pages). So even a massive 230K tile map would be possible, but every level of the scenario would have to fit within the original level's map dimensions - so if one level is a smaller area, it could be padded with ocean and centered but any level too large for the initial map x,y sizes wouldn't fit at all. The lua scripts in the files would have to be wrapped in a conditional such as "if ( level == 1 ) then ; if (turn == 0)" and so on so that the scripts for level 1 only affect level 1.

Molo_Parko wrote:^ File (and network) access are disabled for lua in Freeciv 2.6, for security reasons (there was a vulnerability at one time where anyone able to issue lua cmd's to the server could overwrite files.) I'm not sure that reading the final sav of the prior level would be worth the potential security fiascos that may result by enabling lua file access. But, if data could be passed -solely- via a persistent Freeciv server log file, then campaign scenario level 1 could write data to the log (using lua log.normal() for instance), level 2 could ask Freeciv app (via a "built-in" function) to hand-over as a string, any/every line of the log file beginning with "PacL1:" from dates 10/[1,2,3]/2021 (or maybe just within the last X number of log entries. Or maybe only the last matching line if all needed data for the next scenario can be combined into a single line?) Then lua still wouldn't have file access, only the Freeciv app would (as it already does), but data could still be passed through the log file.

Surely, arbitrary file access is too big a hole. Such an access should exist only to specific Freeciv directories or to files manually selected in a dialog. What I talked about was a configuration file and a savefile, the latter should be accessible only if it is just recorded or loaded. "/lua cmd ...", for a note, is accessible to players with "hack" access levels, i.e. in local games.

it might be possible (in v3) to use the terrain change feature to completely change the entire map in a scenario -- transform the original level 1 map into a level 2 map in the same scenario without having to load a separate level 2 scenario. Just loop through all lines and all tiles in each line and change each until the map is completely different. Then an entire campaign could be a single scenario file.

Yes if you agree to go without resizing the map, changing ruleset or doing any other things not yet supported by Lua (and some of them are not supported even in far plans). Actually, that seems to be not a great limitation. It's even possible to include level saver and changer into the script so you can still create the levels in the Gtk* client editor. One of the problems in 3.0 is no script control of tile knowledge, your player will see old tiles beyound its vision radii, or you can move around a unit and show it the new tiles, but no chance to make the tiles black again (I have filed a feature request for it, maybe we'll have it in 3.1).