Wesnoth 1.13.5
Moderator: Forum Moderators
Re: Wesnoth 1.13.5
there may be something wrong with the lua. It was spewing out errors about creating an empty unit type, then stopped doing that without me doing anything, now whenever game begins last side's leader is selected for player 1.
edit: uhm, ofcourse this happens testing my own umc, so in the end its probably my wml fault but still i have checked and can verify any type= used in [event]s being existant.
edit: uhm, ofcourse this happens testing my own umc, so in the end its probably my wml fault but still i have checked and can verify any type= used in [event]s being existant.
- Celtic_Minstrel
- Developer
- Posts: 2253
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Wesnoth 1.13.5
It might help if you post stack traces from the Lua console? If the problem is in Wesnoth code, that should be visible from the stack traces. (Note, I believe you need to be in debug mode, ie ";debug", to open the Lua console.) You don't need to include all the "Adding xyz" initialization lines, just the actual error.
Re: Wesnoth 1.13.5
this was caused by wml, removing the last added event fixed this one.game begins last side's leader is selected for player 1.
writing debug in the lua console gave only this:
$ debug
{traceback=function: 00AFE900,getinfo=function: 00AFEDF0}
probably not in the lua then, now off to debug via removing events one by one until have find the one at fault.
Re: Wesnoth 1.13.5
When the game is fullscreen, I can't change my resolution. That's annoying, since I run 1680x1050 most of the time, but with Wesnoth, that's too small. Yes, I know there's the zoom, which I take advantage of, but the HUD is still equally small.
- Celtic_Minstrel
- Developer
- Posts: 2253
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Wesnoth 1.13.5
The fullscreen thing was an intentional (though I think somewhat arbitrary) change due to the SDL2 move – SDL2 supports two different types of fullscreen mode, so it was necessary to pick one. I think there was complaints about it in 1.13.4 as well though, so it's quite possible that it'll be changed.
Re: Wesnoth 1.13.5
Can we get debug mode create unit menu to use sorting by race as default ?
Have observed that sorting the recruit list became possible again as its displaying alphabetically sorted after the id's instead unit's name.
There id like to suggest making an seperate key for it that goes into an unit_type, so dont have to rename every id like A Someunit, B Anotherunit... in order to get the desired sorting.
Have observed that sorting the recruit list became possible again as its displaying alphabetically sorted after the id's instead unit's name.
There id like to suggest making an seperate key for it that goes into an unit_type, so dont have to rename every id like A Someunit, B Anotherunit... in order to get the desired sorting.
Re: Wesnoth 1.13.5
Eagle_11 wrote:have not see this before, is it some sort of anti-cheat measure ?
Spoiler:
Re: Wesnoth 1.13.5
Have pushed a fix for this to master. It will be in the next release.Have observed that sorting the recruit list became possible again as its displaying alphabetically sorted after the id's instead unit's name.
Creator of Shadows of Deception (for 1.12) and co-creator of the Era of Chaos (for 1.12/1.13).
SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?
SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?
Re: Wesnoth 1.13.5
(Not sure if this is a proper bug, or more of a WML Workshop question, but...)
It is currently possible to make custom traits have a help description by sticking a [topic] tag in a [race]. However, this trait then shows up in the unit list the help for that race. In the attached example, there is no unit called "Devout", that comes from [race]...[topic]title=_"Devout"....
Even if this isn't the correct way to make traits have help descriptions (in which case, what is?), it seems like strange behaviour in general and is probably not intended.
It is currently possible to make custom traits have a help description by sticking a [topic] tag in a [race]. However, this trait then shows up in the unit list the help for that race. In the attached example, there is no unit called "Devout", that comes from [race]...[topic]title=_"Devout"....
Even if this isn't the correct way to make traits have help descriptions (in which case, what is?), it seems like strange behaviour in general and is probably not intended.
Spoiler:
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Wesnoth 1.13.5
Almost everything gets cut-off with an ... on the sidebar and elsewhere on the UI as of this release for me, sometimes even the unit's name wont display in the recruit unit menu, fe. if it's 'Elvish Spearman' only 'Elvish' does show up, it was definitely better during 1.12
edit: got another error, can someone decipher me the meaning of this one please.
edit: got another error, can someone decipher me the meaning of this one please.
- Celtic_Minstrel
- Developer
- Posts: 2253
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Wesnoth 1.13.5
I don't remember if it made it into 1.13.5, but any trait in a race or unit type now gets an automatically generated topic with no extra work. I'm not entirely sure, but I think race topics were intended for adding additional "lore" topics for a race, so the location it appears in makes sense to me.doofus-01 wrote:(Not sure if this is a proper bug, or more of a WML Workshop question, but...)
It is currently possible to make custom traits have a help description by sticking a [topic] tag in a [race]. However, this trait then shows up in the unit list the help for that race. In the attached example, there is no unit called "Devout", that comes from [race]...[topic]title=_"Devout"....
Even if this isn't the correct way to make traits have help descriptions (in which case, what is?), it seems like strange behaviour in general and is probably not intended.
Thanks for the report. In addition, it might help to know exactly what action you took to produce the assertion failure.Eagle_11 wrote:edit: got another error, can someone decipher me the meaning of this one please.
Re: Wesnoth 1.13.5
That was an 3v3(DrakevsLoyalist) all AI test game with me observing, played with an umc in development, also used Free XP and Rush Mode mp mods.
The last thing that happent before the error is an Ogre attacking AI Drake warrior leader standing on an mineshaft overlay mountain hex.
The last addition i had made to the Umc before went playtesting was adding this ability on the Ogres and nesting the event into [era] top level. Meanwhile have tested it in debug mode found to be working properly and doubt it being the cause as Drake warrior had no slow attack anyways.
Another thing i have observed is setting player slot to empty spawns an random leader for the empty side.
The last thing that happent before the error is an Ogre attacking AI Drake warrior leader standing on an mineshaft overlay mountain hex.
The last addition i had made to the Umc before went playtesting was adding this ability on the Ogres and nesting the event into [era] top level. Meanwhile have tested it in debug mode found to be working properly and doubt it being the cause as Drake warrior had no slow attack anyways.
Code: Select all
#define ABILITY_IMMUNE_TO_SLOW
[dummy]
id=slowimmune
name= _ "massive"
description= _ "this unit is large, as such slow weapon-special does not take effect on it."
[/dummy]
#enddef
#define SLOWIMMUNITY_EVENTS
[event]
name=attack end
first_time_only=no
[filter_attack]
special=slow
[/filter_attack]
[filter_second]
ability=slowimmune
[/filter_second]
{CLEAR_VARIABLE second_unit.status.slowed}
[unstore_unit]
variable=second_unit
find_vacant=no
[/unstore_unit]
[/event]
[event]
name=attack end
first_time_only=no
[filter_second_attack]
special=slow
[/filter_second_attack]
[filter]
ability=slowimmune
[/filter]
{CLEAR_VARIABLE unit.status.slowed}
[unstore_unit]
variable=unit
find_vacant=no
[/unstore_unit]
[/event]
#enddef
Re: Wesnoth 1.13.5
Cool.Celtic_Minstrel wrote:I don't remember if it made it into 1.13.5, but any trait in a race or unit type now gets an automatically generated topic with no extra work.
How does it make any sense to stick random "lore" topics as entries in the units list?Celtic_Minstrel wrote:I'm not entirely sure, but I think race topics were intended for adding additional "lore" topics for a race, so the location it appears in makes sense to me.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Wesnoth 1.13.5
Because its not exactly 'units list', its just the fact wesnoth lists any unit belonging to that race under it's 'racename' topic instead putting them first into an 'units' subsection under 'racename'