[Wesnoth-bugs] [bug #25064] Unit image bugged on cave bridge

URL: Summary: Unit image bugged on cave bridge Project: Battle for Wesnoth Submitted by: tekelili Submitted on: jue 15 sep 2016 10:28:44 UTC Category: Bug Severity: 2 - Minor

[Wesnoth-bugs] [bug #24554] Become has_weapon= key into a subtag of [filter]

URL: Summary: Become has_weapon= key into a subtag of [filter] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mié 06 abr 2016 09:42:43 UTC Category: Feature Request

[Wesnoth-bugs] [bug #24327] Unconsistent behavior rounding unit´s buff

URL: Summary: Unconsistent behavior rounding unit´s buff Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 18 ene 2016 20:30:56 UTC Category: Bug Severity: 3

[Wesnoth-bugs] [bug #23721] add support for key first_scenaraio_only=yes to [event]

Follow-up Comment #8, bug #23721 (project wesnoth): Thanks a lot :) ___ Reply to this item at: ___ Mensaje enviado vía/por Gna! http://gna.org/ _

[Wesnoth-bugs] [bug #23922] Reopening bug #22774 (insert_tag)

URL: Summary: Reopening bug #22774 (insert_tag) Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 05 oct 2015 23:52:55 UTC Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #23920] add advanced configuration option: "not try to overwrite saves"

Follow-up Comment #1, bug #23920 (project wesnoth): Just to be clear, I am talking about autosaves. ___ Reply to this item at: ___ Mensaje enviado vía/por Gna!

[Wesnoth-bugs] [bug #23920] add advanced configuration option: "not try to overwrite saves"

URL: Summary: add advanced configuration option: "not try to overwrite saves" Project: Battle for Wesnoth Submitted by: tekelili Submitted on: dom 04 oct 2015 02:31:32 UTC Category: Feature Req

[Wesnoth-bugs] [bug #23841] a [make_tag] tag to create custom wml tags.

Follow-up Comment #1, bug #23841 (project wesnoth): It you any doubt about its usefullness I can tell you I have dreamed with something like this beign implemented for years :) ___ Reply to this item at: ___

[Wesnoth-bugs] [bug #23779] add support for key "mode=insert" to [object]

Follow-up Comment #1, bug #23779 (project wesnoth): I guess [object] mode=insert would be irrelevant (or not possible to behave correctly when applied), but it would be still usefull decide order of objects for the moment unit levels up. ___

[Wesnoth-bugs] [bug #23779] add support for key "mode=insert" to [object]

URL: Summary: add support for key "mode=insert" to [object] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mié 12 ago 2015 04:39:07 UTC Category: Feature Request

[Wesnoth-bugs] [bug #23739] [event] in [side] doesn't work

Follow-up Comment #4, bug #23739 (project wesnoth): It is barely related, but I would like to ask again for documentation about [event]. If I want to know if something like... [event] name=preload [/event] ...would work inside [side], I would have not clue about it by just reading wiki. I w

[Wesnoth-bugs] [bug #23735] add support for key standing_animation=no to [unit]

Follow-up Comment #1, bug #23735 (project wesnoth): Most of standing animation resemble some kind of fatige/inercy/breathing due to combat/movement activity. However qute often scenarios have AI units with "guadian status"; units with 0 max_moves wich will combat but wont move at all in any scenar

[Wesnoth-bugs] [bug #23735] add support for key standing_animation=no to [unit]

URL: Summary: add support for key standing_animation=no to [unit] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: sáb 01 ago 2015 00:24:02 UTC Category: Feature Request

[Wesnoth-bugs] [bug #23721] add support for key first_scenaraio_only=yes to [event]

Follow-up Comment #5, bug #23721 (project wesnoth): Thanks for clarification, I will for sure use [remove_event] :) ___ Reply to this item at: ___ Mensaje enviad

[Wesnoth-bugs] [bug #23721] add support for key first_scenaraio_only=yes to [event]

Follow-up Comment #3, bug #23721 (project wesnoth): (I am not expert in savegames, so I could be wrong) In my experience use of [remove_event] does not solve problem at all, as event will be still present in save file. Otherwise, how could a replay file be generated from save file as it can be don

[Wesnoth-bugs] [bug #23721] add support for key first_scenaraio_only=yes to [event]

Follow-up Comment #1, bug #23721 (project wesnoth): Btw, note existence of [insert_tag] in WML. When I say "loading variables" it can means "loading code". So that "chunk" can be really long. ___ Reply to this item at:

[Wesnoth-bugs] [bug #23721] add support for key first_scenaraio_only=yes to [event]

URL: Summary: add support for key first_scenaraio_only=yes to [event] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mar 28 jul 2015 15:29:18 UTC Category: Feature Request

[Wesnoth-bugs] [bug #23670] Language settings not persistent after exit BfW

Follow-up Comment #4, bug #23670 (project wesnoth): I have been testing again, and it looks like I had very special conditions while testing: BfW was downloaded 5 minutes ago. I mean probably bug I detected only happens until user open preferences for first time or something like that. I think it

[Wesnoth-bugs] [bug #23675] Replays not saved after [endlevel] result=victory

URL: Summary: Replays not saved after [endlevel] result=victory Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 03 jul 2015 20:24:39 UTC Category: Bug Seve

[Wesnoth-bugs] [bug #23671] Disable music in Preferences crash BfW

Follow-up Comment #5, bug #23671 (project wesnoth): I used files from first attach in your forum post http://files.wesnoth.org/vorbis-dev.zip ___ Reply to this item at: __

[Wesnoth-bugs] [bug #23671] Disable music in Preferences crash BfW

Follow-up Comment #3, bug #23671 (project wesnoth): I replaced both .dll files suggested and bug looked fixed. ___ Reply to this item at: ___ Mensaje enviado vía

[Wesnoth-bugs] [bug #23671] Disable music in Preferences crash BfW

URL: Summary: Disable music in Preferences crash BfW Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 29 jun 2015 13:26:33 UTC Category: Bug Severity: 5 - Bl

[Wesnoth-bugs] [bug #23670] Language settings not persistent after exit BfW

Follow-up Comment #2, bug #23670 (project wesnoth): After more test, it looks like bug can always be reproduced with these steps - Launch BfW - Select Language option and set a new one - Inmediatly select exit option - Lauch BfW again (Language change is not preserved) __

[Wesnoth-bugs] [bug #23670] Language settings not persistent after exit BfW

Follow-up Comment #1, bug #23670 (project wesnoth): After several times experiencing bug, it becomed suddenly solved. I suspect it could be due to me opening by first time "Preferences" menu option and closing after made a change. ___ Reply

[Wesnoth-bugs] [bug #23670] Language settings not persistent after exit BfW

URL: Summary: Language settings not persistent after exit BfW Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 29 jun 2015 12:35:49 UTC Category: Bug Severit

[Wesnoth-bugs] [bug #23663] autopath should prefer ocupied hexes

URL: Summary: autopath should prefer ocupied hexes Project: Battle for Wesnoth Submitted by: tekelili Submitted on: jue 25 jun 2015 14:12:06 UTC Category: Bug Severity: 2 - Mino

[Wesnoth-bugs] [bug #23636] add to [generator] key terrain_liked=no

Follow-up Comment #9, bug #23636 (project wesnoth): Thanks a lot for suggesting use key inside [side], it looks like is working perfectly :) I should have tested it before, as I had this idea from the very begining, but as I was dealing with a "random bug" with unknown procedence and frecuence, I

[Wesnoth-bugs] [bug #23636] add to [generator] key terrain_liked=no

Follow-up Comment #6, bug #23636 (project wesnoth): I guess this becomed a bug report rather than a feature request. Will modify_plcing key behavior be fixed in future 1.12 release? ___ Reply to this item at:

[Wesnoth-bugs] [bug #23636] add to [generator] key terrain_liked=no

Follow-up Comment #3, bug #23636 (project wesnoth): By interference I mean it can cause different side number for starting positions when sides are greater than castles generated (wich screw my sceneraios btw). It is... modify_placing=no ...a current tag or a proposal? It is not listed in wiki,

[Wesnoth-bugs] [bug #23636] add to [generator] key terrain_liked=no

Follow-up Comment #1, bug #23636 (project wesnoth): I key for [side] could also solve issue, I guess ___ Reply to this item at: ___ Mensaje enviado vía/por Gna!

[Wesnoth-bugs] [bug #23636] add to [generator] key terrain_liked=no

URL: Summary: add to [generator] key terrain_liked=no Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 05 jun 2015 14:48:54 UTC Category: Feature Request Sev

[Wesnoth-bugs] [bug #23500] remove [item]s by id

Follow-up Comment #8, bug #23500 (project wesnoth): Well... if just is in stderr.txt but not in game screen, then I guess I am getting the same. It is that a relevant problem? I am living probably with it and didnt notice anything wrong. ___

[Wesnoth-bugs] [bug #23500] remove [item]s by id

Follow-up Comment #4, bug #23500 (project wesnoth): In fact I realized you can probably just BLIT the false id image after your one and will work; wich is more simple than my first proposal. ___ Reply to this item at:

[Wesnoth-bugs] [bug #23500] remove [item]s by id

Follow-up Comment #3, bug #23500 (project wesnoth): I didnt test exactly it, but I am using a similar technique in add on World Conquest II for different proposes and it works. If my advice give errors, then try by using a valid image as first one (I mean, BLIT ir in images/misc/blanck.png). I ca

[Wesnoth-bugs] [bug #23500] remove [item]s by id

Follow-up Comment #1, bug #23500 (project wesnoth): Currently you have a work around for this rare issue using IPF. Lets say you have a copy of misc/blank.png on your add on called "my_blank.png" Then you can place images with "id" like this [item] image=id1.png~MASK(my_blank.png)~BLIT(gold

[Wesnoth-bugs] [bug #23475] documentate executing order of [event]

Follow-up Comment #7, bug #23475 (project wesnoth): I am right now relaying for 1.12 in [era] events being fired before [modification] ones. It looks both intuitive and usefull behavior. That is why I asked for documentate it, as long there is none "expected behavior", I can not ask for a bug fix

[Wesnoth-bugs] [bug #23475] documentate executing order of [event]

Follow-up Comment #5, bug #23475 (project wesnoth): I think would be usefull [modification] were written by key "id=" order, like [set_menu_item] does. That way a coder could have some control about its own modifications coordination. Anyway I dont need such uber control rightnow, what it is more

[Wesnoth-bugs] [bug #23475] documentate executing order of [event]

Follow-up Comment #2, bug #23475 (project wesnoth): edit of previous post It is also not clear... [side] [unit] [event] [/event] [/unit] [/side] ...in wich moment will be writed ___ Reply to this item at:

[Wesnoth-bugs] [bug #23475] documentate executing order of [event]

Follow-up Comment #1, bug #23475 (project wesnoth): Oh, also is not clear... [side] [unit] [event] [/event] [/unit] [/side] ...in wich moment will be writed ___ Reply to this item at:

[Wesnoth-bugs] [bug #23475] documentate executing order of [event]

URL: Summary: documentate executing order of [event] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 13 abr 2015 15:01:43 UTC Category: Feature Request Seve

[Wesnoth-bugs] [bug #23457] add key to disallow "shuffle sides" for [scenario]

Follow-up Comment #3, bug #23457 (project wesnoth): Btw, after more testing, what I firstly indentificated as a collusion with code to check sides, looks now more like a problem with empty hidden [side] ...so more reasons for a key to [side] rather than [scenario] :) ___

[Wesnoth-bugs] [bug #23457] add key to disallow "shuffle sides" for [scenario]

Follow-up Comment #2, bug #23457 (project wesnoth): I Agree Chris, a key for [side] is more handly. ___ Reply to this item at: ___ Mensaje enviado vía/por Gna!

[Wesnoth-bugs] [bug #23457] add key to disallow "shuffle sides" for [scenario]

URL: Summary: add key to disallow "shuffle sides" for [scenario] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mié 08 abr 2015 21:28:21 UTC Category: Feature Request

[Wesnoth-bugs] [bug #23454] Variables not loaded for observers after scenario trnasition

Follow-up Comment #10, bug #23454 (project wesnoth): Thanks a lot :) ___ Reply to this item at: ___ Mensaje enviado vía/por Gna! http://gna.org/

[Wesnoth-bugs] [bug #23454] Variables not loaded for observers after scenario trnasition

Follow-up Comment #8, bug #23454 (project wesnoth): I have finally reproduced bug sucessfully. It looks like is the random map campaign structure wich cause it. [multiplayer] [generator] [scenario] [/scenario] [/generator] [/multiplayer] I attach file with scenario test

[Wesnoth-bugs] [bug #23454] Variables not loaded for observers after scenario trnasition

Follow-up Comment #5, bug #23454 (project wesnoth): Just to be precise, I got unstored named ""observers dont see this name" in local game. But i got unstored unit named "tekelili" in multiplayer server 2. Btw, how can I do that cool yellow window to paste code? _

[Wesnoth-bugs] [bug #23454] Variables not loaded for observers after scenario trnasition

Follow-up Comment #4, bug #23454 (project wesnoth): I am now confused, I have modified your test, but what I got is different outcome in multiplayer server than in local game... for the game host! #ifdef MULTIPLAYER [multiplayer] id= "MP_OBS_SYNC_TEST" name= _ "MP Sync Test 1"

[Wesnoth-bugs] [bug #23454] Variables not loaded for observers after scenario trnasition

Follow-up Comment #2, bug #23454 (project wesnoth): Hum, looks like your test is not doing nothing with variables at scenario2 that would cause a different status for observes that can be spoted? ___ Reply to this item at:

[Wesnoth-bugs] [bug #23454] Variables not loaded for observers after scenario trnasition

URL: Summary: Variables not loaded for observers after scenario trnasition Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mié 08 abr 2015 01:23:06 UTC Category: Bug

[Wesnoth-bugs] [bug #23447] ~BLIT not working correctly

Follow-up Comment #1, bug #23447 (project wesnoth): I can confirm this bug. In fact I didnt think it was a bug... just a primitive implementation, and I have used CROP lot of times to workaround it... lol ___ Reply to this item at:

[Wesnoth-bugs] [bug #23410] Do no ask user to enable forced modification

Follow-up Comment #6, bug #23410 (project wesnoth): @Chris: Use force_mofication will not remove era chosen by user unless [modification] uses disallow_era, in wich case user would be warned as I am not asking to remove that "question". ___

[Wesnoth-bugs] [bug #23410] Do no ask user to enable forced modification

Follow-up Comment #4, bug #23410 (project wesnoth): Just to say it with other works, if you wont ask user: "do you agree in load code inside [scenario][/scenario] in order to play?" then why you ask about... [scenario] force_modificatio= [/scenario] From my point of view, force_modification code

[Wesnoth-bugs] [bug #23410] Do no ask user to enable forced modification

Follow-up Comment #3, bug #23410 (project wesnoth): I dont think user should be punished with a useless extra click just to make debug easir. If I use force_modification, I am saying that is a core part of scenario and wont work without it. I dont see how user can profit from be asked about load

[Wesnoth-bugs] [bug #23410] Do no ask user to enable forced modification

URL: Summary: Do no ask user to enable forced modification Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mar 24 mar 2015 13:22:18 UTC Category: Feature Request

[Wesnoth-bugs] [bug #23399] Error when starting a campaign after multiplayer.

Follow-up Comment #3, bug #23399 (project wesnoth): Apologize for my lack of known. Anyway, if [campaign] has a key define= and is able to define a macro, I guess [campaign] could also #undef MULTIPLAYER ___ Reply to this item at:

[Wesnoth-bugs] [bug #23399] Error when starting a campaign after multiplayer.

Follow-up Comment #1, bug #23399 (project wesnoth): Disclaim: I have no detailed clue, so sorry if question is stupid. Wouldnt be better just #undef MULTIPLAYER #ifdef CAMPAIGN? ___ Reply to this item at: _

[Wesnoth-bugs] [bug #23386] Change ford terrain code to Wf

Follow-up Comment #1, bug #23386 (project wesnoth): As side note, my proposal would complicate current filter terrain=Ww* ...it would become terrain=Ww*,Wf,Wr* But in my experience, I almost never wanted use such filter. ___ Reply to this

[Wesnoth-bugs] [bug #23386] Change ford terrain code to Wf

URL: Summary: Change ford terrain code to Wf Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 13 mar 2015 11:40:13 UTC Category: Feature Request Severity: 1

[Wesnoth-bugs] [bug #23378] [delayed_massage] tag

Follow-up Comment #1, bug #23378 (project wesnoth): I think you can already do that with: [event] name= side turn X [message] [/message] [/event] ___ Reply to this item at: _

[Wesnoth-bugs] [bug #23345] remove preload event

Follow-up Comment #14, bug #23345 (project wesnoth): I am just doing what looks more comfortable and clean. I had a lot of eventn name=prestart because I was writting them directly inside [scenario]. Once I dediced load them from variables, use event name=preload looked by far more easy rather tha

[Wesnoth-bugs] [bug #23345] remove preload event

Follow-up Comment #12, bug #23345 (project wesnoth): I use preload instead prestart because my add on have several name=prestart events that wouldn´t work beingn loaded from prestart. I use first_time_only=no because wiki says it is mandatory such key in preload events. _

[Wesnoth-bugs] [bug #23345] remove preload event

Follow-up Comment #10, bug #23345 (project wesnoth): This macro is present currently in 60 scenarios of my add on #define WORLD_CONQUEST_TEK_SCENARIO_EVENTS [event] name=preload id=WCT_Scenario_Events first_time_only=no [insert_tag] name=event variable=enemy_army.e

[Wesnoth-bugs] [bug #23345] remove preload event

Follow-up Comment #9, bug #23345 (project wesnoth): I am currently making use of preload event in add on "World Conquest II" Reason for use preload event is load all campaign events from scenario variables, and reduce considerabily memory space taken for multiple possible scenarios (each new scen

[Wesnoth-bugs] [bug #23334] add key "version=" to [era] and [modification]

Follow-up Comment #3, bug #23334 (project wesnoth): I think its important that each individual part of the add-on can have a different version number. From my development experience, a new version of [scenario] often maintains the same version of [era] and [modification] and (dependending how dev

[Wesnoth-bugs] [bug #23334] add key "version=" to [era] and [modification]

Follow-up Comment #1, bug #23334 (project wesnoth): I am always meaning for "require_modification=yes" coordinated use ___ Reply to this item at: ___ Mensaje env

[Wesnoth-bugs] [bug #23334] add key "version=" to [era] and [modification]

URL: Summary: add key "version=" to [era] and [modification] Project: Battle for Wesnoth Submitted by: tekelili Submitted on: sáb 28 feb 2015 18:14:17 UTC Category: Feature Request

[Wesnoth-bugs] [bug #23287] Small tweak to traits description format

URL: Summary: Small tweak to traits description format Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 16 feb 2015 18:02:01 UTC Category: Feature Request Se

[Wesnoth-bugs] [bug #23260] Add tooltips to recruit dialogue

Follow-up Comment #1, bug #23260 (project wesnoth): I support this request for recall menu. In my add on, I am giving an "informative" trait. This trait named "trained" have info about buffs chosen from a random pool, and user have no clue wich beneficts provide without using tooltip. As tooltip i

[Wesnoth-bugs] [bug #22974] hidden modifications and force_modification for campaigns

Follow-up Comment #2, bug #22974 (project wesnoth): it would be also very hepfull if such [modification] could have [variables] tag. Currently my {MY_COOL_LIBRARY} takes more space than {MY_COOL_EVENTS} and it is also multiplied by 3 space it consumes.

[Wesnoth-bugs] [bug #22974] hidden modifications and force_modification for campaigns

Follow-up Comment #1, bug #22974 (project wesnoth): I have realized a hidden forced modification would be really usefull to not bloat BfW with complex campaigns. I am currently developing a campaign with 5 scenarios that have lot of alternative maps for each scenario. Writing {MY_COOL_EVENTS} in e

[Wesnoth-bugs] [bug #23236] variable substitution not work for "layer=" key

URL: Summary: variable substitution not work for "layer=" key Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 02 feb 2015 03:08:21 UTC Category: Bug Severit

[Wesnoth-bugs] [bug #23084] AI fails to attack unit with high XP

Follow-up Comment #1, bug #23084 (project wesnoth): I think this is false. I have watched several times AI attack units that just need 1 XP to level. I dont know AI engine details, but it looks consider possible retaliation and attacks to level target withou chance to kill when amount of retalatio

[Wesnoth-bugs] [bug #22774] Modify default behavior of [insert_tag] for empty variables

Follow-up Comment #5, bug #22774 (project wesnoth): I accept gain is not too big to change [insert_tag] if is too complicated. I think current behavior is not reasonable (almost a bug) and can not imagine a coder expecting it and having profit... but can mostly be worked around with my macro insid

[Wesnoth-bugs] [bug #23061] Make possible undelayed substitution with "delayed_variable_substitution=yes"

Follow-up Comment #2, bug #23061 (project wesnoth): i see... possible walk around in previous post looks quite reasonable, and if my wish is difficult to implement I then dont see reason for it. I think this report can be closed. ___ Reply

[Wesnoth-bugs] [bug #23061] Make possible undelayed substitution with "delayed_variable_substitution=yes"

URL: Summary: Make possible undelayed substitution with "delayed_variable_substitution=yes" Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 12 dic 2014 09:32:49 UTC Categor

[Wesnoth-bugs] [bug #23042] Lawful Heavy Infantryman not getting -25% damage at night

Follow-up Comment #1, bug #23042 (project wesnoth): I loaded replay just to check what anyone could imagine: Heavy Infantryman has trait "fearless" (if you mouseover that trait, it explains unit has not penalty at unfavourable time) ___ Rep

[Wesnoth-bugs] [bug #23019] Mounted units incorrectly scaled in recruit list

Follow-up Comment #10, bug #23019 (project wesnoth): sorry, IMP was mean to be IPF (image path function) ___ Reply to this item at: ___ Mensaje enviado vía/por G

[Wesnoth-bugs] [bug #23019] Mounted units incorrectly scaled in recruit list

Follow-up Comment #9, bug #23019 (project wesnoth): Imho have this images at 100x100 is an uneccesary standar breaking that can only lead to more visual bugs and UMC inconvenience when scaling images. If for some reason some part of code like animation (I just guessing, really no clue) need image

[Wesnoth-bugs] [bug #23019] Mounted units incorrectly scaled in recruit list

Follow-up Comment #7, bug #23019 (project wesnoth): I just realized my guess was very easy to test. I resized cavalryman.png and replaced image in BfW folder. It looks kk in recruit list with new one. (file #23023) ___ Additional Item Attac

[Wesnoth-bugs] [bug #23019] Mounted units incorrectly scaled in recruit list

Follow-up Comment #6, bug #23019 (project wesnoth): Just to make sure you understand me, I think source of bug is that units like cavalryman have "unnecessary" size larger than 72x72 and are "unnecesary" becomed smaller due to "unnecessary" blank space surronding them. ___

[Wesnoth-bugs] [bug #22968] Reload in multiplayer severe bugs

Follow-up Comment #3, bug #22968 (project wesnoth): From Chris coment I realized was amistake report several bugs (I was afraid they looked minor bugs separately, when joined make play MP campaigns a nightmare). I dont know well how this site works... can someone delete this report and I do separ

[Wesnoth-bugs] [bug #22968] Reload in multiplayer severe bugs

URL: Summary: Reload in multiplayer severe bugs Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mar 18 nov 2014 12:08:19 UTC Category: Bug Severity: 4 - Importa

[Wesnoth-bugs] [bug #22918] Translations dont work for observers

URL: Summary: Translations dont work for observers Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 07 nov 2014 15:30:43 UTC Category: Bug Severity: 2 - Mino

[Wesnoth-bugs] [bug #22917] Stone bridge (Bsb) broken transition

URL: Summary: Stone bridge (Bsb) broken transition Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 07 nov 2014 01:03:41 UTC Category: Bug Severity: 3 - Norm

[Wesnoth-bugs] [bug #22907] Wish: add dummy overlay

Follow-up Comment #2, bug #22907 (project wesnoth): Sorry for triple post... just also note that a dummy overlay would be also a very useful tool for [generator] ___ Reply to this item at: __

[Wesnoth-bugs] [bug #22877] require_modification not working

URL: Summary: require_modification not working Project: Battle for Wesnoth Submitted by: tekelili Submitted on: dom 26 oct 2014 15:16:06 UTC Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #22844] leader-expendable and hero overlays too similar

URL: Summary: leader-expendable and hero overlays too similar Project: Battle for Wesnoth Submitted by: tekelili Submitted on: mar 21 oct 2014 10:51:47 UTC Category: Feature Request

[Wesnoth-bugs] [bug #22828] [generator] failing in create a castle make BfW crash

Follow-up Comment #7, bug #22828 (project wesnoth): Sorry for no attach files before, my scenario is quite complex and macromized and can not supply a reduced enveiroment. I attach my add on tweaked to reproduce bug: 1- Host game 3p-World Conquest II 2- Use debug in scenario 1 3- use "n" for next

[Wesnoth-bugs] [bug #22828] [generator] failing in create a castle make BfW crash

Follow-up Comment #4, bug #22828 (project wesnoth): Forgive me, I finally found the "true" stderr.txt. it says: "20141019 02:16:47 error engine: No castle location found, aborting." ___ Reply to this item at:

[Wesnoth-bugs] [bug #22828] [generator] failing in create a castle make BfW crash

Follow-up Comment #3, bug #22828 (project wesnoth): I forgot a little detail, to reproduce bug you also need a "big enougth" value in key players players=#I was using 6 ___ Reply to this item at: __

[Wesnoth-bugs] [bug #22828] [generator] failing in create a castle make BfW crash

Follow-up Comment #2, bug #22828 (project wesnoth): I used default [generator]. Never looked stderr.txt before, but it looked to me like all lines have date from a week ago (I think date is when I downloaded and instaled BfW 1.11.17) To reproduce bug, looks enougth with give restrictive values in

[Wesnoth-bugs] [bug #22828] [generator] failing in create a castle make BfW crash

URL: Summary: [generator] failing in create a castle make BfW crash Project: Battle for Wesnoth Submitted by: tekelili Submitted on: sáb 18 oct 2014 20:32:53 UTC Category: Bug S

[Wesnoth-bugs] [bug #22774] Modify default behavior of [insert_tag] for empty variables

Follow-up Comment #3, bug #22774 (project wesnoth): In way I used insert_tag could have sense use it for tags like [redraw], but I pretty much would prefer [insert_tag] doesnt write them if variable given does not exist. Other example of current behavior inconvenience is {FOREACH}. If you insert [

[Wesnoth-bugs] [bug #22774] Modify default behavior of [insert_tag] for empty variables

URL: Summary: Modify default behavior of [insert_tag] for empty variables Project: Battle for Wesnoth Submitted by: tekelili Submitted on: vie 10 oct 2014 14:27:15 UTC Category: Feature Request

[Wesnoth-bugs] [bug #22373] Village flag graphic displayed behind [item] images

URL: Summary: Village flag graphic displayed behind [item] images Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 21 jul 2014 13:45:18 UTC Category: Bug Sev

[Wesnoth-bugs] [bug #22337] Bug in Inspect long arrays

URL: Summary: Bug in Inspect long arrays Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 14 jul 2014 15:17:20 UTC Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #22336] Mushroom tiles use base as double terrain

URL: Summary: Mushroom tiles use base as double terrain Project: Battle for Wesnoth Submitted by: tekelili Submitted on: lun 14 jul 2014 14:57:54 UTC Category: Bug Severity: 4 -

[Wesnoth-bugs] [bug #22324] team name in turn dialog untranslateable since save id is used

Follow-up Comment #3, bug #22324 (project wesnoth): (still no clue how edit) forgive my mistake, key should be value=_"Hello" ___ Reply to this item at: ___ Men

[Wesnoth-bugs] [bug #22324] team name in turn dialog untranslateable since save id is used

Follow-up Comment #2, bug #22324 (project wesnoth): (sorry for double reply, no clue how edit previous one) Just to make it more clear, when you write this code [set_variable] name=str_hello variable=_"Hello" [/set_variable] the value of str:hello will be "Hola", "Alo", "Hello" or whate

[Wesnoth-bugs] [bug #22324] team name in turn dialog untranslateable since save id is used

Follow-up Comment #1, bug #22324 (project wesnoth): This is an old issue. Problems extends to any translatable string saved in a variable. Problem shows more clear in multiplayer, in single player is often only detected in displays as team info or objectives. _

  1   2   >