The Battle for Wesnoth Forums

Hello, First let me start by saying that I am by no means a combat expert, and this is just my "Hollywood-infected" view of the technical details of armed fights :) I think it would enrich Wesnoth's combat system, and open up room for some very interesting combos, to allow an attack to have multiple...

It doesn't seem to be recognized inside [scenario]. I don't have goals here, and we strayed way off the original topic, I was just merely wondering if having the option to set base_income in [scenario] could be more convenient than having to set income for each side one by one, if for example, someo...

I tried it today on 1.14.5, base_income does nothing inside [scenario], so the MP screen probably works differently. Could it be a room for improvement then, that the [scenario] tag should accept base_income?

Celtic_Minstrel wrote: ↑

October 3rd, 2019, 4:20 am

Doesn't base_income= also work in the scenario tag?

Well, it is not mentioned in the scenario wiki, and I never tried to use such key there, so I honestly don't know. I could test it some time if I don't forget.

That's strange. Are you sure are using the syntax right? I'm asking because it's a little bit confusing: Inside [object], the "name" is supposed to be the id key, but inside [remove_object], you must refer to it as object_id ! That's because id here means the id in standard unit filter, and that is ...

Yay, delayed_variable_substitution=no works and solved it Apparently it exists then, but for some reason, yes is the default value here in [tunnel]. I must note, I'm not sure if it's the best default value. For now I'll add the key to the wiki.

No, that's not it. The two codes you pasted are identical. [not] is like [and], but with a false expectation, so several not's after each other work as expected. Also, the item appear fine on the locations, and the printf also finds legal locations. On the other hand, I also wanted to check on the v...

I'm not sure what you mean. base_income is a key inside game_config.cfg (described here), not in scenarios. If you want to set a side's income to 0, use [side] income=-2 instead. (since base income is +2, and side income is added to that).

Hello, I'm having a bit of trouble making some tunnels appear. The idea is to store some locations, then select the sources and targets randomly. Currently, I'm just testing for 1 random tunnel, because that doesn't work already. Here is the code: event=prestart .... [store_locations] x=37-75 y=5-36...

The upkeep key is generally not for the coder to mess with, as far as I know. Other background mechanisms access it, that's why it resets. Instead, you could use an object set a unit to loyal "silently" (without the visible trait). [unit] # unit values [modifications] [object] id=loyalty [effect] ap...

In this case I managed to place the loyal trait in modification but when I wanted to assign to 8 the movements of this unit and that of the leader, it does not allow me [modifications] has a little bit different meaning, it's not where you can "modify" a unit, it's the group where [traits], [object...

1) I did not test your code, I'm just looking at it, but I think your filters are not precise enough. In the unit placed event, if the store_unit finds multiple units, and it will do that, I'll explain soon, than indeed array.attribute is (I think) array[0].attribute, which is the dead unit which ha...

Sorry for the late answer, I've been away for a couple of weeks. I'm sorry for the late reply as well, but I was lots of miles away from this PC :) Just quoting for visibility. In the meantime I came across this topic, and also saw the post about 1.15.1 being release, where a particular bug, carrie...

For whatever reason, it doesn't seem to work either. I also tried using quotes around the ID just in case. I even tried using the [side] ID to see if that would work. The result: None of the leaders gain access to the Unique_Unit for recruitment in any of these cases. That's strange. If all suppose...

I think it makes sense, yes. It basically means, that your recall list gets the same "treatment" at the end of the scenario that your units on the battlefield get. To which I'd say it's fair.