[WIP] Rough draft of Spring Lua Guide

[SpliFF]

IMPORTANT NOTE: The guide linked below is very out of date and should no longed be relied upon. Please refer to the Spring RTS Wiki instead.

Here is the first (still incomplete) draft of my Spring Lua Guide. It is intended to complement existing materials on the wiki and elsewhere.

Spring Lua Guide -> ODT or PDF

The original file is ODF (Open Office). I know this information *should* go on the wiki but the reality for me is OO gives me a much easier editing environment than the wiki provides. This is not designed to replace the wiki, but it is better for my purposes. One day I'll probably write an exporter to wikify this document but for now please don't post OT about the pros and cons of wikis.

This thread is for feedback on the accuracy of the information in the guide. I know many sections need more information but for now assume that I will expand the information and number or examples but haven't got around to it yet (or don't understand the topic well enough). Most of the current content deals with code and concepts I have actually used so it is a bit light on stuff I have no experience with (eg, map scripts). This is probably a good thing because writing about something you've never done is a good way to spread misinformation.

Feel free to drop missing information and corrections in this thread or via email (spliff/at/warriorhut.org) or PM.

[Chosker]

it's quite informative, pretty helpful for starters
thanks for this

[Gota]

Very cool,good job.

[REVENGE]

Wow...Spring Lua Bible anyone?

Nice optimization info, some of this stuff I've never seen being used in many widgets/gadgets

[Tobi]

stickied

[jK]

Wow...Spring Lua Bible anyone?

Nice optimization info, some of this stuff I've never seen being used in many widgets/gadgets

Some of the optimization info text is logicaly incorrect (twisted "slower" with "faster" etc.).
At best you check the source of those tips directly: CA's LuaPerformance Wiki

[SpliFF]

Some of the optimization info text is logicaly incorrect (twisted "slower" with "faster" etc.).
At best you check the source of those tips directly: CA's LuaPerformance Wiki

I know you wrote the tests but are you sure? I think there might be some confusion based on the grammer i used, ie:

runs slightly slower than: (do it the second way)

vs.

runs faster as: (do it the second way)

That second line might be accidently read as "runs faster than".

I'll improve the grammar but if I really did make a mistake could you be more specific? Also I've included these examples for the same reason I wrote the manual in the first place, often in free communities like this things get lost or moved. It's frustrating to have a manual say "check out these tips" and then get a 404. I haven't plagiarized your work, just reported your conclusions and put a credit and the original link at the top of the section.

[jK]

yeah, it has to be my denglish (english with german grammar), but imo "runs faster as" sounds like "runs faster than", but it could also be read as "runs faster in this form: ..".

[Peet]

yeah, it has to be my denglish (english with german grammar), but imo "runs faster as" sounds like "runs faster than", but it could also be read as "runs faster in this form: ..".

It does actually mean the latter, but it should definitely be rephrased to prevent that borderline-ambiguity.

[REVENGE]

Imo, you should just declare a piece of code to be slower or faster. Ie:

1. Slower Method:

Code: Select all

...

2. Faster Method:

Code: Select all

...

[TheFatController]

Some of the stuff in that performance guide is pretty biased with its percent figures

eg.

Code: Select all

Results:
nil-check: 0.297 (106%)
a=x or y: 0.281 (100%)

Conclusion:

  -> WOW! the or-operator is faster than a nil-check. Use it! :D

While 6% looks significant, that's actually 0.000000016 seconds difference per calculation which may as well be nothing.

[tinnut]

Hi SpliFF,

I quite like this guide of yours - have you been updating it? Can you post it up if you have?

Also, would you like some extra details on some of the call-backs and call-ins?

Cheers.

[Pendrokar]

.cheat .anycommand ---Is now written like this in 0.77---> /cheat /anycommand

Just telling to update

[hughperkins]

This is pretty cool

[Stealth870]

That's what I'm talking about! :D Nice work!

[Marmoth]

I think PlayerChanged() and TeamChanged() callins' descriptions are not accurate: they don't react in the described situation.

[SpliFF]

can you elaborate on that? they don't work at all, or they work differently? If so, how?

[Hoi]

Mind if I add it to the wiki?

OO gives me a much easier editing environment than the wiki provides. This is not designed to replace the wiki, but it is better for my purposes. One day I'll probably write an exporter to wikify this document but for now please don't post OT about the pros and cons of wikis.

P.S. I read that, but I'd like to put it on the wiki, becaus the current information in it is very usefull, I'll keep the page updated if you improve the guide.

[SpliFF]

The document is public domain so be my guest. I should probably put a CC or FDL license on it to make that clear.

[slogic]

Gadgets are similar to widgets except that widgets
tend to be UI oriented while gadgets can change the simultation

What's simultation? Simulation? Then i still don't understand the meaning of gadget.