vghetto port project
Moderator: Forum Moderators
Re: vghetto port project
The BOM in UTF-8 is usually considered harmful.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm What's the point of this? The BOM exists for a reason, and the add-on should run equally well with or without it.
- Celtic_Minstrel
- Developer
- Posts: 2166
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: vghetto port project
I'm not going to comment on that opinion, but there are good reasons to use it, especially if you're working on Windows.
- Atreides
- Posts: 1062
- Joined: March 30th, 2019, 10:38 pm
- Location: On the 2nd story of the centre village of Merwuerdigliebe turning the lights on and off
Re: vghetto port project
I think the reason the BOM was included is because wmllint currently complains about it. Me, I'm an ancient DOS user, I barely know what the BOM is LOL. Or UTF... 8- D
- Celtic_Minstrel
- Developer
- Posts: 2166
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: vghetto port project
And from what Elvish_Hunter said on GitHub, it seems wmllint complains about it because Wesnoth complains about it, so I think the right answer is to just… not.
Re: vghetto port project
Thank you for the feedback! much appreciated.
There are some changes that both miss like wolf-hit.wav.
The [if] variable conditionals were not working right because of it.
This is the rule of thumb that I follow now. Use yes/no in WML and true/false in Lua. That makes the code less error prone.
Other than having it included twice it also starts to throw macro redefinition errors.
I tried giving it a shot in Rise of the Elementalist, but they were there for looks rather than strategy, so I reverted them back.
Because they crash wmllint/wmlindent. Run the tools on Ghostly Calls or the original Merry Christmas (or the other one by the same author) or Zombies Introduction. They will crash.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm What's the point of this? The BOM exists for a reason, and the add-on should run equally well with or without it.
No, it's doing some file paths replacements that the more modern version does not. Specifically in changing the names of older soundtracks.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm This is wrong!!! Under no circumstances should you be running wmllint-1.4 on an add-on written for Wesnoth 1.12 – it's only intended for add-ons written for Wesnoth 1.2 (ie, 10 versions earlier).
There are some changes that both miss like wolf-hit.wav.
Yeah, not a big deal.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm The[target]
syntax is supposed to still be valid indefinitely, although there may have been a bug in 1.14 (fixed in 1.16) that prevented it from working? That aside, there's also three other tags that would need a similar treatment… if I recall correctly,[target_location]
,protect_unit]
, and[protect_location]
.
No, it's not pointless. I first became aware of the true/false problem when I worked on Cities of the Frontiers way back then.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm This seems pointless, since the WML parser treats true/yes and false/no as synonyms. In fact, in the GUI2 WML, true and false are consistently used instead of yes and no (I have no idea why this is, only that it is the case).
The [if] variable conditionals were not working right because of it.
This is the rule of thumb that I follow now. Use yes/no in WML and true/false in Lua. That makes the code less error prone.
This has to do with when a file gets included implicitly in _main.cfg like so {./utils/} and then again in the scenario {./utils/death.cfg}Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm I don't really understand what this even means…?
Other than having it included twice it also starts to throw macro redefinition errors.
It shows errors in the console. I'm only doing it for files smaller than 72x72 that are supposed to be 72x72. So not overlay images and such, but regular unit images.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm Why would you even want to do this? And even if you do, automating like that it seems like a disaster waiting to happen.
That is true if it is a special note that is unit specific and not ability specific. But, that wasn't what I've seen in everything that I have ported so far. In all of my cases, it was related to some custom ability. So to fix it, I would include special_note= to the ability block itself and remove it from the unit definition.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm You're missing how to handle a one-off special note. If it's a literal string (ie,{SPECIAL_NOTES}+_"This is a note!"
), then you need to add a[special_note]
tag in the[unit_type]
:
If it's a custom note macro that's associated with a movetype (ie, every unit with that movetype has it and no units without that movetype have it), then add theCode: Select all
[special_note] note=_"This is a note!" [/special_note]
[special_note]
tag to the movetype definition in the[units]
tag. If it's a custom note macro associated with a custom damage type (eg "electrical"), you need to add it in the[language]
tag:
Code: Select all
[language] special_note_damage_type_electrical=_"This is a note!" [/language]
They look like sh*t and I'm not the first one to say that.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm This isn't necessarily correct. It preserves the look of the map, but if you instead want to preserve the stats, you should useTb^Tf
, overwriting the pre-existing base.
In a campaign, I think preserving the look is usually correct, but the existence of the other option is why it's not automated in wmllint.
I tried giving it a shot in Rise of the Elementalist, but they were there for looks rather than strategy, so I reverted them back.
I'm more focused on porting to 1.14 myself. 1.16 hasn't grown on me yet and I barely use it. It's a memory hog and it freezes my computer.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm You should always use the version of wmllint that ships with the target version of Wesnoth, so this is correct when porting to 1.14. You should be using the 1.16 version when porting to 1.16.
Sure.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm It was never written to handle that, so it's fine. Just don't run it on add-ons newer than 1.2 and you should be fine.
- Celtic_Minstrel
- Developer
- Posts: 2166
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: vghetto port project
Okay, that sounds like a bug in wmllint/wmlindent then.
That's weird… unless the add-on in question was somewhere along the line ported from 1.2, I don't know how it would end up with track names that aren't supposed to exist?
When exactly is "way back then"?vghetto wrote: ↑December 29th, 2021, 11:14 amNo, it's not pointless. I first became aware of the true/false problem when I worked on Cities of the Frontiers way back then.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm This seems pointless, since the WML parser treats true/yes and false/no as synonyms. In fact, in the GUI2 WML, true and false are consistently used instead of yes and no (I have no idea why this is, only that it is the case).
Ah, okay, I guess it's safe if it's only making files bigger, although it feels like you could still end up misaligning them.vghetto wrote: ↑December 29th, 2021, 11:14 amIt shows errors in the console. I'm only doing it for files smaller than 72x72 that are supposed to be 72x72. So not overlay images and such, but regular unit images.Celtic_Minstrel wrote: ↑December 28th, 2021, 7:06 pm Why would you even want to do this? And even if you do, automating like that it seems like a disaster waiting to happen.
Re: vghetto port project
Around January 2020. I don't remember which specific version of wesnoth it was at the time, maybe 1.14.5 the debian repo version or later.
These are from the esci-bugfix branch for Wild_Frontiers which is Cities of the Frontiers unaltered.
https://github.com/virtualghetto/Wild_Frontiers
That's when I first made the changes from true/false to yes/no because something wasn't working right with them.
Code: Select all
commit cc35c83e4a4a43c59cf47369b3a19c1530971072
Author: larry_the_cow <larry@gentoo.org>
Date: Thu Jan 23 17:15:36 2020 +0000
commit c8f66db3471028d4f2cfdbf778ad73c1d6c77d35
Author: larry_the_cow <larry@gentoo.org>
Date: Wed Jan 22 19:46:43 2020 +0000
- Celtic_Minstrel
- Developer
- Posts: 2166
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: vghetto port project
Hmm, that's strange, because the parser definitely treats true/yes and false/no as synonyms… I do see some places in that first commit that use
equals
and not_equals
instead of boolean_equals
and boolean_not_equals
though, which would convert it to a string and consider "true" and "yes" to be different, but at least one place is correct.- Atreides
- Posts: 1062
- Joined: March 30th, 2019, 10:38 pm
- Location: On the 2nd story of the centre village of Merwuerdigliebe turning the lights on and off
Re: vghetto port project
We really need a wmllint thread :)
I found another "quirk" of the lint picking machine:
It changes all instances of Rami to Dune Rider. Including custom name lists...
So it took a demon name Ramiel in a race name list and turned it into Dune Riderel. Hehehe.
Amusing as it is it is also a tad annoying since when you run it you get a half page of demon names listed and you are forced to use dry run to avoid changing it again. There is no wmllint magic word that will turn this off, I went through the whole list of options. So it would be quite good to change this or add a way to disable it.
I found another "quirk" of the lint picking machine:
It changes all instances of Rami to Dune Rider. Including custom name lists...
So it took a demon name Ramiel in a race name list and turned it into Dune Riderel. Hehehe.
Amusing as it is it is also a tad annoying since when you run it you get a half page of demon names listed and you are forced to use dry run to avoid changing it again. There is no wmllint magic word that will turn this off, I went through the whole list of options. So it would be quite good to change this or add a way to disable it.
Re: vghetto port project
Heh, reminds me of knyght getting his name updated to Tahsin Jahin Dune Paragon...Atreides wrote: ↑December 30th, 2021, 6:25 pm We really need a wmllint thread
I found another "quirk" of the lint picking machine:
It changes all instances of Rami to Dune Rider. Including custom name lists...
So it took a demon name Ramiel in a race name list and turned it into Dune Riderel. Hehehe.
Amusing as it is it is also a tad annoying since when you run it you get a half page of demon names listed and you are forced to use dry run to avoid changing it again. There is no wmllint magic word that will turn this off, I went through the whole list of options. So it would be quite good to change this or add a way to disable it.
Wesnoth-related GitHub repos:
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
- Elvish_Hunter
- Posts: 1575
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: vghetto port project
Actually, there's a magic comment for this. PutAtreides wrote: ↑December 30th, 2021, 6:25 pm Amusing as it is it is also a tad annoying since when you run it you get a half page of demon names listed and you are forced to use dry run to avoid changing it again. There is no wmllint magic word that will turn this off, I went through the whole list of options. So it would be quite good to change this or add a way to disable it.
# wmllint: noconvert
in the lines where you want to disable conversions.Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
- Atreides
- Posts: 1062
- Joined: March 30th, 2019, 10:38 pm
- Location: On the 2nd story of the centre village of Merwuerdigliebe turning the lights on and off
Re: vghetto port project
Fantastic! Thank you. I hadn't tried that since the help text implied it was for something else only.Elvish_Hunter wrote: ↑December 30th, 2021, 7:24 pmActually, there's a magic comment for this. PutAtreides wrote: ↑December 30th, 2021, 6:25 pm Amusing as it is it is also a tad annoying since when you run it you get a half page of demon names listed and you are forced to use dry run to avoid changing it again. There is no wmllint magic word that will turn this off, I went through the whole list of options. So it would be quite good to change this or add a way to disable it.# wmllint: noconvert
in the lines where you want to disable conversions.
- Argesilao2
- Posts: 113
- Joined: February 18th, 2020, 9:28 pm
- Location: Piciule Patrie
Re: vghetto port project
Just ported to 1.16 the campaign Liberating Alduin.
Tested in normal difficulty, the campaign is complete and should be fully operational, even if it would need several adjustments.
Tested in normal difficulty, the campaign is complete and should be fully operational, even if it would need several adjustments.
Re: vghetto port project
Thank you so much. I updated the main list.Argesilao2 wrote: ↑December 30th, 2021, 10:26 pm Just ported to 1.16 the campaign Liberating Alduin.
Tested in normal difficulty, the campaign is complete and should be fully operational, even if it would need several adjustments.
I'm still stuck working on Wesband. A big update is coming soon(tm) which allows it to work with third party units/eras and add-ons. That means those units would have an inventory and can pick up and drop stuff. Well at least in theory. Also the inventory is sorted!! Wooo!
Edit:
The Altaz Mariners and Den of Thieves were quietly released recently.
I need to update my TAM patch and Marauding Thieves before I get back to this project.
Re: vghetto port project
I'm gonna start the update process. I'll be focusing on the 1.14 uploads first.
Is anyone working on anything relating to this project right now?
I'm going to be porting Northern_Forces to 1.14/1.16.
Is anyone working on anything relating to this project right now?
I'm going to be porting Northern_Forces to 1.14/1.16.