Quote from Scawen :

I thought I'd better post this here in case you think of a good reason for every line to start with a slash. I don't want to regret that decision and have to change it further down the line when there are hundreds of scripts around.

line wrap on long scripted lines ... easier to tell wher the command begins and where it ends

a comment symbol which is easier to distinguish from the leading character of a command line would be nice though


ive also noticed theres no autoexec script as of yet ... i cant think of a specific use for it atm but somwhere down the line it might be a good idea

Quote from Honey :

i1) less programming skilled people who start to learn lfs scripts, may be higly confused and make a lot of mistakes putting the slash where is not needed and skipping it when they shouldn't -> i guess it will be the top reason for issues and make forum full of threads asking why their script with correct syntax is not working

Well, that's simple : Slash is never needed! Nothing can be easier than that!

The only time you would ever need a slash is if you type a single command into a chat box.

Quote from Shotglass :

ive also noticed theres no autoexec script as of yet ... i cant think of a specific use for it atm but somwhere down the line it might be a good idea

What's that? I mentioned "entry.lfs" (which would be run when LFS gets to the main entry screen - though I didn't explain that). Is that what you mean?

Quote from mrfell :

Just been setting up the scripts for DFP and notice this everytime i start a single player game. The only thing i can think of is i have 2 axis not calibrated, mainly because i dont know what they are.

One command in a script you are running should be like this :

/command parameter1 parameter2

But you have :

/command parameter1

I am going to make it more helpful - it needs to tell you the script and the line number where the problem is.

OK thanks, i'll have a look and let you know

Andrew

Quote from Scawen :

Well, that's simple : Slash is never needed! Nothing can be easier than that!

The only time you would ever need a slash is if you type a single command into a chat box.

Noooo! The same reason the "/" is needed in the text box should follow for scripts. Of all the different aspects of scripting, prefixing a command with a "/" is the simplest concept to grasp. Losing it, however, is the fastest way to confuse anyone trying to interpret a script they're reviewing.

Well I think I'll have to go with removing the / command. And I'll explain why. But before I explain, I will mention, that no-one has come up with any real reason why it would go wrong.

And now the explanation. On further consideration of the command :

/event time 19:00 /say hello .. OR ... event time 19:00 say hello

I realised it would be nicer to say :

at 19:00 say hello

And then I've been thinking of other event starters like "in" and "on". For example :

in 5 sec say hello
on race_start say good race

But these can be combined!

on race_start in 1 min say this is cool

See... that statement contains 3 commands, but reads very easily! Much better than :

/on race_start /in 1 min /say this is cool

[ how it works : "on" is followed by an event indentifier (e.g. race_start) and inserts the remaining command into that event. So at the start of the race, the remaining text is executed. So it runs "in 1 min..." which attaches the remaining code to a new event which will occur in 1 minute. So then after 1 minute it runs the remaining code "say this is cool". ]

I like the idea of removing the / before commands, the only thing I think that will make the code more friendly user is to add " or ' betwen the text to output in the say command, so you know where the output text starts and ends.

Example:
on race_start in 1 min say "this is cool"

if you plan to implement events like this, then you definately must keep the slash, otherwise, what would happen for such lines?:

on race_start say race is starting in 1 min

in 5 sec say say

nicer sintax are always the worst, who is writing code always want unambiguos sintax...you may make it unambiguos to interpret but surely is damn ambiguos to read, imo yet as it is, the sintax should be enforced with commas and parenthesis to make it more clear and robust.

Quote from Honey :

if you plan to implement events like this, then you definately must keep the slash, otherwise, what would happen for such lines?:

on race_start say race is starting in 1 min

in 5 sec say say

nicer sintax are always the worst, who is writing code always want unambiguos sintax...you may make it unambiguos to interpret but surely is damn ambiguos to read, imo yet as it is, the sintax should be enforced with commas and parenthesis to make it more clear and robust.

That's why i suggest using the " or ' for outputting text, that way you won't mix code with output text.

Personally I don't like easy to understand but long code, when you get used to write code adding words that are not strictly necessary it's kind of annoying, I just like functions and parameters.

They aren't needed because absolutely everything after a say command or an echo command, is what is to be said.

There are no more commands on a line following a say (or echo, or msg, or rcm).

Quote from RiGun :

Personally I don't like easy to understand but long code, when you get used to write code adding words that are not strictly necessary it's kind of annoying, I just like functions and parameters.

i perfectly agree!!! so you too are for keeping the slash, right?

Quote from Scawen :

What's that? I mentioned "entry.lfs" (which would be run when LFS gets to the main entry screen - though I didn't explain that). Is that what you mean?

whoops must have missed that ... pretty much the same
in fps games the autoexec.cfg is the one thats read at startup (just like the autoexec.bat really)

Quote from Scawen :

Well I think I'll have to go with removing the / command. And I'll explain why. But before I explain, I will mention, that no-one has come up with any real reason why it would go wrong.
[...]

i much prefer something in the realms of

/wait on "list of triggers"(
/wait for n mins
/say blubb
)

this would also enable you to do scripting and things like that from the chat window
and didnt you want to ass loops and ifs at a later point ... i dont see how you could make those nonconfusing with the syntax you proposed

much easier to read and debug imho

Quote from Honey :

in 5 sec say say

say say say !
(had to be done sry )

Quote from Scawen :

They aren't needed because absolutely everything after a say command or an echo command, is what is to be said.

There are no more commands on a line following a say (or echo, or msg, or rcm).

maybe your examples for events, just mislead us...only you have in mind what in the future you want or not want to implement, just keep in mind that powerful and robust interpreters (i.e. bash) have a "strong" sintax with clear delimiters and rules...if i was you i would keep the leading slash and also i will use another character like "^" or "|"...but that's just an opinion...

Quote from Shotglass :

say say say !
(had to be done sry )

i like that goldie oldie

On "on"/"at" events, please consider making it possible to string multiple commands together, or will we need to run script files to achieve more than one command, on event?

For example: "at 19:00 say World cup final is starting! : end_race"

versus "at 19:00 run gameover"
where..

Quote from gameover.lfs :

// This script should run at 7pm
say World cup final is starting!
end_race

It could save quite a myriad of very small .lfs files running around, creating havoc.
(I don't know if end_race is planned as a command. It's for illustration only.)

Are there any tut's for scripting ? I was happy to hear about making my own player-views for each car, but i dont know how to do this

For the timing business, I would prefer (unless this is a pain in the ass for Scawen) "/wait" (obviously remove the leading slash if that goes) e.g. "/wait 5" means that it waits for 5 seconds and then does the next thing in the script. And as for set events, that could be "/waituntil".

Provided semi-stupids like me can knock up a basic script with timing, I'm happy

Quote from Honey :

i perfectly agree!!! so you too are for keeping the slash, right?

No I don't like to type a slash every time I want to call a function, that would be confusing with the comentaries.

Scawen,

if you want to add special keywords like at, on, in, then a delimiter for multiline scripting is definitely needed. eg:


also I think string delimiters are definitely needed for keeping the code a bit tidy and readable. In a month or two, when LFSScript (well, the Language needs a name, doesn't it?) is out of it's beta-phase, some people will come up with the first LfSScript Editors / Editor Plugins.
And its pretty hard to highlight a string when you don't know where it begins or ends...
and it keeps the code readable, as I already mentioned.

Imho with slashes is much faster to read and understand the code.
(for non english motherlanguage people, maybe english ones feel better without slashes)
Without, code and text lines will seems the same.

I think that the / truely defines what a script is, it may help to have the / so then we can see what is a script input and what is the output, yes the /on 6:00 /say ZOMG ITS 6:00! looks odd, but its easier to decipher what is what in case you need to change parts of it.

I would agree that text delimiters make sense and make the code easier to read.
How else are you going to do conditional statments like

If x=1 say hello else say goodbye

and for that matter, if you do variables, would you have to delimit them with a /?

/If /x=1 /say hello /else /say goodbye

I also think that with a simple editor environment where keywords and commands are highlighted like in most dev environments, the / delimiter becomes redundant. It makes perfect sense in the text box to break out of chat mode and into script or command mode.

I'm sorry, but I have never written a scripting language, so I can't think of any situation where not having the / would be a problem.

SpeedScript is my vote for the script name

Quote from Hallen :

SpeedScript is my vote for the script name

Why not LiveforScript? lol

speedscript(tm)