Can we have a default LuaRules in springcontent?

[SpliFF]

Since it's nearly impossible to create even a simple mod without at least one gadget it seems odd to me that Spring Content doesn't contain a default/reference LuaRules implementation.

It seems the expected behaviour is to run off to CA or another active mod and copy theirs but this isn't a terribly good idea. CA's LuaRules includes a ton of things that are CA specific. I'm sure most mods are the same.

So can we please have a base version of LuaRules, main.lua and draw.lua so the ONLY thing a new mod needs is LuaRules/Gadgets/mygadget.lua ?

[FLOZi]

Since it's nearly impossible to create even a simple mod without at least one gadget it seems odd to me that Spring Content doesn't contain a default/reference LuaRules implementation.

It seems the expected behaviour is to run off to CA or another active mod and copy theirs but this isn't a terribly good idea. CA's LuaRules includes a ton of things that are CA specific. I'm sure most mods are the same.

So can we please have a base version of LuaRules, main.lua and draw.lua so the ONLY thing a new mod needs is LuaRules/Gadgets/mygadget.lua ?

This is S44's main.lua:

Code: Select all

if AllowUnsafeChanges then AllowUnsafeChanges("USE AT YOUR OWN PERIL") end
VFS.Include("luagadgets/gadgets.lua",nil, VFS.BASE)
VFS.Include("LuaRules/mineClear.lua")

All that is needed for a new mod (and I think most current mods use this method now rather than including the CA gadgethandler) these days (post 0.82 we can drop the AllowUnsafeChanges stuff) is (in both main.lua and draw.lua):

Code: Select all

VFS.Include("luagadgets/gadgets.lua",nil, VFS.BASE)

i.e. what you're asking for is more or less already there, and has always been

Perhaps though such basic main.lua and draw.lua could be packaged in base content LuaRules, but I assume there's a sensible reason all base content lua lives instead in LuaGadgets.

[SpliFF]

Yeah I copied that from smoth's mod. The issue though is that this is an "opt-in" system for gadgets when perhaps an "opt-out" would make more sense (ie, if you DON'T want gadgets/widgets you create empty files or set some kind of modoption).

The issue here is that I'm trying to document the mod creation process and the current process creates an unnecessary step between a new mod folder and a working "hello world".

Getting that far could be the difference between sticking with Spring, giving up, or looking for an alternative engine. What we're saying by not fixing this is that creating a mod requires copy-pasting trivial lines from other peoples mods / tuts to get started and I think it all just gets in the way.

Ideally a working "hello world" should require exactly 2 files: modinfo.lua and the "hello world" gadget.

[SirMaverick]

All that is needed for a new mod (and I think most current mods use this method now rather than including the CA gadgethandler) these days

That's the correct way to do it.

Yeah I copied that from smoth's mod. The issue though is that this is an "opt-in" system for gadgets when perhaps an "opt-out" would make more sense (ie, if you DON'T want gadgets/widgets you create empty files or set some kind of modoption).

Creating empty files to disable something is ugly, might lead to clutter. I prefer opt-in.

Ideally a working "hello world" should require exactly 2 files: modinfo.lua and the "hello world" gadget.

3 files is already too much? As FLOZi wrote you need a small file with a few lines to have gadgets.
Besides that afaik you need some files in gamedata else spring won't start.

[SpliFF]

3 files today, 30 tommorow. Spring has a history of crashing unproductively when presented with mods missing such trivial crap as beep6.wav and missing cursors. Spring content is perfectly capable of providing these things, just as it's capable of providing an easier way to activate gadgets (for example disable the gadget system if there are no gadgets).

The argument I seem to be getting is that it's easy for mod authors to add the necessary files, so why bother? Well obviously you should bother because it makes it difficult to start a new mod.

How the hell should anyone be expected to take an existing mod and know what is or isn't necessary? I know because the last time I tried it took me TWO DAYS TO MAKE AN EMPTY MOD!

That's right! It's hard to make a mod that does absolutely nothing!

There's no good reason for any of this. It's just sloppy. If 90% of new/testing mods use the same gadget handler, the same cursors, the same beeps then they should already be there. If you want to extend it you already can. No existing mods break because they already have their own.

Why should you opt-in for gadgets? What possible use would a game be without them? Even a mutator or content pack is going to inherit from the parent game. So basically you're saying most games don't need gadgets. In the VERY RARE situation where you really want to turn off the luarules systems it isn't clutter to have a single optional modoptions switch to do so.

What I'm saying is important. Depending on arbitrary files other than modinfo is a broken system. It forces new modders to follow convoluted instructions that tell the engine nothing it really needs to know. It means designing a new mod around engine bugs instead of fixing the bugs in the first place. It's how bad software gets written.

[SirMaverick]

3 files today, 30 tommorow.

It's more like, 30 yesterday, 3 today.
Seems gamedata files aren't needed anymore (or only needed when mod has units?). A 1 file mod is working for me. 3 Files for "Hello World". 2 if you directly print in main.lua instead of a gadget.

The issue here is that I'm trying to document the mod creation process and the current process creates an unnecessary step between a new mod folder and a working "hello world".

The argument I seem to be getting is that it's easy for mod authors to add the necessary files, so why bother? Well obviously you should bother because it makes it difficult to start a new mod.
How the hell should anyone be expected to take an existing mod and know what is or isn't necessary?

No one knows that from the start. He has to learn. E.g. by reading documentation that you are making.

I know because the last time I tried it took me TWO DAYS TO MAKE AN EMPTY MOD!
That's right! It's hard to make a mod that does absolutely nothing!

Took me less than 10 minutes.

Why should you opt-in for gadgets?

Personal opinion. It's easier to understand if you have to activate/add something, than "well it works by magic".
Btw. you have to opt-in for lua unit scripts, too.

What possible use would a game be without them?

I don't know. I don't know any mod that doesn't use gadgets.

Even a mutator or content pack is going to inherit from the parent game.

Mutator is not an own mod. Own mods inherit from nothing.

So basically you're saying most games don't need gadgets.

Thank you for claiming things I've never said.

In the VERY RARE situation where you really want to turn off the luarules systems it isn't clutter to have a single optional modoptions switch to do so.

Modoption might still be clutter, but you prevent empty file clutter that way.

Depending on arbitrary files other than modinfo is a broken system.

Code: Select all

return include("LuaGadgets/Gadgets/unit_script.lua")

**

It forces new modders to follow convoluted instructions that tell the engine nothing it really needs to know. It means designing a new mod around engine bugs instead of fixing the bugs in the first place. It's how bad software gets written.

If you found bugs you should report them.

Spring engine is complex. A few files mod doesn't help you understand how to make a game. Did you know you need 5+ files to add a single unit?
A Hello World is fine. But for a start you'd need a more complex example anyway.

**If CA is doing it wrong, please tell us.

[FLOZi]

You only need 1 file to make a mod run now, modinfo.lua (and it'd be pretty silly to run without that! Admittedly it requires you to depend on cursors.sdz, which could just be integrated into springcontent.sdz perhaps). 3 for a working LuaRules environment.

That's down from about 20 or so a year ago.


However, I'm still working on my ABC mods, A is just a modinfo and empty folders, B will be the most useful for experienced modders, all the luaRules and important gamedata files already in and ready to edit to your needs. The idea is that C will have actual example units and gadgets / widgets. That's not so much of a priority so far as CA, S44, and especially Damned (as it is small and all-lua) and most mods generally are pretty good for examples.

[Argh]

You could download one of my GLSL tech demos (particle system, normalmaps, etc., they're all basically the same), snip the crap that you don't need (not much, maybe 10-20 files- sounds and bitmaps, mainly) and write some documentation for each empty folder, so newbies know what is supposed to go there, and where to read about it on the Wiki.

That would give you an instant "mod" that doesn't have anything it absolutely didn't need, will run, and has the complete directory structure for all of the crap you want to add later to make an actual game.

Just a thought. Haven't ever had time to look over ABC mod, but I presume it's about as simple.

The other thing that needs to happen is that whatever is used is presented in a big, fat can't-miss-it-if-I'm-reading-the-first-tutorial-stuff download link for a Wiki article about "how to start using this engine to build a game", as the first step for would-be game designers. The issue with the ABC thing or my demo is that while neither is probably too bit-rotten to use, they're totally obscure from a newbie's POV. The Wiki needs a first-time-game-developer flow, very badly.

[AF]

IIRC you have yet to rerelease any of your demos etc to bring them into line with the latest spring. It is questionable wether they will load at all nevermind run under spring stable

[FireStorm_]

your demos

Except MM right?
http://springrts.com/phpbb/viewtopic.php?f=14&t=23945


One of Spliffs dummi-mods thought me a great deal.
At first I used it to see my own models walk around on stolen scripts.

Now a days, none of my test/mini-mods work any more. Trying to fix em has mainly resulted in disappointment. That has kinda halted the learning process.

I think stripped down mods would be greatly appreciated by starting modders, and even other community members.
At least I would...

[Argh]

Here is a working version of one of the tech demos. Stripped down, etc. I just haven't bothered to convert a couple of TDFs to Lua.

[FireStorm_]

he, thanks. much appreciated.