Permanent LOS support in lobby? (and in the engine?)

[lurker]

Code: Select all

Spring.SendCommands{"cheat 1"}
Spring.SendCommands{"globallos"}
Spring.SendCommands{"cheat 0"}

No. This doesn't work. You can't use it on an autohost. There needs to be a direct LuaRules call to turn it on and off.



And this isn't about adding a feature, it's about making it easier to turn off a feature, a good thing!

[trepan]

Yall might also consider modifying the unitDef sensor radii
(something that globalLOS doesn't do, as far as I know).

[lurker]

Yep, would make good sense to use globallos and changing sensor distances as a modoption without any engine changes beyond a lua call, which I'll add in a couple days if no one else does.

[TradeMark]

wouldnt it be easier to just disable LOS testing in the engine code >_>

Code: Select all

if(!dont_test_los){
    test_los();
}

easy cake

[lurker]

And then when you turn it off again? It takes more code than just disabling checks.

[TradeMark]

dont_test_los = 1; // permanent LOS on

dont_test_los = 0; // permanent LOS off

what can be easier

[Tobi]

That's silly. We don't need any more engine-wide options that are either inapplicable or outright destructive to the gameplay of mods that aren't designed for it. We already have D-gun limits for mods that don't have D-guns, diminishing metal-maker returns for mods that don't have metal makers, etc. We _just_ got the stuff to move away from this kind of crap with the new EngineOptions feature and you want to add _more_ of them?

Notice that your option would be completely inapplicable to a mod like Fibre, and would be destructive to a visibility-oriented mod like 1944.

It's currently possible (but difficult) to make a mutator for any given mod that would do what you want - and it would be listed in the lobby as such, so players would actually see "Balanced Annihilation Permanent LOS mode". If it's added as a switch in a core TDF/lua file like I suggested, it would be trivial to do so.

Plus, you SHOULD implement this as a mutator, since you should also be gutting out all the visibility-related units that are cluttering up the menu.

Mods can already remove engine options from the lobby, so it's the mod's fault if it shows DGun limit while it doesn't have DGun.

Engine option seems to make most sense for this implementation wise because it could entirely disable all the LOS map updating. (which isn't turned off using any LUA based solution because it's per unit, and which isn't turned off when using /globallos because that switch can be toggled again at runtime, so LOS maps will need to stay up to date.)

Besides that it would open an easy option for a mod which does not want to use LOS, to actually turn it off completely: by hiding the engine option and setting it to default to off.

(Stuff like changing sensor radii and enabling /globallos through a gadget or something seems like a very hacky workaround to me...)

[Pxtl]

In that case, I have one question: will it be controllable from Lua in one of the startup script files? That is, can I have a mod-option (not a game option) that controls several other features, including this one? Or will the option be hard-coded to be controlled by the engine options screen?

[Tobi]

The engine options screen is not hard coded (at least it ought not to be; if it is, complain at the lobby client developer).

The engine options are read through unitsync from EngineOptions.lua, which can be overridden by the mod. (Both by overriding entire file or by defining options with the same name in ModOptions.lua, IIRC)

So a mod can hide / remove / add any engine options as it wishes, similarly to mod options. The only difference is technical: engine options are the same as mod options, except that the engine contains a hardcoded reference to them. (ie. the feature they expose is coded in C++ instead of LUA.)


EDIT: oh wait, I see you mean something different.

I don't think binding options together is possible right now in any way.

However, once the checks are in place to disable LOS, it shouldn't be hard to add a LuaRules callout that permanently disables LOS for the rest of the game.

(And of course if that is added the engine option would be less necessary again cause a mod could make a modoption combined with a 3 line gadget that calls this function...)

[Pxtl]

(And of course if that is added the engine option would be less necessary again cause a mod could make a modoption combined with a 3 line gadget that calls this function...)

This last part was my point from post 1. Add some Lua and then we can make a modoption for any mod. The only difference is that TradeMark wants the option to be available by default in every mod.

Personally, the long-term solution would be to implement a UT-style mutator system that lets users bolt some custom Lua and units onto any mod (rather than only being able to run 1 mutator that has to be specifically designed for a specific mod), and then you could make a "Full LOS" mutator that you could use with any mod, and everybody's happy (except TradeMark, who is annoyed that his players have to download a 200 byte mutator file before they play).

But in the short term, a lua-command and an engine-option will satisfy everybody's needs.

[TradeMark]

erm, so isnt d-gun limit setting default too?

and you can always hide the option if you dont like it in your mod

i dont see any reason why would you want to restrict people from playing your mod with this setting, like it would kill them? no need to prevent people using some settings...

(except TradeMark, who is annoyed that his players have to download a 200 byte mutator file before they play).

you still dont get it? its not about the size, its about that will you waste your time. a) searching the mutator. b) downloading it. c) installing it. d) and then finally join in the game (since you cant join in games which mod you dont have)

Its been proved fucking many times that people dont like to download new mods... they rather play that what they are already playing, unless some new mod is totally new and awesome

It sounds fucking stupid to download new mutator just because of permanent LOS setting, which is so basic thing that it should be able to put on/off like the d-gun limit already is.. or game end mode... or start positions style...

--

Edit:
Here is how it was in OTA:

Mapping: Mapped/Unmapped
Line Of Sight: True/Circular/Permanent

What i am asking is these settings:
Mapping = Mapped
Line Of Sight = Permanent

That easy it was... no need to prevent players using those settings -.-

[trepan]

Something to consider now that ModOptions and MapOptions
are being more frequently (and with the advent of EngineOptions).
The BZFlag version of widgets/gadgets uses the pattern that I'd
started before bailing on Spring. It goes a little something like this:

Code: Select all

if (WantConfig) then
  return {
    name = 'Widget Name',
    author = 'joe smoe',
    etc...
  }
end

<active module code>

Spring might use a similar pattern, but with an additional
'elseif (WantOptions) then return { { option1, etc... } } end'
clause so that ModOptions can draw option information out of the
gadgets. This would make full-featured, optionned, 'drop-in' gadgets
easier to create and manage.

P.S. The main reason that the WantConfig pattern is much better
than the current pattern is that it allows the module handler to
extract configuration information from a module without having to
pass it a fully loaded environment. Note that this technique also
works for pre-compiled modules.

P.P.S. I'll probably be committing the 'modules.lua' file (and friends),
to BZFlag sometime soon. It's both faster and cleaner than the
current Spring widgets.lua/gadgets.lua, and it's LGPL v2.1.

[imbaczek]

P.P.S. I'll probably be committing the 'modules.lua' file (and friends),
to BZFlag sometime soon. It's both faster and cleaner than the
current Spring widgets.lua/gadgets.lua, and it's LGPL v2.1.

cool, very nice of you to go with LGPL, it'll help clear those infamous legal gray areas. from technical pov, is it backwards compatible or do existing scripts require modifications?

[lurker]

Is something like local Wantconfig = ... the proper way to do this, or am I missing something?

[trepan]

The BZFlag project is all LGPL, all the time, so don't thank me :)
You'll probably need to tweak it some to get it to work with Spring.

As an example, the Spring lua rework (that I never committed),
had each call-in tagged with a control loop type (ex: BASIC,
FIRST_TRUE, FIRST_FALSE, SPECIAL, etc...) The module handler
generates looping functions for the call-ins based on their types
(except for SPECIAL functions, which must be provided with a
function that will generate the looping function). So, you'd need
to emulate the Script.GetCallInInfo() function to provide function
types.

[trepan]

lurker:
Ya, you're missing something. Reread my post, paying
special attention to why the 'if (WantConfig) ...' pattern
is better.

[Pxtl]

So wait, the "modoptions.lua" file is deprecated and the config parameters are stored in the gadget itself, allowing the gadget to be reusable as a stand-alone?

Good thought, as long as there's a way to hide the option and set a value from another gadget, so you can stick a bunch of gadgets together into a single gadget but have a new set of simplified options rather than barfing all their combined options to the user.

Either way, a way for the user to load multiple mods (each with its own suite of gadgets and _post.lua files) would be ideal, particularly when combined with a more modular modoptions system.

[lurker]

I don't think I'm missing the point of your post, I just made my question unclear. I'm asking about how to have function parameters in a file that's loaded into a chunk and executed. Example, the code I've been working on over the last week does this:

Code: Select all

local filenames = {vid2 = 'vid--evolution', frame = 'evolution\\frame.jpg'}
local files,prepmode = ...
if not files then return filenames end

Is using ... the way to go? Is there any other way? Is WantConfig an environment var instead?

Yay for programming constructs that can be construed as parts of sentences.

[trepan]

Ah, sorry, your second post certainly helped clear up the question.

Ya, using '...' to get input arguments also works, but I prefer the
'WantConfig' method because its purpose is more clearly defined.
Note that you could also scan source code or byte code for that
string pattern to determine in advance if the file is the type of
source code that you're looking for. Also, I think the following
lines at the top of a file is about as clear as it gets:

Code: Select all

if (WantConfig) then
  return {
    config_params...
  }
end

rather than:

Code: Select all

local opts = { ... }
if (#opts > 0) then ...

or

Code: Select all

local mode = ...
if (mode == 'config') then ....

etc...

They'll both work. The key point is that there be a return
statement when the config table is used for the function's environment.
And as this forces you to use two separate environments anyways,
I'd rather just have the configuration request tag done as cleanly
as possible.


P.S. the module handler code is something like this;
(treat this as pseudo-code :)

local chunk, err = loadstring(code, tag)
-- error check
setfenv(chunk, { WantConfig = true }) -- add VFS.Include and the like here
local success, config = pcall(chunk)
-- error check
setfenv(chunk, GetRealEnv(x))
local success, data = pcall(chunk)

[lurker]

Yeah, environment var is a nice way to do it. I'm not doing it that way because I run it in the global environment; it's a dev widget that only loads one file atm. I skip half the error checking too.

Should probably put in error checking when I prep it for release, though.