dealing with luaui conflict in non conventional manner.
Moderator: Moderators
dealing with luaui conflict in non conventional manner.
So since many of the BA widgets are written ham-handedly causing users to have luaui crash on them epicly, I have come to a decision:
I have a couple of choices:
Blacklist/whitelist
Completely open(as it is now)
I do not like blacklists/whitelists as they are limiting for adv players. I cannot do open either though because many people are writing unsafe and sloppy widgets.
So thinking of a solution I came to a conclusion for gundam rts. I am going to have a /gundam dir in the spring folder. So I will store stuff like this:
Spring/Gundam/Luaui/
Spring/Gundam/Configs/
Spring/Gundam/Music/(for overriding music)
Spring/Gundam/Docs/
and if possible
Spring/Gundam/Screenshots/
This will allow advanced users to copy over whatever widgets they need, and allow people to have the massive pile of shit ba widgets without killing gundamRTS' widgets
Now, this solution has brought about new issues, I have to include all the luaui contents with gundam so I can have all the headers and base code I need, meaning I will HAVE to update every time that luaui folder in spring changes. I means I have had to add the luadir variable to alll luaui code(ENGINE DEVS FIX THIS IN YOUR LUA!). Thirdly and most importantly, I am having a with selections.lua(the lua that controls the widget menu.)
so I have inside of the sdd:
gundamDEV8.sdd\gundam\LuaUI\selector.lua
but, when I hit f11:
"Failed to load: selector.lua (missing file: gundam/luaui/selector.lua)"
I have a couple of choices:
Blacklist/whitelist
Completely open(as it is now)
I do not like blacklists/whitelists as they are limiting for adv players. I cannot do open either though because many people are writing unsafe and sloppy widgets.
So thinking of a solution I came to a conclusion for gundam rts. I am going to have a /gundam dir in the spring folder. So I will store stuff like this:
Spring/Gundam/Luaui/
Spring/Gundam/Configs/
Spring/Gundam/Music/(for overriding music)
Spring/Gundam/Docs/
and if possible
Spring/Gundam/Screenshots/
This will allow advanced users to copy over whatever widgets they need, and allow people to have the massive pile of shit ba widgets without killing gundamRTS' widgets
Now, this solution has brought about new issues, I have to include all the luaui contents with gundam so I can have all the headers and base code I need, meaning I will HAVE to update every time that luaui folder in spring changes. I means I have had to add the luadir variable to alll luaui code(ENGINE DEVS FIX THIS IN YOUR LUA!). Thirdly and most importantly, I am having a with selections.lua(the lua that controls the widget menu.)
so I have inside of the sdd:
gundamDEV8.sdd\gundam\LuaUI\selector.lua
but, when I hit f11:
"Failed to load: selector.lua (missing file: gundam/luaui/selector.lua)"
Re: dealing with luaui conflict in non conventional manner.
if it helps in any way, the file is visible if placed here:
Spring\Gundam\luaui
Which strikes me as freaking odd.
Spring\Gundam\luaui
Which strikes me as freaking odd.
Re: dealing with luaui conflict in non conventional manner.
I think a better solution than blocking/separating would be to post about the widgets that are giving problems and why, so that the authors/community can fix them up (I don't think this would be difficult, and it is worth it if they are popular i.e. useful), and hopefully get some rules out there about what newbie widget writers should do to ease portability and/or reduce conflicts.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: dealing with luaui conflict in non conventional manner.
./slap
Edit: Let me be more concise. Do you have any idea the sheer amount of widgets there are out there? How the hell is a gamedev gonna know? The only thing we get from our users is "It doesn't work". So now we're supposed to bugfix luadev's stuff for them even when we have no idea nor details?
Edit: Let me be more concise. Do you have any idea the sheer amount of widgets there are out there? How the hell is a gamedev gonna know? The only thing we get from our users is "It doesn't work". So now we're supposed to bugfix luadev's stuff for them even when we have no idea nor details?
Re: dealing with luaui conflict in non conventional manner.
Shit will still get broken people will not read the standards etc.Niobium wrote:I think a better solution than blocking/separating would be to post about the widgets that are giving problems and why, so that the authors/community can fix them up (I don't think this would be difficult, and it is worth it if they are popular i.e. useful), and hopefully get some rules out there about what newbie widget writers should do to ease portability and/or reduce conflicts.
Re: dealing with luaui conflict in non conventional manner.
leaving this bit for me to look at later
Line 1091 in my file
Seems like it loads only out of spring folder instead of vfs
see if loadwidget and VFS.Include what are differences...
tired sleep now. Bitches don't know about gundam games tonight, fags, lol suck it *A and shit. I am tired. good night.
Line 1091 in my file
Code: Select all
local sw = self:LoadWidget(LUAUI_DIRNAME .. SELECTOR_BASENAME)
self:InsertWidget(sw)
self:RaiseWidget(sw)
see if loadwidget and VFS.Include what are differences...
tired sleep now. Bitches don't know about gundam games tonight, fags, lol suck it *A and shit. I am tired. good night.
Re: dealing with luaui conflict in non conventional manner.
I talked to someone who played gundum and had their luaui shutdown, I got them to send their infolog so I could have a look at what widgets are crashing in gundum, and lo and behold the widget that shutdown luaui was a mod widget, while the other crashing widgets were either extremely minor fixes or were coded to crash deliberately.
You don't need to go out and fix every issue in every widget, just the ones that are popular/important. At the very least you should talk to the authors about the problems, they might even fix it themselves. Either way the widgets would be improved and the community would be better off for it. A separate folder is just going to hide problems through people not being able to use their widgets, and become a hassle for anyone who can figure it out.
Is there a reason why you don't just have user widgets disabled by default?
You don't need to go out and fix every issue in every widget, just the ones that are popular/important. At the very least you should talk to the authors about the problems, they might even fix it themselves. Either way the widgets would be improved and the community would be better off for it. A separate folder is just going to hide problems through people not being able to use their widgets, and become a hassle for anyone who can figure it out.
Is there a reason why you don't just have user widgets disabled by default?
Re: dealing with luaui conflict in non conventional manner.
VFS is case-sensitive?smoth wrote:gundamDEV8.sdd\gundam\LuaUI\selector.lua
but, when I hit f11:
"Failed to load: selector.lua (missing file: gundam/luaui/selector.lua)"
Re: dealing with luaui conflict in non conventional manner.
Because even disabled widgets can mess stuff up when they're badly written.Is there a reason why you don't just have user widgets disabled by default?
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: dealing with luaui conflict in non conventional manner.
Assuming that that is an actual question, iirc it had to be made that way to make linux behave because people were getting errors with case sensitivity etc etc. This was a loooooooong time ago tho, so what I say may or may not have any relevance.jK wrote:VFS is case-sensitive?smoth wrote:gundamDEV8.sdd\gundam\LuaUI\selector.lua
but, when I hit f11:
"Failed to load: selector.lua (missing file: gundam/luaui/selector.lua)"
Re: dealing with luaui conflict in non conventional manner.
because I don't have enough work to do as it is. By all means I should be required to debug all the widgets to. It isn't like I don't sacrifice enough time testing engine builds or other shit. No, fuck the widget devs, I am tired of making sacrifices because you lot see my project as marginalized. "No one plays gundam so I don't care!" and then no one plays gundam because of this kinda shit, so yeah just feeding the excuse, no one plays gundam so we keep it that way. All I can say is fuck that. I am on person with very limited help from the community and frankly, I don't think I owe these coders any more community service than I already give.Niobium wrote:You don't need to go out and fix every issue in every widget, just the ones that are popular/important. At the very least you should talk to the authors about the problems, they might even fix it themselves.
FACTzwzsg wrote:Because even disabled widgets can mess stuff up when they're badly written.Is there a reason why you don't just have user widgets disabled by default?
JK: if it was case sensitive the other widgets would have an issue as well or perhaps you are saying that load method is case sensitive?
Re: dealing with luaui conflict in non conventional manner.
I still suggest that the spring widget and gadgetBecause even disabled widgets can mess stuff up when they're badly written.
format be rewritten to something like this:
Code: Select all
if (WantConfig) then
return {
name = 'widget_name',
author = 'blah blah',
enabled = false,
}
end
-- rest of the code
code into a function, and first execute it with a limited
function environment to aquire the widget/gadget's
parameters (without giving it the tools to mess with
any external states).
example:
Code: Select all
local f, err = loadfile(filename)
setfenv(f, {
WantConfig = true,
VFS = { Include = VFS.Include, },
})
local res, err = pcall(f)
if (is_desired_code(res)) then
setfenv(f, the_real_environment)
-- blah blah
end
Also note that the setfenv() function has been removed
from the current lua 5.2 offerings, but you can arrange
for similar functionality (especially given the fact that the
manager can prepend to the source code). The changes
required to make this work (for both the managers and
the widgets/gadgets), are trivial.
Re: dealing with luaui conflict in non conventional manner.
I'd just find a way to disable all "non-official" widgets in your game until the user explicitly turns them on. Save/Restore the widget setup when they start/leave your game. That way users can experiment with widgets but they do so in an "opt-in" manner. If a widget breaks anything while disabled that is a broken widget and you're well within your rights to blacklist all such widgets you know of (there can't be that many surely).
Re: dealing with luaui conflict in non conventional manner.
I am going to say this one more time
disabled/enable a widget does not prevent it from destroying your lua.
disabled/enable a widget does not prevent it from destroying your lua.
Re: dealing with luaui conflict in non conventional manner.
Then I'd say that widgets that do nasty stuff even when disabled should be killed on sight.
Re: dealing with luaui conflict in non conventional manner.
I'm not talking about disabled in the normal sense. I'm talking about throwing the widget away without even loading it. You should be about to do that with some minor tweaks to the default widgetHandler itself. When the widget requests to load check it's filename and skip it if it's in your blacklist. You don't even have to parse the file.smoth wrote:I am going to say this one more time
disabled/enable a widget does not prevent it from destroying your lua.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: dealing with luaui conflict in non conventional manner.
The mod widget may have crashed but it can be due to the presence of a local widget.Niobium wrote:I talked to someone who played gundum and had their luaui shutdown, I got them to send their infolog so I could have a look at what widgets are crashing in gundum, and lo and behold the widget that shutdown luaui was a mod widget, while the other crashing widgets were either extremely minor fixes or were coded to crash deliberately.
Re: dealing with luaui conflict in non conventional manner.
keep in mind it will be better in the long run that I establish a structure for game subdirs. That way we can have game specific screenshot, config file dirs etc.
Re: dealing with luaui conflict in non conventional manner.
Exactly this. To write a widget that messed with things mod-wide, only on particular mods, and even when disabled would require either deliberate intent or gross incompetence. Do you have the names of some of these widgets? I'd like to see what was done, as I've never seen this kind of widget before, I also reckon they could be fixed with a simple copy-paste into :Initialize.zwzsg wrote:Then I'd say that widgets that do nasty stuff even when disabled should be killed on sight.
Yet when deciding between your options to fix a small number of worst-case widgets, you choose the one requiring the largest amount of dev time, a separate folder system. The time required for minor fixes is small, and the time to implement a small blacklist in the handler is negligible.smoth wrote:because I don't have enough work to do as it is. ...Niobium wrote:You don't need to go out and fix every issue in every widget, ...
Screenshots great, config files great, multiple widget folders holding similar widgets with identical or inconsistent files? Can't say I look forward to it. Ironically the hassle of dealing with the separate folder would lead me to not bothering with it, and thus releasing my widgets untested in gundum.smoth wrote:keep in mind it will be better in the long run that I establish a structure for game subdirs. That way we can have game specific screenshot, config file dirs etc.
Re: dealing with luaui conflict in non conventional manner.
I have no idea, you would have to go through all of baracus's widgets. Fun fact, one of things that breaks is selector.lua. I like it though you essentially say I am incompetent for not catching your built in lua bomb? GG, you are making a freind quick. I am not even sure if it is your lua bomb or what but it doesn't matter as I am not going to stop everything and play hunt other people's lua bugs.Niobium wrote:Exactly this. To write a widget that messed with things mod-wide, only on particular mods, and even when disabled would require either deliberate intent or gross incompetence. Do you have the names of some of these widgets? I'd like to see what was done, as I've never seen this kind of widget before, I also reckon they could be fixed with a simple copy-paste into :Initialize.
I am not going to play hunt the black list or play YOU NEED TO UPDATE THIS WIDGET PLAYER! It is not what I am here to do. A seperate folder system has more benifits that JUST isolation from user widgets. The widgets might be one line fixes but I cannot stop everything every time someone writes a lua bomb or like you writes one on purpose >:|.Niobium wrote:Yet when deciding between your options to fix a small number of worst-case widgets, you choose the one requiring the largest amount of dev time, a separate folder system. The time required for minor fixes is small, and the time to implement a small blacklist in the handler is negligible.
You have not written widget 1 for gundam anyway. It is fine if you don't want to bother, you will play gundam? I doubt it.Niobium wrote:Screenshots great, config files great, multiple widget folders holding similar widgets with identical or inconsistent files? Can't say I look forward to it. Ironically the hassle of dealing with the separate folder would lead me to not bothering with it, and thus releasing my widgets untested in gundAm.