dealing with luaui conflict in non conventional manner.

[smoth]

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)"

[smoth]

if it helps in any way, the file is visible if placed here:
Spring\Gundam\luaui

Which strikes me as freaking odd.

[Niobium]

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]

./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?

[smoth]

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.

Shit will still get broken people will not read the standards etc.

[smoth]

leaving this bit for me to look at later


Line 1091 in my file

Code: Select all

		local sw = self:LoadWidget(LUAUI_DIRNAME .. SELECTOR_BASENAME)
		self:InsertWidget(sw)
		self:RaiseWidget(sw)

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.

[Niobium]

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?

[jK]

gundamDEV8.sdd\gundam\LuaUI\selector.lua
but, when I hit f11:
"Failed to load: selector.lua (missing file: gundam/luaui/selector.lua)"

VFS is case-sensitive?

[zwzsg]

Is there a reason why you don't just have user widgets disabled by default?

Because even disabled widgets can mess stuff up when they're badly written.

[Forboding Angel]

gundamDEV8.sdd\gundam\LuaUI\selector.lua
but, when I hit f11:
"Failed to load: selector.lua (missing file: gundam/luaui/selector.lua)"

VFS is case-sensitive?

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.

[smoth]

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.

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.

Is there a reason why you don't just have user widgets disabled by default?

Because even disabled widgets can mess stuff up when they're badly written.

FACT

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?

[trepan]

Because even disabled widgets can mess stuff up when they're badly written.

I still suggest that the spring widget and gadget
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

The widget handler would compile the widget/gadget
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

Note that this setup also works for precompiled lua code.
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.

[SpliFF]

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).

[smoth]

I am going to say this one more time

disabled/enable a widget does not prevent it from destroying your lua.

[zwzsg]

Then I'd say that widgets that do nasty stuff even when disabled should be killed on sight.

[SpliFF]

I am going to say this one more time

disabled/enable a widget does not prevent it from destroying your lua.

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.

[CarRepairer]

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.

The mod widget may have crashed but it can be due to the presence of a local widget.

[smoth]

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.

[Niobium]

Then I'd say that widgets that do nasty stuff even when disabled should be killed on sight.

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.

You don't need to go out and fix every issue in every widget, ...

because I don't have enough work to do as it is. ...

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.

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.

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]

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 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.

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.

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 >:|.

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.

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.