#Rosetta Project (Umbrella)
1 messages · Page 2 of 1
I believe the types in the Java stubs are determined by the Java return types—the function returns a double even though the random number will be an int or long
That said, if you use a Random instance with newrandom() the return types on its random method will be accurate since albion recently corrected that (it's defined in a separate stub since it comes from Kahlua). Also isn't as complex of a random number generator, which fits most use cases
good to know
btw why does umbrella do this instead of using class fields?
wouldn't this work the same?
--- @class Recipe
--- @field GetItemTypes Recipe.GetItemTypes
--- @field OnCanPerform Recipe.OnCanPerform
```etc
fields are for instances
i would argue in an ideal world this shouldn't be declared as a class at all, but emmylua is dumb and there are benefits to doing it anyway
yea that is true, i was just curious is all
also i've never seen type comments on the same line as a variable
it's always either above, or use @as
in fact, I can't even find the Recipe.GetItemTypes type, it doesnt exist
either that or umbrella isnt resolving it
The same line thing is fine, if they don't exist that's a bug. But yeah it's what albion said, class fields are generated that way to differentiate between them & instance fields
On my end I see them defined in that same file? Let me see if that's what's in main
Oh nevermind, I was looking at .WeaponParts. Yeah, that's missing
also, I noticed I still get sandboxvars issue (the one I did the PR for before), does umbrella release in chunks? I would've thought it got merged into the main branch
I believe albion updates the main repo by manually running the two tools & that's done for updates other than hotfixes
So it'll likely be in main on the next updates
you have to manually run stuff to release update? thats oof moment
but I assume its something like issue I had with leaf, where you need the game files to release?
It's manual in the same sense that running a command in a terminal is manual
Like it could be automated, but yeah it requires game files
I remember we were talking about that here a while back & you brought up depotdownloader
the problem is that its really a pain to store the entire game into runner storage
actually now that I think about it, you could in theory just only use the lua folder and java(now the jar), to save on storage space
idk how I didnt think of that before considering i've known about depotdownloader for a long time now
didn't we already have this conversation 😅
probably, my memory has been trash recently, i cant recall ever mentioning this here though
we did yeah 😅
oops
another broken thing I think may be ProceduralDistributions, see here
this is intended to reduce filesize
hmm ok. but we can't even have a dummy structure?
I understand not having all of the values because its a lot, but things like list field not being there makes all my distribution code error
also we can outline every possible key value as well
That could be done via the stub data—feasible to add to the stub generator, but it's probably the messiest thing I've written in the last decade so I'm not in any rush to add that 😅
In either case, an issue on the repo or a PR would be welcome
true I forgot I can do that
tbh its hard to know if its a bug or intentional design (like this case)
Yeah, probably would be good to add a note to the README or elsewhere about the edge case handling
Honestly those tables probably shouldn't have even been classes, so maybe that'd be a simpler fix. It'd be breaking for anyone referencing them, though
I miss being able to use the callback types like Callback_xyz
still technically there, but you have to do some trickery to get it to work proeprly now, instead of just a simple type doctag
i still don't really get why the emmylua guys are against that
they seem to take a stand on the most simple things but then will add some arbitrary feature no one will ever use
tbh they dont do that all the time, but still
and if they do add something useful, it won't be documented so you won't even know about it
we are kind of limbo though, because if we go back to luals it's like regressing a decade and staying on emmylua we aren't guaranteed features
when you mentioned forking emmylua it sounds reasonable now
do you know if they are explicitly against using the type dogtag for funcs or that they just havent added it yet?
there's an issue for it where they're against it
no chance i'm going back to anything that doesn't support generics
the problem with forking it is getting the extensions to play nice
I believe the emmylua extension has the ability to point to a custom exe, but its just more setup than normal which sucks
In the hypothetical future with a fork, I imagine it would also make sense to fork the extension—could then either directly bundle the stubs or have functionality to download and update them
Also, what's the callback type y'all are referring to? Distinct from aliases which map to function types?
basically emmylua doesn't like this but luals does:```lua
---@alias MyFunctionType fun(a:string):boolean
---@type MyFunctionType
local function myFunction() end
the alias type can still be used elsewhere, just not as ---@type
Ohh, gotcha. I do the first part of that frequently but not the function definition with a type
Interesting, odd that it wouldn't be supported
by the extension I assume you mean only vscode, otherwise we'd be forking each repo for each of the extensions + the base emmylua-analyser-rust repo
they have lot of segmentation (for better or worse)
Yeah, I meant vs code
Gotta love when EmmyLua updates and you get 40 new diagnostics
invert-if is an example of something I'm on board with on paper but in practice it goes directly into my ignore list
Same 🙃 I assume there's some setting somewhere for it since it includes the level there but I couldn't be bothered
Also seems stricter about X = X or {}, which is annoying but good
Working on the stub data update; would've done so yesterday but I forgot I do that 😄 Should be done today
i've been too busy to do any of my update chores yet 😅 this one doesn't seem too major at least
Yeah, at least on the Lua side there weren't many signature changes
PR for 42.14 at https://github.com/PZ-Umbrella/pz-lua-stubdata/pull/6; I did a PR instead of just merging because 1. I'd just like to do that going forward in case anyone has thoughts & 2. this does not include the changes from https://github.com/PZ-Umbrella/pz-lua-stubdata/pull/3 (but probably should, I don't have any better idea on how to handle those fields)
If no one has objections or other thoughts I'll probably merge PR 3 into PR 6 myself & then merge to main tomorrow
i've been meaning to go back over that pr but i just haven't had much energy for it lately
Completely fair, I think in the meantime we ought to include it anyhow since iirc it reflects what's in the stubs currently
Me when I lie
Gonna go ahead and merge now bc iirc there weren't any Lua signature differences in the patch
Oh, didn't even notice there was an approval—now it looks like I was just waiting for that 👀 that's definitely it, I didn't just forget it exists
Of course I only remember I was gonna include the license change after pressing merge
it was mostly intended as a prod since i finally got around to doing my 42.14.0 chores
Appreciated, I probably would've noticed it tomorrow if I hadn't remembered
I'm gonna be taking a break from PZ stuff to focus on other endeavors—unsure how long (indefinitely, but likely not permanent because I love pz & the community). This will likely include stub data updates, unfortunately
taking a break is worth it