Unit script have a menu button to switch between weapons

[smoth]

because I hate when a post is lost..

http://tvo.github.io/spring/2010/04/19/ ... the_stumpy
It says "This example makes the weapon of the stumpy fully functional. Here is the complete code:"

so from that page as one block...

Code: Select all

-------------------------------------------------------------------------------------------
-- Here piece numbers are retrieved (using the piece function) and assigned to the 
-- variables base, flare, turret and barrel.
-------------------------------------------------------------------------------------------
local base, flare, turret, barrel = piece('base', 'flare', 'turret', 'barrel')
local SIG_AIM = {}

-------------------------------------------------------------------------------------------
-- The call-in Create is called right after the unit is created. Because all pieces 
-- are visible by default, we need to hide the flare piece here, as it should 
-- only be briefly shown after firing.
-------------------------------------------------------------------------------------------
function script.Create()
	Hide(flare)
end


-------------------------------------------------------------------------------------------
-- This is a common pattern present in (nearly) all unit scripts you’ll read and write. 
-- AimWeapon is the call-in that is started by Spring when an enemy is nearby and the unit 
-- needs to aim at this enemy. Spring pre-calculates the heading and pitch and passes these to 
-- this function. Spring calls this function very often though, which is why Signal and 
-- SetSignalMask are used to ensure only one aim thread (per unit) is alive at any one time.

-- The next statements define the actual animation: the turret piece is turned towards the 
-- target at a horizontal speed of 0.5 rad/sec and a vertical speed of 0.25 rad/sec. 
-- The thread is then suspended until the animation has finished before it shouts ‘FIRE!’ 
-- to Spring by means of the statement return true.
-------------------------------------------------------------------------------------------
function script.AimWeapon1(heading, pitch)
	Signal(SIG_AIM)
	SetSignalMask(SIG_AIM)
	Turn(turret, y_axis, heading, 0.5)
	Turn(barrel, x_axis, -pitch, 0.25)
	WaitForTurn(turret, y_axis)
	WaitForTurn(barrel, x_axis)
	return true
end

-------------------------------------------------------------------------------------------
-- Once the weapon is fired (even if AimWeapon returns true it’s possible the unit does not 
-- fire because e.g. friendly units or trees block its line of fire) Spring calls FireWeapon 
-- for that weapon. Typically, this displays a flare and plays a recoil animation. That is 
-- exactly what is done in this example. First, the flare piece is shown and the barrel is 
-- positioned 2.4 elmos backward. Then the call to Sleep suspends the thread for 150 
-- milliseconds before the flare piece is hidden again. Immediately the barrel starts moving 
-- back to it’s initial position at a speed of 3 elmos/sec.
-------------------------------------------------------------------------------------------
function script.FireWeapon1()
	Show(flare)
	Move(barrel, z_axis, -2.4)
	Sleep(150)
	Hide(flare)
	Move(barrel, z_axis, 0, 3)
end

-------------------------------------------------------------------------------------------
-- Last but not least these two call-ins define which pieces Spring shall use as ‘origin’ 
-- in all the aiming calculations. If you are new to unit scripting, just follow the pattern 
-- presented here: AimFromWeapon should return the turret piece and QueryWeapon should return a 
-- piece at the end of the barrel. Later on you may use these to implement weapons that fire 
-- from multiple barrels on the same turret.
-------------------------------------------------------------------------------------------
function script.AimFromWeapon1()
	return turret
end

function script.QueryWeapon1()
	return flare
end

better forb?

[Forboding Angel]

http://tvo.github.io/spring/2010/04/19/ ... the_stumpy
It says "This example makes the weapon of the stumpy fully functional. Here is the complete code:"

No. Functional != complete.

For a complete tank script we need a few things.

I'll list everything, even the silly stuff:

Declaration of pieces
Declaration of variables
Declaration of signals used for aiming/firing weapon(s)
The commonly used "SmokeUnit"
Create function
AimPrimary
AimFromPrimary
QueryPrimary
FirePrimary
Killed function

The above is a comprehensive "Full script" for a basic tank, leaving nothing out.

Code: Select all

local base, flare, turret, barrel = piece('base', 'flare', 'turret', 'barrel')
local SIG_AIM = {}

function script.Create()
	Hide(flare)
end

function script.AimWeapon1(heading, pitch)
	Signal(SIG_AIM)
	SetSignalMask(SIG_AIM)
	Turn(turret, y_axis, heading, 0.5)
	Turn(barrel, x_axis, -pitch, 0.25)
	WaitForTurn(turret, y_axis)
	WaitForTurn(barrel, x_axis)
	return true
end

function script.FireWeapon1()
	Show(flare)
	Move(barrel, z_axis, -2.4)
	Sleep(150)
	Hide(flare)
	Move(barrel, z_axis, 0, 3)
end

function script.AimFromWeapon1()
	return turret
end

function script.QueryWeapon1()
	return flare
end

This unit functions, but what happens when it is damaged? What happens when it is destroyed? What about when the unit is done aiming and firing (restoreafterdelay)? What if I want to insert my own function in there? There are no examples.

Just because something works, doesn't make it complete. As perfect examples, I point to 95% of all bos scripts in existence

[smoth]

And yet I posted the complete armcom script

[Forboding Angel]

Smoth, I am addressing knorke's assertion that tobi's article had a full complete script where, in fact, it does not. Not even close.

[FLOZi]

Iirc I wrote the stumpy example which Tobi used, I'll see if I can find the original .lua when I get home from work

[Forboding Angel]

You guys tell people to use lus, when in fact there are very few "good" examples of lus where it can be compared to the same thing in bos.

People like me have good reasons for sticking with bos.

Smoth, sadly, your script makes for a pretty terrible example, although some of those functions look pretty useful for copy paste purposes in the future.

[smoth]

Why is it a terrible example?

[Forboding Angel]

Code: Select all

-- State variables
   isMoving, isAiming, isBuilding = "derpy spring", "derpy spring", "derpy spring"

I realize that that is jsut you having a sense of humor and having fun with crap that doesn't matter, but things like that make comparing a bos script to a lus script very difficult and mask the importance.

Think of using lus as learning a new workflow (because, well, it is!). In learning a new workflow, you compare new methods with the old, so that in the future, you know how to do it the new and improved way, but when the new doesn't even remotely resemble the old (exaggerating a bit) and you have coders being cute, it makes learning your new workflow a very slow process.

[smoth]

It isn't that different, not that script outside of the weapon Id crapola and all the math rad it is very similar. You are not seeing the forest for the trees.

[knorke]

I need an example of a tank with just a turret and a single weapon, could someone hook me up?

That was the question...
The "stumpy" tutorial answers it.

http://tvo.github.io/spring/2010/04/19/ ... the_stumpy
It says "This example makes the weapon of the stumpy fully functional. Here is the complete code:"

No. Functional != complete.

For a complete tank script we need a few things.

Yes, but hard to make advanced animdefs when not learnt basics yet.

I'll list everything, even the silly stuff:

Declaration of pieces
Declaration of variables
Declaration of signals used for aiming/firing weapon(s)
The commonly used "SmokeUnit"
Create function
AimPrimary
AimFromPrimary
QueryPrimary
FirePrimary
Killed function

The above is a comprehensive "Full script" for a basic tank, leaving nothing out.

The "stumpy" tutorial covers all of that. Note that there is a second page.

If you want to see more scripts that were meant as examples (both simpler or more advanced) then look at SpringTutorialGame or emmanuel's animDefs pages on wiki. Both linked in wiki.

Also my offer still stands.

[Forboding Angel]

Converted:
http://pastebin.com/QbUFbsi7

to
http://pastebin.com/3gSuRqjL

Anyone care to point out mistakes?

[knorke]

Code: Select all

Spring.UnitScript.EmitSfx (dirt, 1025)
Spring.UnitScript.Sleep(400)

No need to prefix with Spring.UnitScript.
where did you get that from?

[Forboding Angel]

Code: Select all

Spring.UnitScript.EmitSfx (dirt, 1025)
Spring.UnitScript.Sleep(400)

No need to prefix with Spring.UnitScript.
where did you get that from?

Wiki: http://springrts.com/wiki/Animation-LuaCallouts


Fixed some issues
http://pastebin.com/DKXjp6AG

but getting this error, which doesn't make sense to me:

Code: Select all

[f=0007923] [Lua unit script framework] Error: [string "scripts/eheavytank4.lua"]:50: bad argument #1 to 'Turn' (number expected, got nil)

So instead of using actual names of pieces I'm supposed to use piece numbers? And this is somehow a step forward?

Updated some more with missing areas:
http://pastebin.com/R0e7kPC6

Updated some more:
http://pastebin.com/sNETFi8K

[Forboding Angel]

Knorke, I just donated 15.40(usd -> 10.82 euro) to spring server.

I don't care how many you do, honestly, but what I really want is examples that I can use from unit to unit.

For example, you'll see in the hovercraft units that there are a lot of places where I reuse common elements. Yes yes, I know those should be set as includes. I had planned to do all that at a later date and lost motivation when lus came about, knowing that I'd end up having to do it later anyway.

The factory scripts are awful. The builders aren't much better. There is also some legacy code left over in turret scripts so that I would remember how to block shots if not enough power in an area (I don't use that method anymore for anything because it's an ugly noobtrap).

The script I have been working on is the eheavytank3 (Crusher - Hovertank).

Tbh, if I can get that single script running, then it's pretty much a copy pasta fest over 95% of the other mobile tanks.

What I really need though is to be able to compare how things are done in bos, to how they are done in lus. From what I have seen so far, I have more or less used intuition and been right about 90% of the time, which is encouraging.

Being a lus newbie myself, I believe that once I see examples relevant to what I already have, I can probably put together a guide that will be a bit more useful to nubs than what is currently available.

[knorke]

So instead of using actual names of pieces I'm supposed to use piece numbers? And this is somehow a step forward?

variable name: barrel vs barrel1

Common mistake, but newbs always seem to shrug it off as "lol typo" or "oh silly synthax", but trick is think how to prevent that from happening or how to find it more quickly.

It is actually supereasy to catch. Like literally in seconds.
Still it is the kind of mistake where peoplepersons go "lol i spent whole last night fixing that." And that creates the rumors of "lua so hard."
While that sometimes legimately happens, in many cases it is supersilly. In cases of newbs it is always supersilly. (I know because newbing around myself)
So here how look at such message:

Error: [string "scripts/eheavytank4.lua"]:50: bad argument #1 to 'Turn' (number expected, got nil)

scripts/eheavytank4.lua is the file name obv.
50 is the line number

go to that file + line:

Code: Select all

Turn(barrel, x_axis, pitch, 25)

bad argument #1 to 'Turn' something is wrong with the first arguement passed to function Turn()

arguement #1 that is barrel

(number expected, got nil) Says what excactly was wrong: function "Turn" wanted ("expected") a number, but got nil.


So now one looks what was wrong with that barrel.
Since variables do not change to nil on their own, and piece-variables basically never need to change value, most likely case is always typo.

So one looks where is barrel declared:

Code: Select all

local base, turret, barrel1, firepoint1, dirt = piece('base', 'turret', 'barrel1', 'firepoint1')

and checks spelling
Most pro way to check spelling is to select word, in basically editors that makes it highlight other occurences of the selected word. So easy to see which one was mistyped:



(just to show example, no idea if in script there is more errors)

[Forboding Angel]

Understood.

Yep, silly error. Not syntax of course, just derp.


Doesn't error, mostly seems to work (looks like smokeunit part and sfx occupy parts are still lolbroked), but refuses to fire. It does aim on it's own though. I was thinking I derped the signal, but that doesn't seem to be the case.

http://pastebin.com/R17qvnhU

[yuritch]

Not sure this will help, but here's the full LUS for a large ship: link. I've made that years ago, but the unit is not in S44 (since it's too large) and naval submod never got much development.

Pieces are referenced by names here (actually those are variables which get values from piece() function, but it's like that in BOS anyway)

[FLOZi]

Original stumpy lus side-by-side with bos (in comments)

http://pastebin.com/yk2w3k0B

[Forboding Angel]

Very nice flozi. You should add that to the wiki. Very useful.

[knorke]

Today was erster Ma jawohli: too lazy for shortening it or proofreading.

1)
unit_script.lua:
in evo contains the whole blabla - instead of just including from basecontent.

1b) Maybe that is why your script doesnt fire, with that fix it does. Didnt try without.
1c) Turn(turret, y_axis, heading, 25) --use math.rad(25) to convert, otherwise that is instantly fast

2)
In setSFXoccupy()
The bos script has line:
set UPRIGHT to 1;

Now in your http://pastebin.com/R17qvnhU it got converted to: local upright = true
Which is completly different:
The bos was a toggle between having the tilt with terrain or not. (aka "upright")
The lua is just useless declaration of a variable. Does nothing.

It seems the idea was to have some logic that hovers tilt to terrain when on land, but stay parallel to surface of water.
But on water are always parallel to water anyway.
There is no need to copy all this, just calling SetUnitValue(COB.UPRIGHT,0) once archives same effect.

3)
Why is there so much if-else in setSFXoccupy()
terraintype will either be 2 or 4 (water and land)
Animating the unit in so tiny upwards motion is unnoticeable anyway:
move base to y-axis [-0.85] speed [50];

4)
In SmokeUnit() there are two if's to decide which smoketype to use.
Originally probally was: emit-sfx smoketype from base;
But now smoketype never gets used...just always the same emit-sfx 1026 from base;

5) On the 1026 from 4)
EmitSfx / emit-sfx
For custom CEGs from unitdef it is
emit-sfx 1024 +n from piece;
with n = number in order how CEGs are declared in unitDef.
Kinda makes sense to write like this because one can see 1024 +3 = it is the third CEG.
Just small thing to make it bit easier to read.
But eventually peoplepersons start to shorten 1024+3=1027
and in Lua carry on like: EmitSfx (dirt, 1025)
better is:
EmitSfx (dirt, SFX.CEG +1)
or just use Spring.SpawnCEG ("cegName",...)


There is much more like that in many scripts.
Variables that get changed via some complicated looking logic - but useless because they never get used anywhere.
if-while-else-bla constructs that always resolve to if (true), no matter what input.
All that is result of copypasting stuff together without understanding it.

But now we want to leave bos behind, so why is any of that still relevant?
Because history is repeating itself.

I mean things like this:

What I really need though is to be able to compare how things are done in bos, to how they are done in lus.

It is too much state of mind like: "How does this bos-thing translate to Lua-thing?"
Instead should think: "What do I want the unit to do? And how to archive that?"

Because the other way only works for very basics.
Like:

Code: Select all

hide piece; 

becomes

Code: Select all

Hide (piece)

But that is just bit different looking form of writing.
After reading the stumpy-tutorial and if one knows bit Lua it is obvious.
Now you know the new synthax but are still just writing bos script style.
And adapting their errors.
Or it results in "blind porting" things like the local upright=true or many other examples throughout forum.
http://springrts.com/wiki/Animation-Cob ... ua_scripts

Not sure this will help, but here's the full LUS for a large ship: https://github.com/spring1944/burning-w ... gangut.lua

It begins with 50+ lines, each one declaring multiple variables with names like aa37_flare_43.
Tables! Good thing those variables are never used in script
But still so much duplicate code...? Did not look too closely..if it works then all is good but for learning? The length alone makes it unsuited for that.


eheavytank.lua: http://pastebin.com/ksZaF5ge
The bos script had something to make the unit rock from recoil of firing weapon.
But it did not work right: It rocks around wrong axis. (Make unit face to east, fire gun to north, to see.)
I just translated that behaviour, even if it was wrong: The rocking was originally so small and it was almost unnoticeable.
It was more a "jerking a bit" instead of real rocking.
Still for real recoil rocking has to do like for ex. zero-K.

For smoke, I made damageSmoke (), at top once can adjust from where to smoke:
local smokePieces = {base,turret}
and also can adjust the CEGs in function itself of course.
It also uses two different CEGs based on damage.
There is tons of ways to make unit smoke, with the delays between smokes, where smoke/fire is emitted from etc.
Imo perfect canidate for make a damagedUnit.lua that always gets included. (like some mods do)

The only use left of setSFXoccupy was to decide if unit is in water or not, to toggle which effect to show when moving.
In Lua could be done different (see other script), but for sake of staying closer to original it uses setSFXoccupy again.

eamphibrock4 .bos
https://code.google.com/p/evolutionrts/ ... brock4.bos
(As .lua: http://pastebin.com/y5WMPMsN)
Has these long if-ripples that bos is famous for:

Code: Select all

if (shooting_num==1) 
     {  
     	piecenum=firepoint1;     
     }

     if (shooting_num==2)
     {   
     	piecenum=firepoint2;
     } 
     
     if (shooting_num==3)
     {   
     	piecenum=firepoint3;
     }
	 if ...
	 

With the port-bos-to-Lua approach that would result in same thing again.
(So in Lus looks bit different now.)

Wheels could simply be:

Code: Select all

StartMoving() { spin all the wheels }
StopMoving() { spin all the wheels }

Instead weird thing with the while (true)
Yes, there is one emit-thing in the loop too, but it still means that the wheels might stop/start with delay of sleep 400;
Since the function is again unfittingly named Thrust() I again assume copypaste fail.

Instead of always emiting dust-CEG like original I decided to make:
-dust on land (when moving)
-bubbles in deep water (always bubbling)
-wakes in shallow water (when moving

Also: the CEG for muzzleflash has ttl=2 meaning it is practically invisible. (for testing i put to ttl=20 to even see it)


In general:
Many spring unit scripts are actually really basic.
So basic, that copypasting should ONLY be done to save typing.
(compared as to copypasting because can not do it otherwise)
Usually there are some simple if's, some loops, maybe an array. (in bos not even the array)
That is the chapter that comes after "Hello world."
And there is some "spring stuff" like AimWeapon() or Killed() which is always the same.

Honestly:
If you feel like needing to copy that, then the time is better spent at learning about programming in general. Might stumble onwards like that, but every slight obstacle means landing on nose.
SpringTutorialGame, stumpy tutorial and other examples should be enough to learn basic unit scripting.
But of course none of those is a tutorial on Lua or scripting itself - that must come from elsewhere.

Maybe some fancy looking walk-animations are long, but they usually have no complex algorythms or math either.
(exception: some scripts by zwszg or few others where legs try to stay in contact with terrain etc, instead of always doing the same motions)
But usually they are just many commands in waterfall fashion.
Sometimes via some keyframes (for ex. emmanuel's scripts), sometimes literally just many pages of Turn/Move commands.
All that it needs to make that is endurance - that means it is boring.

Not every bos script has to be ported to Lua.
If there is no plan to work on it (like integrate more with gadgets etc), then is just waste of time and risk to maybe add some bugs.
Even if there is lots of nonsense in script, if it works then it works. That is okay.
BUT that does not mean one has to use these nonsense scripts as base for anything new - be it lus or bos.

eamphibrock4 .cob as Lus: http://pastebin.com/y5WMPMsN
eheavytank3 script as Lus: http://pastebin.com/ksZaF5ge

interblog needs pictures: