LuaRules. What is it? How do I use it?

[Fatal]

I am in the process of trying to make a simple tutorial mission for CA (well I am not certain of the mod yet, if not CA then BA). In the original thread I was instructed to use LUA in the scripting, but not long after that someone mentioned that LUA is outdated and that LUArules could work for both scripting and commanding the computer players, and that it's the thing I want to use.

However, I so far I haven't found any information on what LUArules actually is or how to use it. I've found and read numerous tutorials for LUA, but LUArules keeps on evading my grasp. To my knowledge the example scripts are in basic LUA, so no help from those either.

Please help me. Where can I find information on this?

[lurker]

A simple overview: The example scripts are in the spring lua script system, which as you said isn't that great. The suggestion is for you to use spring's lua rules system, where the gadgets live. Just open up CA and look at its LuaRules folder.

[Fatal]

Well yes, I'm in CA LuaRules folder, but practically all of it is uncommented, and there's so much of it that I have no idea where to start looking, nor to what to look for. Are there any tutorials on how to tame this beast?

Please don't hit me, I introduced myself to LUA just today.

[trepan]

http://spring.clan-sy.com/wiki/Lua_Scripting

[Beherith]

Fatal, for placing info, unzip the map Ooooweeee and look at where it placed the fog widget.

[Fatal]

Not that I would be ungrateful for your aid, I honestly appreciate anyone who bothers to spend some valuable internet time to help the new guy, but so far I'm still more or less in square one, altough I do have found one fellow springer who said he could help with the tutorial map scripting. The problem is, I'm anxious to get going and he hasn't been around in a few days.

The resource trepan posted is more or less useless to me at the moment. The analogy that describes this situation and that I've used sometime before is that I have a "build your own car engine" kit without a manual of any kind.

Beherith's tip is the first step; I have the folder called maps alongside with a folder called LUArules, in which I tell Spring what on earth to do with my map. Then again, during my #lua chattery, someone (can't remember who) said that LUArules should only be associated with mods and not maps, and that I would actually need to modify a mod to achieve the goal I'm after (or at least so I understood it).

After looking at various LUArules stuff made by other people, there's only one expression that defines how I feel about this.


WAT


seriously, I can't believe that some people have learned to use LUA by just looking at the resources I have been told to look at. I mean, I do understand some bits here and there, but that won't help much when I need to comprehend the basics first. Please help me, for great justice.

[Hoi]

WAT
seriously, I can't believe that some people have learned to use LUA by just looking at the resources I have been told to look at. I mean, I do understand some bits here and there, but that won't help much when I need to comprehend the basics first. Please help me, for great justice.

lol i think the same thing, but most of the people who start learning lua can already do c++ (aka programmers) and in some way understand all that stuff

[Evil4Zerggin]

Some of the major features of a gadget's code:

1. Info

At the top of each gadget there is "function gadget:GetInfo()". This basically tells Spring some basic information about your gadget: what your gadget is called, who wrote it, etc. The easist way to do this is to copy it from an existing gadget and change the info accordingly.

2. Synced Versus Unsynced

Your gadget runs in two modes: synced and unsynced. The simple way of putting it is that synced deals with things that affect all players (e.g., status of units), while unsynced deals with things that only affect a single player (e.g., GUI). gadgetHandler:IsSyncedCode() tells you which mode your gadget is currently in. You can do more when synced, but everyone has to run the code, not just the local player.

Many gadgets operate only in synced mode. This is why you often see things like

Code: Select all

if (not gadgetHandler:IsSyncedCode()) then
  return false
end

3. Speedups

Often you'll see things like

Code: Select all

local GetUnitDefID = Spring.GetUnitDefID

This is purely a performance thing: by "localizing" the function like this, you can get to the function faster later on.

4. Helper Functions, Local Variables, etc.

These are pretty much up to you and what you want to do with your gadget.

5. Callins

This is the meat of a gadget. These tell your gadget when something happens, and allow your gadget to take action (using the stuff Trepan posted). A callin looks something like this:

Code: Select all

function gadget:Callin(--[[arguments]])
  --your code here
end

Whenever an event corresponding to the callin happens, the callin gets called. Some callins are called with arguments giving information about the event. For example, when gadget:GameFrame(n) is called, n is the number of the frame. Furthermore, some callins expect that you return some value. For example, callins with "Allow" in their name typically block the action if you return a false value.

Callins are listed in gadgets.lua. You may find the following callins particularly useful:

gadget:Initialize()

This is called before the game proper starts, specifically when "LuaRules" shows on the loading screen.

gadget:GameFrame(n)
gadget:UnitDestroyed(unitID, unitDefID, unitTeam, attackerID, attackerDefID, attackerTeam)

[Fatal]

Now we're talking.

I'll do some research and come back with hopefully more precise questions next time.

Thanks a lot mate, this'll help me quite a bit. I reckon that since this will be a purely singleplayer endeavour, I'll just use synced code and be happy with it.

[trepan]

Changed the topic name to "LuaRules" from "LUArules".
Script name case matters in some instances (for example,
the inter-script links), so I'd rather it be correct in public
posts.

[Evil4Zerggin]

Since this thread is the first documentation of its kind as far as I am aware, I've linked to it from the wiki. Feel free to ask any more questions that you may have here, and I'll answer them as well as I can; if I can't answer them then hopefully someone else will.

I do have a question, however: is LuaRules now the way to make missions? Or is there some other system available/under development?

[very_bad_soldier]

EDIT: This was somehow needless, sorry...

But another question: I have learned gadgets run in unsynced AND in synced mode. How can I transfer variables from synced to unsynced code? Maybe I am wrong but when I filled a local variable in the global scope, it was empty when I checked the same variable in unsynced code.
Or is sharing of data from synced to unsynced code not the way it is meant to be done?

[FLOZi]

SendToUnsynced(...)
RecvFromSynced(...)

So, say, you have my_synced_var set in some synced code, you call

Code: Select all

SendToUnsynced("someStringDescribingMyVar", my_synced_var)

then in unsynced code you have

Code: Select all

function RecvFromSynced(...)
if arg[2] == "someStringDescribingMyVar" then
  local my_unsynced_var = arg[3]

So you will now have the same value in my_unsynced_var as you did in my_synced_var

[very_bad_soldier]

Thanks, this is very helpful!
But another question: Why are most callins like UnitEntered/LeftLOS only available in synced code?
And what can I do if my unsynced data needs to know about these events for drawing purpose? Is it feasible to just "route" each of these synced callins to unsynced code by using SendToUnsynced?
So in my synced callins UnitEntered/LeftLOS/Radar I only call SendToUnsynced to notify unsynced code about these events?

[lurker]

Unsynced luarules in 76b1 are rather limited compared to widgets. 77 will have at least most of the callins available if the user doesn't turn it off.
Running a bouncer in luarules wouldn't be great performance-wise, but it would work.

[123vtemp]

NOTA is the main/ only mod to my knowledge that has and will be turning out mission if you are interested you may be welcome to help

NOTA Spring forum: viewtopic.php?p=151901#p151901
NOTA forums:
http://nota.strategyboards.com/

Of course you would need to understand the game play first. The units in NOTA often need skill for devastating results.

[overkill]

Lua Rules != Nota style missions, nor is Nota style missions what he needs.

[FLOZi]

And just to set you straight, S44 has/will be having missions too.