if it were up to me I would be more like
Trust me, it's happened before :joy:
local function getItemLink(itemId)
if nil == itemId then return end
local isItemId = itemId == 'number'
local isValidLink = string.match(itemId, "H0") or string.match(itemId, "H1")
if isValidLink return itemId end
if isItemId then return zo_strformat("|H1:item:<<1>>:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|h|h", itemId) end
-- otherwise shit hit the fan
end
ShouldBeInFurc() deliberately does not add shit to the database :joy:
function ShouldBeInFurC(link)
link = FurC.GetItemLink(link)
local itemId = GetItemLinkItemId(link)
if IsItemLinkPlaceableFurniture(link) then
return nil == FurnitureCatalogue.settings.data[itemId]
end
if not IsItemLinkFurnitureRecipe(link) then return false end
for _, versionData in pairs(FurC.Recipes) do
for _, id in ipairs(versionData) do
if id == itemId then return false end
end
end
for _, versionData in pairs(FurC.FaustinaRecipes) do
if versionData[itemId] then return false end
end
for _, versionData in pairs(FurC.RolisRecipes) do
if versionData[itemId] then return false end
end
-- yeah okay, it should actually return false, but this is a util function for datamining
return nil == FurnitureCatalogue.settings.data[itemId]
end
just for fun
I switched to the ZOS function to convert IDs and links at some point, but that led to downstream exceptions
and at that point I wasn't really into it anymore
that thing is loaded by sidTools, then adds a hook to the item viewer to dump the data into its saved variables
then there'll be a list of strings that just needs a little bit of search and replace until it's directly ready for FurC's data files
I have furC but I kinda just let it show the tooltip
looks like I will be playing with it for a bit, thanks so far
Good night everyone :) <waves>
Sorry for waking up this necro topic, but a RU guildie of mine who is using EN client, is getting DATETIME format of
That format I am getting with DE game client, my OS being in EN locale. I am totally confused. Isn't internal DATETIME format fixed for certain game client language?
DD.MM.YY. His Windows system is in RU.That format I am getting with DE game client, my OS being in EN locale. I am totally confused. Isn't internal DATETIME format fixed for certain game client language?
When I run the client in RU, my DATETIME format is exactly like in EN:
MM/DD/YY.
No @Sharlikran , OS locale doesn't consistently affect game client DATETIME format. A Czech guildie using EN client has en-us locale, whereas Russian guildie with EN client has European DATETIME format we see in DE client. It's completely unreliable. And client's locale is affected by launcher. E.g.: in Launcher set it to a different locale, then start the game via
eso.exe bypassing Launcher's PLAY button. Game won't start with new locale you chose, it will start with old one. I did a lot of testing yesterday discovering these. My guess is, when game is installed and started via Launcher the first time, it feeds locale from OS to the game, and that sticks there as locale of that chosen client language. After that whenever you come back to that client language, that "memorized" locale setting used again. That's how these two guys, one having RU and the other having CZ locales in their OS, using EN game client get different DATETIME formats.
These said, I haven't checked any game INI files to confirm my findings. I will just skip using any DATETIME formats from API.
@shehi Thanks for the correction, I would have thought it made a difference.
However, I was asking to be sure because I mentioned I parse it already and didn't get a response. I have not had any reports of it not working. Not sure who does or doesn't have issues with it though. I use it because I wanted to get the date the guild was founded but I wanted it in epoch time.
https://github.com/ESOUIMods/AdvancedMemberTooltip/blob/main/AdvancedMemberTooltip.lua#L725-L808
@Sharlikran , in that code you linked above:
The line local day, month, year = get_formatted_date_parts(dateString, "dd.mm.yy") assumes wrongly, as I described.
And then the rest of the logic there relies upon that assumption. I just don't understand: based on what you assume date format to be dd.mm.yy?! As I mentioned above, the format used ingame is completely unreliable. Personally on my EN game client, where Windows locale is EN-GB, I get mm/dd/yy dateformat, where digits aren't zero-left-padded (i.e. it is 3/30/2014, not 03/30/2014).
And as already mentioned, my Czech guildie with CZ Windows locale, using EN game client is getting dateformat like I do, in EN-US style.
And a Russian guildie with RU Windows locale, using EN game client is getting dateformat like that of DE game client, in
And a Russian guildie with RU Windows locale, using EN game client is getting dateformat like that of DE game client, in
dd.mm.yy style.
My assumption is, when we installed the game and started it the first time, for me Windows had EN-US back then, for Czech guy the same, and for Russian he had Russian one. So Launcher took these locales and assigned to our EN game client as valid locale.
I personally changed my Windows locale to EN-GB later on, but that doesn't affect anything anymore. Of course these need proper testing, checking INI files etc - maybe @ZOSDanBatson or someone else from ZOS could shed a light on this, I don't know :)
I personally changed my Windows locale to EN-GB later on, but that doesn't affect anything anymore. Of course these need proper testing, checking INI files etc - maybe @ZOSDanBatson or someone else from ZOS could shed a light on this, I don't know :)