Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on October 16, 2005, 04:37:58 pm
-
Internal thread (for me when I start coding this):
http://www.hard-light.net/forums/index.php/topic,33845.0.html
As per mikhael's request, a brief outline of stuff I'd like to have
gr - Basic graphics library
For all 2D drawing functions, like line, circle, box, bitmap, etc.
g3d - 3D graphics library
For all 3D drawing functions, like models or bitmaps in 3D space or maybe 3D lines
sxp - SEXP functions
Maybe just an evaluate-sexp function. This would mostly be a hack to get SEXP data and functions integrated where Python doesn't have 'em
mth - Math lib
Whatever functions aren't included with default Python math libs.
Presumeably some of the appropriate python libs would be imported by default, so you wouldn't have to import them every time. The math library in particular, since getting rid of the prefix would make it more readable and easy to use and there really aren't many functions named "cos"
Past that...
Ship class
Features simple stuff like get_speed get_name get_target etc.
Mostly I've been more concer
HUD Stuff - basically once new HUD stuff is define, it turns off the original ones. The goal is more to provide an all-new system than to integrate with the old one, that would be more trouble than its worth.
Now to quote my post in the big feature thread:
For the new HUD I was thinking along similar lines. The old :V: system is so hardcoded it isn't even funny.
For both of these I'd probably be relying alot on Python integration as well to give a lot of flexibility (without sacrificing much simplicity) to modders.
So general idea for a gauge entry:
$Name: Blah
$Show in: ("cockpit" "target cockpit")
$XCoord: 100 ;; Draw 100 pixels to the right of the left edge of the screen
$YCoord: 240 ;; Draw 200 pixels down from the top edge of the screen
$Draw: {
# What you want to draw goes here. Like to draw a
# 100 pixel-square X:
# Top left to lower right
gr.line(0, 0, 100, 100)
# Top right to lower left
gr.line(100, 0, 0, 100)
# Draw the current target model too?
g3d.draw_ship_model(self.target(), 0, 0, 10, 10)
# Write the name in the upper left
gr.text(self.target().get_name(), 0, 0)
# Note that 'self' would refer to the ship you're
# currently viewing from, rather than just the player ship.
}
Gauges would be separated into different 'screens' (I use the term because that's the class name for the new GUI, Gui_screen), each screen would correlate to a different ship type or something.
Assuming all this got implemented, it'd be really really flexible; you could do pretty much anything you wanted with the HUD, the only limit would be how advanced of Python knowledge you had. [/B]
-
So, is this mainly a script your own HUD thing, or is this intended to eventually be linked deeper into the engine?
-
Right now it's going to be mainly for the HUD thing, but if I can get it working, Bobb has expressed an interest in using it for the textures system.
I'd also like to use it for the armor.tbl system to get rid of the cumbersome calculation system in there now.
I didn't really plan on linking it into the physics system or something, but things like that could probably be arranged on request. My *preference* would be to have a global functions library, so everything available in the HUD would be available elsewhere.
-
I was thinking more along an abstraction layer between the low end engine, and the player, implementing all the existing game systems and SEXPs in Python. That would make the engine fairly universal and move the hard coding up to a level where more people could deal with it. It would also have make certain things (complete ship animation channels and the like) more readily available.
-
Yeah, that's a lot more work than I'd like to plan on doing at the moment.
If I can get the system I described fully working it'll be a huge step forward in hud modding and very extendable.
-
If I can help with the python stuff, I'll do anything I can.
-
NO NOT PYTHON!! :shaking:
*runs away screaming*
-
Why not python? Python rocks block. :)
-
What scripting language would you recommend (Besides SEXPs :p)?
-
I nominate Perl. Or Rexx. Or VBScript. Or PHP. Or Java!
No really, I mean it. Stay with Python. It is TEH WIN, to be so 20th century. Easy of readability, good exceptions, good tracebacks, lambdas, blah blah blah.
-
think you could move more stuff into python, so we could do custom weapon flags and such?
i dont care what scripting language you use, just so long as its about the same ease of use as quake-c.
-
Basic interpreter is up-and-running.
- I can't compile in debug mode because I don't have python24_d.lib
- I haven't gotten it so that you can drop the initial "gr." and the like via C
- I've coded the basic HUDGauge GUI function, but haven't actually gotten proper parsing set up (right now it just reads 'python.tbl' and executes Python after $Python:)
However, here's going to be the basic idea wherever Python is involved...
At program start, *all* libraries will be initialized. These will be usable in all fields, at least via the "import" command.
(TODO) Individual subsystem (EG HUD, Texture system) may define libs to be auto-imported, so no import command will be necessary. Or, they can make all functions available.
Wherever a Python 'field' is, you can do one of two things. If you just want to throw in a single-line expression:
$Python: gr.line(1,2,3,4)
Or, if you want a multiple-line code block:
$Python: {
gr.line(1,2,3,4)
gr.line(4,3,2,1)
}
THe {s may be pretty much anywhere you like so long as the Python code is inside them.
The onlylimit to how long a Python code block may be is the maximum parsable filesize. A line may be up to 4096 bytes long. (But you should really be using a code block for that :p)
-
Here's the basic C API in fs2_open:
PyBytecode python_parse();
The magical parsing function; it compiles Python into bytecode. AFAIK you do not need to have a 'session' going for this to work
PySession py_session_create();
Creates a new Python 'session'. This is a virtual thing I came up with to make everything easier on the mind. Any modules you import etc will only be availabe in this namespace
void py_session_import_module(PySession* session, char* module_name);
Imports a module into the current session; the same as saying "import module_name" in Python. (Still not working)
void py_session_use_namespace(PySession* session, char* module_name);
Makes a module's functions freely available, without needing to use the module name. (Still not working)
PyResult py_session_evaluate(PySession* session, PyBytecode* code);
Actually executes Python code that was parsed into bytecode.
I've tried to abstract stuff as much as possible so it's not necessary to worry about calling X_INCREF and X_DECREF (PyResult, PySession, and PyBytecode are all basically identical classes that call them).
-
I've got single-line expressions successfully evaluating as strings, floats, and integers in C.
Basically this adds a few functions to PyResult:
bool GetLong(long *dest);
bool GetDouble(double *dest);
int GetString(char *dest, int dest_size);
As far as modding goes, the basic limitation here is that it looks like that if the field takes a return type, you're not going to be able to take multiple lines. Meaning, I don't think you'll be able to import something for something like "$X Coordinate:".
-
Originally posted by WMCoolmon
What scripting language would you recommend (Besides SEXPs :p)?
Pretty much anything except Python. I've had too many bad experiences with it.
And don't get me started on that thrice-cursed indentation rule. If I wanted whitespace to stand for anything, I'd use Whitespace.
-
Originally posted by Goober5000
And don't get me started on that thrice-cursed indentation rule. If I wanted whitespace to stand for anything, I'd use Whitespace.
That is a joke on itsself. A good one too....
-
Are you saying that python is whitespace sensitive?
-
if my.func() is True:
my.do()
my.otherthing()
do() will only execute if func() is true; otherthing() will always execute. A tab is used to delineate a code block, or whatever they call it, rather than brackets.
It doesn't look like it has any problem if you start off with a tab or something.
Also, I think that it's sensitive to tabs, rather than spaces (i used five spaces in the example b/c i'm lazy)
-
Originally posted by FireCrack
Are you saying that python is whitespace sensitive?
Yes, it is. Python enforces a consistent indentation patter at the block level. It doesn't matter how you do your indents, so long as they're consistent. This annoys sloppy coders.
This makes people like me, who have to read other people's code a lot, very very happy.
-
Originally posted by Goober5000
NO NOT PYTHON!! :shaking:
*runs away screaming*
-
Oh, give it up, Kaz. Neither of you seems to have anything substantive to say about it. Its just kneejerk stupidity.
Mik, please reconsider this post in the light of my post immediately following. :) -- Goober5000
-
Originally posted by mikhael
Yes, it is. Python enforces a consistent indentation patter at the block level. It doesn't matter how you do your indents, so long as they're consistent. This annoys sloppy coders.
This makes people like me, who have to read other people's code a lot, very very happy.
I very much agree with the basic sentiment behind that. I'm a stickler for clean code formatting - spaces on either side of every operator, newlines between logical segments of code, etc. Clean code is readable code is easily-debuggable code.
But I vehemently disagree with the way Python enforces it. It violates one of the fundamental tenets of engineering design: separating form and function. In order to make code do a particular thing (its function), you have to enter certain coding symbols. But you should also have the right to arrange your code (its form) in whatever way you see fit.
This is the rationale behind TeX and similar typesetting schemes: you write your content (function) and you design your typeface (form), but you do them separately. If you need to completely reformat your academic paper in order to submit it to a different conference, you can do it simply by swapping out the current design and swapping in the new one.
It's the same way with formatting. Different formatting styles are matters of opinion. Although I very much dislike the Kernigan and Ritchie brace style (and in fact tend to rewrite it in BSD/Allman style if I'm working on it to any significant extent) I can understand the rationale behind using it and support the coder's right to arrange it in the way he wants. If he wants to enter the Obfuscated C Contest that's fine by me and I will stand by his right to do it. But I will run his code through a BSD/Allman pretty printer before I even attempt to mess with it. :D
There is a very significant distinction what a coder should do (i.e. make his code readable to others) and what he has the right to do (i.e. design his code however he wants). In conflating form and function, Python completely steamrollers over that right.
Now that's just the philosophical argument. The practical argument (whitespace getting corrupted via spaces converting to tabs or tabs converting to spaces) is a whole new argument altogether. :D
-
I 100% agree with Goober5000's assessment - plus using scripting languages in performance-intensive applications targeted at non-scalable archetectures is simply asking to have you system bogged down to next to nill performance.
-
Originally posted by mikhael
Oh, give it up, Kaz. Neither of you seems to have anything substantive to say about it. Its just kneejerk stupidity.
Mik, please reconsider this post in the light of my post immediately following. :) -- Goober5000
Hey, I wish I could edit other people's posts for no other purpose than to give them orders. Such a great use for mod powers...[/sarcasm] :doubt:
That being said, I don't totally disagree with you. I'm plenty annoyed with 'proper' coding styles in languages with {s is to put them so that the conditional is right above the code; IMHO it makes it look cluttered. So I like the freedon to do whatever the hell I want with it.
In fact these days, I tend to use K&R for short conditionals, and BSD/Allman for either branching or long ones.
So when I get to Python, I feel somewhat naked without my lovely braces. :p
However Python does have going for it a simple syntax, that will work for short expressions or longer blocks. Its API documentation is a piece of crap IMHO, but I can compile the code and then run it repeatedly.
It's cross-platform and thankfully the only difference seems to be the libs. It's fairly well-known and popular, so there are a lot of tutorials on how to use it.
To answer Kazan's complaint, I'd like to point out that we already have one scripting language, the SEXP system. But that doesn't seem like it was ever really meant to be edited directly by your everyday modder, nor does it work well for short expressions.
I could hack in hardcoded things like lists and such, but that seems a bit stupid when I can provide the tools to people to do that themselves, and give them a lot more per-mod flexbility in the process.
So, rather than have the SEXP system, an expression system, and a scripting system, you have the SEXP system and one scripting system whose functions can be used for both expressions or logic loops and whatnot.
-
SEXPs are an expression system, not a scripting language - orders of magnitude of complexity difference
-
I have to say that I disagree that it is a basic engineering principle to seperate form from function. And I'm pretty sure both my grandfathers would agree with me, having worked for Hughes Aircraft. The basic form of a missile is integral to its function, and has been since the very first V2 rocket, which was actually the first ever medium range ballistic missile.
There is no reason at all why programming shouldn't follow suit, code parsing correctly being dependent on formatting of that code. As has been observed, it does annoy sloppy coders that Python is this way. You know what? GOOD! Neat code IS easier to debug. Furthermore, IMO, it seems to me that sloppy coding often causes more bugs to be introduced into code simply because it is sloppy. And sometimes is the cause of bugs on its own. I applaud the designers of Python for forcing would-be programmers to make clean clear code.
-
i guess il need to study up on my python, any of you coders know a good tutorial off the tops of your heads thats relevant to the way this system will be implemented?
-
CaptJosh: do yourself a favor and STFU
1) Missiles are not programs - aerodynamics is one of the small list of things there form and function are integral to each other - PROGRAM CODE IS NOT
2) nobody gives a rats ass what your grandfathers did, it doesn't make you special, stop talking about it ever seven seconds
3) you're being an attention whore - STOP IT
4) Have you even written code?
-
i find the best engineering feats occure when designers reject the established rules and design something totally out of the box. it usually comes out really cool, or becomes a disasterous failure. either way its amusing :D
and josh, stop being an attention whore, theres only enough room for one and the position is already filled :D
-
Thanks for showing your lovely tact yet again Kazan.
I like the idea of python for scripting (though to be honest I like ruby better). Python's a well thought-out language that's easy to read and has a rich feature set.
BTW: There are many examples of successful games (some of them far more resource intensive than FS2) that have used scripting languages. Homeworld 2 uses lua all over the game. Heres's a blurb from the lua site about it:
Homeworld2 is a space PC RTS game that uses Lua4 extensively in almost every aspect of the game, including the UI, AI, game rules, game flow, stats, game attributes, game tuning and automation.
-
Lua is supposedly faster than Python, it's also used in Far Cry, and the examples on wikipedia didn't look too bad.
It's pretty similar to python actually.
I think Ruby is somewhat more complex, though; Python is about as simple as I can see a programming language getting while still being efficient.
I don't have experiene with either Lua or Ruby tho.
Edit: But at this point, I'm strongly biased towards Python because I know it's usable & I have the majority of the needed stuff implemented.
-
Kamikazi: i have a low tolerance for repeated expressions of Narcassitic Personality Disorder
if you hadn't notice he's been doing that in thread after thread after thread.
-
Kazan: You post for attention as well. Get the personal issues worked out in PM please, this is a rather important discussion IMHO. If the wrong langauge ends up implemented, WMC will have done a lot of work for naught, and you'll be stuck with a lot of old code in CVS you don't need/use.
As for languages: I can see the argument on whitespace having a meaning to the compiler, and I agree with Goober on that. On the other hand, aside from the whitespace issue, is there another argument against Python?
EDIT: I just thought of something; If people are absolutely demanding braces, I can write a program that goes from braces to tabs for a large block of code in about 8 lines in PHP. C would be a bit longer, but still doable. So there would be the option of using braces, but still Python for the rest of the code. It might be liable to some bugs due to translation, but I doubt that there'd be many.
-
You just have to take into account the various ways to put the brackets: http://en.wikipedia.org/wiki/Indent_style
but it sounds like a plan.
Keep in mind that Python syntax is like:
#Check if (name) is in the current channel/context
def inChannel(name):
userlist = xchat.get_list("users")
if userlist:
for i in userlist:
#Add any reclaimers we missed
if isReclaimerName(i.nick) and not isReclaimer(i.nick):
xchat.command("whois %s" % i.nick)
if xchat.nickcmp(i.nick, name)==0:
return True
else:
dMsg("Unable to load userlist")
return False
(That is from my IRC bot, if anyone is wondering)
It'd be nice if it could preserve linenumbers just in case :nervous: (ie insert a blank line where a bracket was)
-
Interesting. Very HLL.
Although the # comments would surely get on my tits after a while.
I don't think CaptJosh is making a bad point in terms of code readability being a good thing; I think maybe you're thinking at cross purposes here, though.
From what I read here, the primary objection to Python is not to do with forcing readable code (is such a thing even possible), but in forcing a restrictive code structure/formatting that may be counter-intuitive and ultimately irritating (I've never even looked at python myself, so I can't evaluate personally). This is not to do with wishing to be a 'sloppy' coder, but simply to work within the most comfortable personal format (and hence the most efficient/effective one).
To me, readability is not synonymous with a particular format, but more simple conventions; meaningful variables, proper commentary.
EDIT; (etc)
In either case, drawing an analogy with missiles is IMO not valid. Because with a missile, the physical form affects performance; this is not true for programming - any non-trivial code will be able to be written in a large amount of (perfectly readable) different formats, without that difference affecting performance.
(that's entirely aside from the functional aspects of abstraction & decoupling, which I'd expect to be outside the scope of the scripting being discussed here, but are another significant difference from 'physical' engineering)
Oh, and enforced tabulation can sometimes, in my experience, hurt readability anyways, particularly if enforced in a non-intuitive way (try - catch blocks come to mind).
I'm firmly on the fence vis-a-vis python, though, given my never having used it. If it's chosen, I'll adapt. If not....well, I'll adapt to whatever else is used :D
-
All right, calm down you guys. Kazan, while I agree with you, you could have said that with much more tact.
CaptJosh, you're confusing two definitions of the word "form". A missile's "form", i.e. its shape, is part of its function - it has to have certain aerodynamic properties. Because it is integral to the design of the missile, it does not fall under the engineering definition of "form". So your first paragraph is incorrect. As for your second paragraph, that was addressed previously.
EDIT: Yeah, I see aldo also addressed the missile thing. What he said too. :)
-
Yeah, "form" if applied to a v2 missile would likely be whatever is painted on it...
And i agree abnout pythion, consistency is good, but evrey now and then you have somthing that would look better or be more readble in a different format.
-
Exactly. In the missile analogy its form is what colour you've painted it, not the shape of the missile.
I never knew that Python made whitespace demands on you. Just thinking about the amount of problems you can get from people cutting and pasting code is more than enough to scare me off it.
*Looks at all the posts detailing table problems. Imagines how much worse they'd be if whitespace mattered.*
-
Good point. :shaking:
Although if the compiler detects it, why can it not auto-correct it? Or is the nesting solely controlled by ws?
-
Point taken on form vs. form. I guess I'm forever a hardware type. *smiles wryly* As far as coding, the most I can say I've done is HTML and mIRCscript.
I used to code all in one big blob of HTML. For all of about two attempts. It stopped when I realized that even I couldn't find any thing in my own HTML. I started formatting it with gloups of two spaces, initially, then moved on to using tabs, as it was faster, and made sections more distinct. I'm a big fan of W3C compliance in HTML, as well. When w3c standards are used, it's virtually impossible for a page to be readable in one browser but not in another.
That said, I'm going to be learning C++ as soon as I can. I have some things I'd like to do vis-a-vis porting some stuff from one game to another and I need to learn this so I can do that.
Finally, Kazan, I posted because I thought I had something to contribute. If you don't like my contribution, refute or rebut it in a civilized manner. If you can't do that. I suggest you sit on your hands until you can respond to me without the use of ad hominem attacks.
-
Originally posted by aldo_14
Although if the compiler detects it, why can it not auto-correct it? Or is the nesting solely controlled by ws?
Judging from WMC's post it appears so.
if userlist:
for i in userlist:
#Add any reclaimers we missed
if isReclaimerName(i.nick) and not isReclaimer(i.nick):
xchat.command("whois %s" % i.nick)
if xchat.nickcmp(i.nick, name)==0:
return True
else:
dMsg("Unable to load userlist")
return False
The else is associated with the first if. Without the whitespace however it would be associated with the last one. Given that something like that compiler autocorrection would bugger up your code completely. There's no way for the compiler to know which of the 3 if statements the else belongs to once the whitespace is gone.
And for those who didn't get my point about cutting and pasting look what happens when I cut and paste the above code
if userlist:
for i in userlist:
#Add any reclaimers we missed
if isReclaimerName(i.nick) and not isReclaimer(i.nick):
xchat.command("whois %s" % i.nick)
if xchat.nickcmp(i.nick, name)==0:
return True
else:
dMsg("Unable to load userlist")
return False
:eek:
-
As I said, adding brackets to Python would be a matter of 8 or 9 lines of code in PHP, meaning about 50 do to it very reliably in C.
-
Originally posted by karajorma
Judging from WMC's post it appears so.
if userlist:
for i in userlist:
#Add any reclaimers we missed
if isReclaimerName(i.nick) and not isReclaimer(i.nick):
xchat.command("whois %s" % i.nick)
if xchat.nickcmp(i.nick, name)==0:
return True
else:
dMsg("Unable to load userlist")
return False
The else is associated with the first if. Without the whitespace however it would be associated with the last one. Given something like that compiler autocorrection would bugger up your code completely. There's no way for the compiler to know which of the 3 if statements the else belongs to once the whitespace is gone.
[/B]
Sweet jeebus, that's just daft.
Fair enough, I use a similar tabulation for Java, but at least I can change that for readability without buggering up the whole thing six ways from sunrise.
Please tell me the likes of
if hoojiflip
do1
do2
looknobracketingtoendthisandseparate
isn't legal? Ugh.
-
The separate thing would be figgered as part of the loop b/c it's the same tab spacing out.
So, what language would everyone like to try out? 'Lua' and 'Ruby' seem like reasonable suggestions, tho I haven't looked at the API for them. Be nice to get a consensus on this.
Requirements are basically that it must support objects, member functions, and evaluate single-line expressions to a value. Oh and it must be possible to embed it in an app (ie fs2_open).
-
Originally posted by WMCoolmon
Oh and it must be possible to embed it in an app (ie fs2_open).
And fully cross-platform. Meaning: Win32, Win64, Linux/x86, Linux/x86_64, Linux/PPC, OS X/PPC (G4), OS X/PPC (G5), at the minimum.
-
Originally posted by WMCoolmon
The separate thing would be figgered as part of the loop b/c it's the same tab spacing out.
That's what I mean; ugh. What horrible ambiguity.
Originally posted by WMCoolmon
So, what language would everyone like to try out? 'Lua' and 'Ruby' seem like reasonable suggestions, tho I haven't looked at the API for them. Be nice to get a consensus on this.
Requirements are basically that it must support objects, member functions, and evaluate single-line expressions to a value. Oh and it must be possible to embed it in an app (ie fs2_open).
I've heard good things about Lua, but I'll be damned if I can remember where or why I was looking it up. I think maybe for some horrible distributed network testing or something.
-
There is no ambiguity. If its indented consistently with the other lines in the block, its part of the block. Its fully, completely, utterly consistent.
For sanity, never use tabs for spacing, ever. Use Spaces. Never use anything but spaces, no matter what programming language you use. Different editors expand tabs differently. Just don't do it. Its damned bad practice.
All that said, stay with Python. If the only complaint is syntactically signifigant whitespace, I dare say we have a winner. Most languages people can come up with a hell of a lot more important (and valid) things to complain about.
-
Originally posted by mikhael
There is no ambiguity. If its indented consistently with the other lines in the block, its part of the block. Its fully, completely, utterly consistent.
.
Unless you make a mistake in the tabbing.
-
Its rather obvious when you make a mistake in the tabbing, actually.
So obvious that even a non-programmer like me can see the mistake and fix it. Shocking.
-
Different editors? Examples please? And please don't point out vi and emacs. I am so damn tired of that debate. They both suck. Give me mcedit any day. :D *ducks and covers, in preparation for the approaching napalm deluge from lovers of vi and emacs alike*
-
My editor expands tabs to 4 spaces. Some editors expand it to 8. Or 5. In many editors, this is configurable on a per user basis. I like 4, but you might like 3.
Worse, some editors save tabs back as spaces, and some don't.
And yes, this is a case of vi versus emacs versus pico versus joe versus evil versus vile versus Kedit vs Gedit vs Notepad vs Context vs PFE vs... whatever.
-
And for those of you *****ing about Python not having nice clean brackets or whatever:
Python Block Delimited Notation Parsing Explained
Subject: Addition explanation of indentation for the tutorial
From: Michael McLay <@nist.gov>
Date: Mon, 9 Mar 1998 16:42:19 -0500
Message-Id: <[email protected]>
To: [email protected]
Fredrik Lundh writes:
>
> In fact, Python already supports block delimiters:
>
> if foo: #{
> foo1();
> foo2();
> foo3();
> #}
>
> Inspired by Larry Wall, Guido also made sure that the ending delimiter
> could be written in various other ways, such as #end if. Anything to
> empower the newbies, you know. But real Python programmers tend
> to omit both semicolons and curly braces, of course.
This undocumented feature of the language should be explained in the
official distribution of documentation!! How about adding the
following as an Appendix of the Python Tutorial. Also add a footnote
the explanation of indentation at the end of Chapter 3.
Appendix XXX
Python Block Delimited Notation Parsing Explained
Python incorporates a sophisticated parser and advanced notation for
recognizing block delimiters from almost any computer language. The
foreign language notations of C, Ada Pascal, TCL, and Perl will work
in most situations. The Python parser only requires two minor
modifications to the block notation rules of the foreign language's
grammar rules in order to be Python compliant.
The first change is the addition of a rule which states that
indentation of code is not simply a stylistic suggestion like it is in
other languages. It is mandatory in Python. The use of indentation
is considered good coding practice in all these languages and Python
takes this a step further by making it required by the language
grammar. In Python the meaning of a code block which is not properly
indent is not defined. Experienced Python programmers find this rule
to be very helpful in making everyone's code more readable. An added
benefit is that language sensitive editors, such as Xemacs, can assist
in writing code since they are able to automate the indentation of
code blocks.
The second change to to the grammar rules of foreign languages is that
all symbols used to indicate the beginning or end of a block must be
prefixed with the '#' character. If you are a former Pascal or Ada
programmer this will change your usual notation to:
if x: #BEGIN
x = x + 1
#END
If you are more familiar with C and C++ then you will be comfortable
with either:
if x: #{
x = x + 1
#}
or:
if x:
x = x + 1
or even:
if x: x = x + 1
C programmers will be happy to hear that the Python parser will do the
right thing even if curly braces are not included when two trailing
statements are present:
if x:
x = x + 1
y = 3 + x
This last feature will fix a common source of bugs in C, C++, and Java
programs.
Python's parser is also sophisticated enough to recognize mixed
notations, and it will even catch missing beginning or end delimiters
and correct the program for the user. This allows the following to be
recognized as legal Python:
if x: #BEGIN
x = x + 1
#}
or even:
if x: #{
x = x + 1
Now as you can see from this series of examples, Python has advanced
the state of the art of parser technology and code recognition
capabilities well beyond that of the legacy languages. It has done
this in a manner which carefully balances good coding style with the
need for older programmers to feel comfortable with look of the
language syntax.
-
Originally posted by mikhael
Its rather obvious when you make a mistake in the tabbing, actually.
So obvious that even a non-programmer like me can see the mistake and fix it. Shocking.
I don't think so. Not with non-trivial cases or pasted code. Especially not if you use an auto-tabbing IDE. If you have, say, several nested ifs, I think it'd be very annoying to read.
And...it's just nasty to me. Too inexplicit. Like, um, non-bracketed arithmetic is with >1 operators. That's not a criticism on the level of 'dump it, agh agh agh!', though. I just find it very odd.
(Are there really no brackets atall?)
NB: I believe tabs are stored as single characters in ASCII and (I believe) Unicode. So editors could change representation based on user preferences. Apparently some substitute spaces, although AFAIK I've never used one with that.
-
Its really something you get used too, and quickly, Aldo. I'm an idiot and I managed to figure it out, after all.
-
python seems to be withing my ability to grasp. so im for it.
-
extending the sexpression system would be less code, less memory overhead, faster execution, etc
-
Originally posted by mikhael
And for those of you *****ing about Python not having nice clean brackets or whatever:
[snip]
That does nothing to resolve the whitespace issue and in fact makes it worse by sticking a band-aid on it. Suppose a C programmer is using #{ and #} and encounters an indentation problem. He's going to debug his code based on the braces, not the indentations. The result will be even more frustration.
This is not a matter of making people more comfortable with the code. This is a fundamental design flaw of the language itself.
-
Originally posted by Kazan
extending the sexpression system would be less code, less memory overhead, faster execution, etc
Maintenance and readability would be issues, however. In any case, other resource intensive games have used scripting languages and still run well.
Anyhow, lots of people seem to be unhappy about Python. What do you propose as an alternative? It's possible to embed C into Python directly if the indenting is so horrible to you.
-
Originally posted by Goober5000
That does nothing to resolve the whitespace issue and in fact makes it worse by sticking a band-aid on it. Suppose a C programmer is using #{ and #} and encounters an indentation problem. He's going to debug his code based on the braces, not the indentations. The result will be even more frustration.
This is not a matter of making people more comfortable with the code. This is a fundamental design flaw of the language itself.
I see you failed to grok the humor. It was a joke.
Kaz, be silent. You're be Kazan again. Its annoying.
If Python is out, I recommend Perl. Its small, fast, and freeform. Structure is nearly completely unimportant. Its got braces. Its got blocks. Its got all the stuff Python has going for it syntactically. Even a monkey can use it.
-
mikhail: you mean i'm being CORRECT? I'm trying ot make sure code runs fast?
as for "readability" - we can simply extend the FRED SEXP editor and you can do all your SEXP-building in a nice GUI.
piece-of-cake
-
I don't believe you to be correct. After all, Quake3, Freedom Force, Far Cry, Freelancer, and what, a dozen or so other games runsso slowly, because of that scripting layer. Give it a rest, Kaz. Either give it a try, decide its too slow in alpha and rip it back out--its modular, right? if not WTF?--or quite whinging about it. Don't give me this bull**** "I'm Kaz and I'm right!" line. I don't buy it.
The truth is you don't want to do it. Plain and simple. Personally, I think the whole SEXP system is bollocks. You can't extend it to the point that I will think it anything else without turning it into a scripting engine. And you know what? That still won't address all the other scripting that WMCoolman wants to do (HUDs) or I want to do (physics, weapons, ship animation).
-
quake 3 _IS_ a total CPU hog
It _Shouldn't_ be extended to a scripting engine - games shouldn't have scripting engines: PERIOD. They're too much overhead
expression systems are so much faster
-
Give me an expression system that does what I want and isn't a total PITA to code for like SEXPs are. Basic API functions and a syntax that doesn't make me barf. A graphical editor can bite my ass, I'm not writing one when I can implement Python and have it be functional and readable without spending all that time on it.
Pardon me, but I'm in a hurry to go and am tired of people *****ing about my choice of Python and either not offering alternatives or oferring alternatives that involve far more time and effort and trouble for everyone involved.
If I may paraphrase you here, Kaz, please offer constructive criticism to the topic at hand. If you do NOT like my choice of scripting engine, suggest/argue alternatives. If you want to argue about syntax and programmer rights and whether or not Python has a crappy one, take it to another thread.
-
Kazan has spoken. Everyone pack up and go home. He's absolutely right.
-
WMC: I _HAVE_ given you an alternative that is superior in every fashion except for readability - and I have already given a solution for that -
fork the engine if you want to put that POS language in it - it's right next to BASIC on
this (sexpression) is pretty readable to me - it's not that hard to understand postfix notation expressions
( when
( is-event-true-delay
"Start shuttle alpha"
28
)
( add-goal
"Bravo 1"
( ai-waypoints "Bravo1-way" 89 )
)
)
here is a complex one
( when
( >
( distance
"Alpha 2"
"TCS CV-50 Wellington"
)
30000
)
( ship-invisible
"TCS CV-50 Wellington"
"TCS Erikson"
"TCS Storm"
"TCS Nightfire"
"Shuttle Alpha"
"Bravo 1"
"Bravo 2"
"TCS Drake"
"F-96D Arrow"
"F-86C Hellcat V"
"F-66A Thunderbolt VII"
"TCS Aurora"
)
( change-ship-model
"Jump Node Buoy"
"TCS CV-50 Wellington"
)
( change-ship-model
"Jump Node Buoy"
"TCS Erikson"
)
( change-ship-model
"Jump Node Buoy"
"TCS Drake"
)
( change-ship-model
"Jump Node Buoy"
"TCS Storm"
)
( change-ship-model
"Jump Node Buoy"
"TCS Nightfire"
)
( change-ship-model
"Jump Node Buoy"
"TCS Aurora"
)
)
syntax is "( operator arg1 .... argN )"
-
Kazan, while you and I may agree on almost everything in this thread, your brash attitude is seriously impeding your argument. Please make an effort to be polite. :)
I happen to think that the sexp system is one of the most gorgeous things in FS2. It's crudely implemented in a lot of places, of course, but it's very well designed. Theoretically we could "upgrade" the sexp system to full-fledged LISP.
Let's stop thinking negatively and start thinking positively. WMC, what don't you like about the sexp system and how would you like it improved?
I gather that your primary issue with the sexp system is how it's implemented: specifically, all those procedures that define return values and arguments. Refactoring the sexp system into a well-designed class might solve a great many of these problems and make it easier to code for.
Even if we don't redo the implementation, I've been noodling a possible upgrade to the sexp system that would allow arguments and return values in types other than int. Perhaps that would help.
-
Goob, you miss the point of having a scripting layer. Its not about replacing SEXPs, not really.
A scripting layer allows you to keep the SEXP system if you want, but lets everyone who doesn't like it go their own way. With a scripting layer, you would just recode the SEXPs as objects in the scripting layer. You get existing SEXPs for free, and everyone else gets whatever SEXPs they want to add and--get this part--they don't have to recompile to get a new SEXP. They just include the script for it with their campaign, mod, whatever.
On top of that, a scripting layer has benefits in other places: modular physics; trading model; docking; ship transformation; animation; camera scripting; Bob's materials system.
All one has to do is look at pretty much any modern game to see the possiblities. All the Force Powers in Jedi Outcast and Jedi Academy, all the weapons, all the AI behaviors, etc, are coded not in the engine, but in the scripting layer.
-
But can you add the scripting layer without creating unacceptable CPU load in game?
-
No no, I understand that point, mikhael. I know about games implementing stuff through scripts. I want to make sexps the scripting layer. :D
In fact I wonder every once in a while about moving the AI code into scripts built through sexps, since AI improvements are the number one request of people new to the SCP. This way they can design their own AI code. :D
-
Originally posted by CaptJosh
But can you add the scripting layer without creating unacceptable CPU load in game?
not really
-
Ok. If that's true, Kazan. Why? What are the technical limitations?
-
It's a scripting engine, there is a lot of overhead involved in interpreting script - it's just the nature of text parsing
-
Well, I can agree with you on that based on experience. Just opening a large document in OpenOffice takes a noticeable amount of time.
Would I be correct in assuming that unlike the mission script files in Starfleet Command Orion Pirates, it's not something that can be read and dealt with during mission loadup?
-
it theorectically can be compiled into "Bytecode" - but that's just like java.. and it doesn't speed it up too greatly
mission files and other text files with FS2 get parsed into a binary structure and then worked with once it's binarty
-
There's only INITIAL overhead, Kazan. Python compiles only if the module is not compiled, or the script timestamp is more recent than the bytecode time stamp. Parsing only happens the FIRST time or on changes and its a trivial delay anyway.
Goober: how are you going to take SEXPs and use them to manipulate the HUD without ending up writing your own scripting language? You're working bass-ackwards there.
-
mikhael: make sexp-functions for manipulating the hud - all the basic arithmetic functions are already there
-
Its still backwards and reinventing the wheel, just to keep from stepping on someone's pride. You're just going to layer on more and more crap, until you've built your own lisp for no real purpose.
-
Once the tables are parsed, it doesn't have to be interpreted. It'll all be stored as bytecode.
I said this twice on AIM, and I think I've said that at least once in this thread. If I haven't then the nature of the functions I've implemented should at least imply it.
But re SEXPs
As has been pointed out, the orderof the SEXPs is counter-intuitive. It's also rather inefficient; remember how it's not practical to implement a function that both does something and returns a value.
Let me rewrite this in Python:
( when
( >
( distance
"Alpha 2"
"TCS CV-50 Wellington"
)
30000
)
if shp.distance("Alpha 2", "TCS CV-50 Wellington") > 3000:
That's all on one line, though. So to be fair let's put 'em both on the same line:
( when ( > ( distance "Alpha 2" "TCS CV-50 Wellington" ) 30000 )
That's looking particularly ugly to me.
But what happens when you try to use them in an expression like so (This would be the Python):
$Weapon damage: weapon.damage() * target.shield_strength() + weapon.damage() * 0.5
Now I run into a problem. I don't know how to write that in SEXPs. I guess:
$Weapon damage: (+ (* weapon-damage target-shield-strength) (* weapon-damage 0.5))
That's awful. That's three arithmetic calculations and it already it requires specialized knowledge of programming.
Not to mention I used floats, which'd require the overhaul of the SEXP system.
-
Umm. Is it just me or are sexps totally irrelevant to this thread? If you want flexibility through sexps you've still got to write the code for them. Python (or any other scripting language) would let you extend sexps in a more modular fashion.
BTW: If people would rather adopt Perl over Python (I think Python is fine) I'd recommend Ruby instead. It is loosely inspired by Perl, has nicer syntax and can be easily extended using C.
It _Shouldn't_ be extended to a scripting engine - games shouldn't have scripting engines: PERIOD. They're too much overhead
So I guess the developers of World of Warcraft, Far Cry, Homeworld 2, etc. are all crazy then? It's a wonder they get paid to make that junk eh?
-
Bless you, Kamikaze. That's exactly the point I was trying to bring across.
-
OK, I've been looking at Lua.
1: It sounds like its faster and smaller than Python
2: It is as extendable
3: It is as portable, there is even a PS2-port project apparently
4: It can be compiled into bytecode
5: It could attract other modders who've used Lua in newer games
6: It doesn't seem to be as 'constraining' (ie it uses ends instead of whitespace apparently)
----------------------------------------------------------------------------
-- Execute the file if there is no "file error".
-- If an error is found, and it is not a "file error", Lua 'error'
-- is called and this function does not return
----------------------------------------------------------------------------
function doif (filename)
if not filename then return end -- no file
local f, err = _open(filename)
if not f then return nil, err end -- no file (or unreadable file)
f:close()
return doscript (filename)
end
-
Originally posted by WMCoolmon
As has been pointed out, the orderof the SEXPs is counter-intuitive. It's also rather inefficient; remember how it's not practical to implement a function that both does something and returns a value.
So that could be one of the things we change.That's awful. That's three arithmetic calculations and it already it requires specialized knowledge of programming.
It's exactly the same as the other one, only with postfix instead of infix. You still need three arithmetic calculations:weapon.damage() * target.shield_strength() + weapon.damage() * 0.5is equivalent to((weapon.damage() * target.shield_strength()) + (weapon.damage() * 0.5))is equivalent to(+ (* weapon-damage target-shield-strength) (* weapon-damage 0.5))See? BTW, have you ever programmed in LISP? A sexp node is exactly equivalent to a LISP operator.
The advantage of keeping the sexp system is that we can make a GUI script editor by simply copying the sexp tree stuff that's in FRED. Very straightforward, and it allows modders who don't know how to "program" to still write scripts.
The sexp system, as it currently stands, is already a scripting language. To add hud or physics script commands, all you need to do is add another sexp operator. I've already implemented simple loops with when-argument.
EDIT: Lua looks fine; if you want to implement Lua as a scripting language then more power to you. But I think extending the sexp system would be better in the long run.
-
Why do you insist on going the most restrictive route? For most people LISP like structures are counterintuitive and illegible. Moreover, by extending SEXPs instead of using a scripting layer, you cater to the Fredder at the expense of basically anyone else who can program. Take a look at the other route though: by implementing SEXPs as scripted objects, you allow the Fredder to continue using his knowledge without loss, but you also allow a more traditional programmer the power to do what he wants to do.
I don't know about you, but I want the one that offers more flexibility.
-
UPDATE!!!
I figured I'd implement a few functions for people to play around with.
There are three modules; you gain access to them by use of "import module". Then you can call the functions with "module.function()"
fs2 - general
getState(depth) - Gets the current game state string; depth is for example if you have the options screen going while in a game too.
getViewerMode() - gets the viewer mode (in cockpit, outside cockpit), this is an integer b/c the way FS2 does it is it sets each bit depending on viewer mode. If its 0 then it means in-cockpit basically :p
gr - 2D graphics
setColor(red, green, blue, alpha) - Sets the current drawing color
drawLine(x1, y1, x2, y2) - draws a line from x1, y1 to x2, y2 in the current color
drawString(x, y, string) - writes the string to the specified position
drawImage(x, y, imagefilename) - draws the image at the specifed position
shp - ships
getClass(shipname) - Gets the class (string) of the specified ship
getTarget(shipname) - Gets the target (ships only for now) of the specified ship
getShields(shipname) - Gets the shield strength of the specified ship
getHull(shipname) - Gets the hull strength of the specified ship
getPlayer() - Gets the player ship name
Sample table (python.tbl):
;;You can have more than one $Python, they are run sequentially
$Python: {
import gr
import fs2
import shp
gr.drawImage(1,1,"crim00")
}
That will import all the modules and draw the medical ship concept art in the corner of _every_ FS2 screen.
If, for example, you wanted to draw the concept art in just the tech room:
$Python: {
import gr
import fs2
import shp
if fs2.getState() == "GS_STATE_TECH_MENU":
gr.drawImage(1,1,"crim00")
}
Note that this is just a test, ifI were to do it properly I'd make a 'ship' class that you could play with. But I'm a bit unclear on using classes like that.
All this stuff is surprisingly reliable for something I coded, you should be able to screw stuff up without crashing FS2. Oh, and it won't tell you about parse errors yet, so if your code isn't working double-check it for them.
EXE: http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip
-
EDIT: Disregard the old post, didn't see the nexst page.
As far as any scripting langauge is concerned, I think forcing everyone with SEXPS might scare away some programmers. If there was a good scripting language for table stuff, and/or animations and the like, it would be very easy for mods to implement a lot of changes themselves, or get freelance programmers to do it. It would keep CVS commits for specific project features down, which in turn lowers the amount of bugs, and also lower the workload of current SCP coders.
Just look at the other internal, and see how many of those features are implementable via a scripting system instead of more and mroe SEXPS.
-
i have to agree with mik there. ive never been good with the sexp system. programming by dropdown menu is hellishly ineffietient and time consuming. part of the reason i never bothered learning fred. i sorta liked the way quake c worked, you had to compile it externally from the game engine to a binary file and it was fairly object oriented. it had the same syntax as c and was fairly simple to work with. i wonder if something like that would work. instead of scripts, lets use simple programming followed by a compile. the goal is simple, extend gameplay related code to a format which lesser programmers can utilize.
-
{}s will just make my life harder. Notice how I'm using them to delineate the Python code chunks? Throwing a "}" anywhere between the actual ones will make the parser think that the Python is over and stop parsing the rest of the table. I didn't code it to be smart :p
-
Originally posted by WMCoolmon
{}s will just make my life harder. Notice how I'm using them to delineate the Python code chunks? Throwing a "}" anywhere between the actual ones will make the parser think that the Python is over and stop parsing the rest of the table. I didn't code it to be smart :p
That can be fixed using a few lines, I'd wager.
if($inputChar=="{")
{
$DepthOfIndent++;
}
if($inputChar=="}")
{
$DepthOfIndent--;
}
if($DepthOfIndent<1)
{
EndPython();
}
EDIT: Fixed intendation. (Yes, I use BSD style intendations. K&R is quite unclear IMHO.)
EDIT2: While I'm at it:
if($inputChar!="}"&&$inputChar!="{")
{
$x=0;
while($x<$DepthOfIndent)
{
$inputLine="TabCharacter".$inputLine;
$x++;
}
}
Now, this is PHP, but is there any reason why we cannot use Python, but extend it with running the above code before parsing it?
-
Probly not.
Also, parabolas are fun. :D
$Python: {
import gr
import fs2
import shp
i = 0
mult = 0.3
max_size = 100
x_start = 200
while i < max_size:
x1 = i
y1 = mult*i*i
x2 = i+1
y2 = mult*x2*x2
gr.drawLine(x_start + x1,y1,x_start + x2,y2)
i=i+1
}
-
so let me het this straigt, all code will be written in python.tbl and the modules would be internal?
-
If we do go for a scripting language, would people accept Python with the curly braces mod?
NOTE: I know nothing of scripting langauges, I am limited to BASIC, and C style stuff. I greatly prefer the latter (off course). The only thing I do hope is that some scripting language gets implemented at one point. Consensus on which language is a first point there, and since WMC has quite abit of Python already implemented, it seems logical to stay there.
Note that the above code only adds the option of curly braces. If you already insert tabs, they will remain unchanged. I could write something that removes the old tabbing quickly, but that is not a good move, since Python programmers would dislike that. A "DontUseIndent" flag could be made easily, but that is a design decision up to the coders.
BTW: The above code was PHP, does that even work in C? (Assuming you change the inputChar and inputLine things in a way you can use it?)
-
Originally posted by Nuke
so let me het this straigt, all code will be written in python.tbl and the modules would be internal?
Python.tbl is something I have cooked up for now so people/me can screw around with it without worrying about the HUD system. Its easier to get to the pilot screen than start a mission.
Right now the implementation is hackish galore. Python is executed every time the backbuffer is flipped, as the easiest way to get it to execute everywhere without flickering was to throw it into the flip()ing function. The stuff in Python.tbl is just loaded into an array and then executed.
So the final version I think would be more likely to use Python in a somewhat less global context. A HUD Gauge would have its own little set of Python code that would be executed every time its drawn, or every time someone clicks on it.
BUt for the most part at least, yes, modules will be internal and written in C/++.
Like I said the reason I did it this way is because I'm still learning. I don't really get how to return an actual ship object from functions, yet. And for now, you can sort of make a HUD by checking the game state and viewer mode and only executing funtions if both are set properly.
@kasperl: Sort of, not really. The general idea is spot on, but the code will probably end up being fairly different.
-
Kamikazi: and all those games are CPU-whores well beyond what they should be.
WMC: the Postfix notation SEXP trees are no less readable than the Python.. infact I'd say the Postfix notation SEXP trees are _MORE_ readable due to the use of () in the operator convention.
-
Guess I should chime it here as well. My thoughts...
I agree with Goober about using SEXPs instead of some new scripting language. I also agree with others that the SEXP system is a bit insane, but it's something that can be fixed. An easy to use GUI SEXP editor would do a lot to reduce the learning curve and allow non-programmers to make SEXP snippets relatively easily. I'm not volunteering for that however, I've got enough to work on as it is. The new interface code I'm working on (LUI) will take advantage of the SEXP code (with some new evaluation functions) to do it's work. It won't be heavily scripted like the HUD might be but LUI isn't going to be suitable for the lab for hud anyway and is not meant to replace WMC's gui stuff, only the current interface gui.
Python is a memory whore. I'm not sure how much memory other languages require but memory usage is our main problem and how many people want all of this new crap and then turn around and ***** about memory usage is just sad to me. A lot of work has been done to reduce memory usage and though the memory footprint has increased in FS2_Open over retail, memory usage has actually decreased, alot. The high memory usage comes from all of the art that get's used and now here we are wanting to increase the base memory usage even more. No optimization in the world is going to fix this for everyone and the core code isn't going to get much better than it is now and will in fact get worse as new functionality gets introduced. If something that increases memory usage and introduces new slowdowns get's introduced I won't publicly object. But I am going to make a note of everyone that insisted on that particular feature though and any complaint from them about memory usage or speed is going to be ignored from me. As the person who has fixed nearly every major memory leak and memory bug in the past 2 years or so, that should mean something to you. I don't want that to seem like a threat or anything but I didn't come to this project to be a Little Dutch Boy with a finger always plugging the leaks in some dam.
I'm not against a new scripting language getting used, however, regardless of what gets used there is a price to pay whether it be higher memory usage, a learning curve, or lack of some functionality. Decide what's closer to what you want and need and whether it can be expanded to fill the rest of that need. There is no win-win here.
-
freespace memory usage has never bothered me. im dirt poor and if i can afford a gig of ram then anyone can :D.
now that people have brought up the ui it gets me wondering, why are there two being implemented? i like the lab and all and its very useful for mod testing, but why is it and the other replacement ui not one in the same? not to complain, id like the idea of both the lab and the replacemnt interface. im just curious why theres two systems that do pretty much the same thing. is one just an interim solution while a more advanced system is being developed?
that may or may not be the issue with the sexp and scripting systems, im no programmer and i dont really know the difference between an expression system and a scripting system. so long as it boosts modability and is fairly easy to program il be happy with it.
-
Problem is, (as CP and I were discussing in the MediaVP thread) a gig of ram is only barely adequate now. The memory issues are almost all art-related currently, but Taylor's right. A cost-benefit analysis HAS to be done somewhere. I will say that this whole python debate seems to have more to do with an ego contest than actual merits and disadvantages of the language itself though, which is going to ultimately impede any efforts to standardize the interface. Taylor's comments do a good job of talking about the costs from a high level (though I'll admit he is a little close to the subject to be fully objective) and I hope he is heeded. Ultimately though, my thoughts on this, for the entire team, are to pick something to be used everywhere scripting is implimented and stick with it, as I don't want to expect people to have to use multiple implimentations for the same game.
As for my personal preference, I really think one of the things that made FS shine is that it didn't try to do too much. There's too much grandiose talk of capship-flying and strategic gameplay right now as it is, and opening up the engine for something it was never meant to do is a mistake IMHO. Scripting the HUD, or at least making it fully customizable, is a good thing, yes. But please don't try taking that too far.
-
I've refrained from saying too much since I don't know python that well but the more I'm reading about it the more I'm starting to come down on the side of a SEXP based scripting system.
Goober has already suggested that as part of implementing SEXP scripting we'd see an overhaul of the way SEXPs work allowing us to use floats and possibly other structures in SEXPs (Like arrays or collection classes). We's also get SEXPs with return values and a whole bunch of other useful stuff. That's a benifit that is instantanious to all FREDders and therefore the community.
On the other hand as far as I can see using Python benifits Mikhael since he doesn't have to learn a new scripting language and nobody else. Taylor says it's a memory whore. Kazan says it's slow. I'm just not seeing the advantage.
Can someone please explain what are the flaws of using SEXPs as the scripting language cause to be frank I've not really seen anyone say why we shouldn't aside from WMCs comments about the lack of return values and ability to use floats (something Goober has already said he wants to put in anyway).
-
Oi, this is what I get for ignoring engineering titled threads.
Python has advantages, mostly in support and readability. It's alot easier to learn python than it is to learn SEXP's, and the skills are portable.
It DOES have memory issues.
The thing with this, is, if you manage to figure out how to hook python into the engine, it (ideally) should be trivial to hook ANY off the shelf scripting language into the engine.
It's been done to commercial engines (TGE had python integration, and once it was in, a number of other home-baked and off the shelf scripting languages, someone even built javascript into it). Users of the engine now have a choice of scripting languages available to them, sometimes it is even a concurrent choice. That's not a bad thing.
So any design work, at the "guts" level should be resuable. It doesn't hurt to investigate options, but I THINK the memory usage issue should be enough of a reason not to call python the "official" scripting language of the SCP. Someone mentioned a cost benefit analysis, more data seems in order.
It would be nice to have something that a new to fs2 scripter could pick up and start using. Lua might work, Python is often suggested (outside FS2, see above), very few others seem mature enough development wise to take up the task.
Finally, one more personal attack and I "aggressively moderate", getting really damned tired of it.
-
WMC infact linked me to a site showing python is 50x slower than C++ code
now an extended sexp system has the following advantages:
- Takes advantage of an existing wealth of code and integration with the engine that already exists
- Being an expression-based system it is faster than a scripting-system and has less memory usage
- easy to add new, or customized, functionality with the high-performance parts inside machine-compiled and optimized code
- Nobody has to learn a new language*
*unless they want to write raw sexps - which isn't hard
Disadvantages
- Ease of use requires a GUI sexp editor**
** shouldn't be that difficult to implement in wxWidgets
-
Might I suggest someone sets out a list of aims and objectives (functionality level, customisability, use, and soforth) for this change, so we can better evaluate SEXP vs language?
I'm assuming you've already got a similar discussion in the scp internal, of course, so it'd be a cut & paste job.
-
Given the following operators
vector
takes three arguments, floating point - constructs a vector
syntax: ( vector x y z ), x y z being numerics or operators which return scalar numerics
3dcolor
takes four arguments, all floating point - constructs an RGBA color
syntax: ( 3dcolor R G B A )
draw-color-line takes three arguments -
One color argument, two vector arguments
Syntax: ( draw-color-line c v1 v2 )
now let's use these in an expression
( draw-color-line
( 3dcolor 1.0 0.0 0.0 1.0 )
( vector 10.0 10.0 1.0 )
( vector 20.0 20.0 1.0 )
)
would draw a Red (zero transparecy) line from the coordinates (10.0, 10.0, 1.0) to (20.0, 20.0, 1.0)
we could also express this as a single-line
( draw-color-line ( 3dcolor 1.0 0.0 0.0 1.0 ) ( vector 10.0 10.0 1.0 ) ( vector 20.0 20.0 1.0 ) )
-
Originally posted by Nuke
freespace memory usage has never bothered me. im dirt poor and if i can afford a gig of ram then anyone can :D.
Yes but we have multi platform issues to think about. FS2_Open has slightly different memory requirements on the basic platforms since you have to take into account platform specific libs and ui stuff and input stuff and etc...
Also think about the fact that Python will likely use different amounts of memory on Linux than it might on Windows. You can't assume that any memory stats you get under Windows are going to be the same on Linux and OS X. A gig of ram my be enough for you but someone on OS X may have to get 2 gig. Same for Linux.
Originally posted by Nuke
now that people have brought up the ui it gets me wondering, why are there two being implemented? i like the lab and all and its very useful for mod testing, but why is it and the other replacement ui not one in the same? not to complain, id like the idea of both the lab and the replacemnt interface. im just curious why theres two systems that do pretty much the same thing. is one just an interim solution while a more advanced system is being developed?
I don't consider the lab ui code to be suitable for the rest of the interface (but I am biased). That's not to say that it can't do it, just that something written specifically for the FS2 interface ui would be better. It would be nice if the two could be merged after I get done but that's something for WMC and myself to work out at a later date. Of course what I'm working on isn't suited to the lab at all and deffinitely not for anything on the hud. WMC's ui is great for that stuff and even possible future things that work in-mission such as billboards and various other things.
Having an interim solution would only make things worse. It's wasted work since going from what we have now to what I'm working on is considerably easier than going from the lab ui code to what I'm working on. I'm trying not the reinvent the wheel here. As much code as possible will be reused and when I'm done the default interface will look and work exactly like it does now. The difference will come when you get to do just about anything you want with it as far as customization goes.
Originally posted by StratComm
Taylor's comments do a good job of talking about the costs from a high level (though I'll admit he is a little close to the subject to be fully objective) and I hope he is heeded.
Very true, I'm not all that objective on this. I have my point of view just like everyone else does. I would much prefer to extend the SEXP system to do what's needed rather than introduce something new. But I'm also coming from the "oh great, something new to worry about when there is a problem" side of things. Everyone will probably agree that I'm the primary bug fixer so you can probably understand my concern there. I'm not really a part of the modding, mission designing, model/art producing side of the community just so I can come from that other side. That way I'm not obligated to come down on anyone's side on new features, just to keep it all working.
I think the basic developer thoughts (largely glorified for this posting) from the python discussion go something like this:
WMCoolmon: "Python!"
Bobboau: "More bugs!!" (sorry Bobboau, couldn't resist ;))
Goober5000: "Why won't SEXP work?"
Kazan: "HELL NO!!!"
Taylor: "****. Now I need another gig of ram. :sigh:"
:)
-
Originally posted by aldo_14
I'm assuming you've already got a similar discussion in the scp internal, of course, so it'd be a cut & paste job.
Actually there isn't anything in there on this. It's only fair to have a technical discussion about this where other people can comment as this isn't just an issue about the coding in C.
-
WMC infact linked me to a site showing python is 50x slower than C++ code
Of course it's slower, it's not compiled ahead of time, that's going to be true of any pure scripting system ;)
TGE Script gets around this (partially) by compiling the scripts the first time, then running the compiled scripts on subsequent runs.
-
[color=66ff00]Given the realtime nature of games would a pre-compiled language not be a requirement nevermind an asset?
[/color]
-
I'm sure someone will correct me if I'm wrong, but if I'm not mistaken, it's not the language that needs to be compiled, but rather the scripts written with it.
-
[color=66ff00]You've misinterpreted the meaning.
Scripts are not written with a language, they're written in a language or more to the point, in a language the compiler understands and can convert into machine code.
[/color]
-
Given the realtime nature of games would a pre-compiled language not be a requirement nevermind an asset?
Not for an actively developing game, and not for a game where you have non-coders contributing content, not to mention the ability to tweak and test instantly.
In my opinion, it's not an asset, it's a liability. Hinders development and content creation.
Imagine having to wait for a coder to compile a table (equivalent).
What you give up in execution speed, you make up for in flexibility.
But that's just my opinion. Monolith's engine (what used to be lithtech) had everything execute in C++, including game logic and levels.
-
A lot of the new posts say the same things about sexps's vs. scripting language. Let me stress again that sexps and a scripting language are not mutually exclusive at all. The scripting language can be used to create more extensions to the sexp system.
Python has been used in many intensive games successfully. A couple of examples are Earth and Beyond, Battlefield 2 and EvE Online (EvE uses stackless python). Other games have successfully used lua and other languages. It is definitely possible to use python or lua in FS2 without being too much of a burden on computers.
-
simply hooking python in will have overhead that writing new sexp functions and not using them will not
-
No one is saying that they are mutually exclusive. But a massive overhaul of the SEXP system automatically adds new SEXPs and allows you to create more.
Doing this in python simply gives you the latter. Why not get something for free?
I've yet to hear anyone state any disadvantages of doing this by simply expanding the pre-existing SEXP system.
-
karajorma: it's not in the language some people prefer
-
I've actually yet to see any real advantage of reimplementing LISP from a half-arsed beginning (IE SEXP). I don't care if you use Python or not. Use Lua. Use Perl. Use Python. Use Vbscript. Use PHP. Use Java. Use ECMAscript. Use Rexx.
In short, use whatever gets you the most flexibility, with the least reinvention of the wheel. That points to a scripting layer to me. And Inqui's absolutely right: any scripting layer properly implemented would be modular enough to take any engine.
Originally posted by Kazan
karajorma: it's not in the language some people prefer
Ah, you mean like SEXPs? That seems to be your biggest aregument against scripting. You prefer SEXPs. It cuts both ways.
-
mikhael: i prefer sexps for concrete computational reasons - performance is superior and overhead less than using a full scripting language
-
Kazan stated earlier that parsing text takes a lot of CPU cycles. I've seen that just in opening a large text document or a spreadsheet that I made from a highly expanded modded shiplist in Starfleet Command Orion Pirates.
FS2 Open is already preatty tough on system overhead, and you're talking about adding something that would just make it worse, mikhael. Not everyone has an uber-system. Personally, I'm running a Duron 1.6 GHz with half a gig of PC3200 DDR and an 8X AGP 128 MB geForce FX5200. Inferno already jitters pretty damn badly in some spots for me, and you want to add something that would make such an issue worse just by being there.
Contrary to your assertion, it's not a matter of the developers liking SEXPs more than a scripting language. It's a matter of at least some of the SCP developers actually taking into account that there are people like me without top-end systems.
-
/sigh
a spreadsheet/document in MS Word is not a good example
-
Originally posted by mikhael
I've actually yet to see any real advantage of reimplementing LISP from a half-arsed beginning (IE SEXP). I don't care if you use Python or not. Use Lua. Use Perl. Use Python. Use Vbscript. Use PHP. Use Java. Use ECMAscript. Use Rexx.
And I've already posted an advantage. Any changes to the SEXP system are instantly useable by FREDders. It's a 2 for 1 deal.
And you still haven't posted a single disadvantage.
-
I've said my bit. Do it or don't.
-
Originally posted by Kazan
/sigh
a spreadsheet/document in MS Word is not a good example
You think I use that trash? OpenOffice, man. All the way. And I'm talking text files over a megabyte in size, which is unusually large for the average spreadsheet or text doc.
And would you kindly quit complaining when someone is backing you up? Take it in the spirit in which it is intended. I swear, you can't help some people... :rolleyes:
-
Any office suite is still not a good computation example of what i'm talking about.
An argument "backing me up" that is totally off base is more damage than the opposition bro
-
Originally posted by CaptJosh
You think I use that trash? OpenOffice, man. All the way. And I'm talking text files over a megabyte in size, which is unusually large for the average spreadsheet or text doc.
And would you kindly quit complaining when someone is backing you up? Take it in the spirit in which it is intended. I swear, you can't help some people... :rolleyes: [/B]
You're being quite rude to Kazan. What you posted was off topic and misinformed. This is not about word processing but about compiled code vs. interpreted code vs. bytecode.
Originally posted by karajorma
And you still haven't posted a single disadvantage.
I consider the disadvantage Kazan posted (needs a GUI to be effective) to be a major issue. A GUI can make the process unwieldly and inefficient. A scripting system would have the best of both worlds, coders could make script extensions and FREDers can keep doing their own thing. The scripters could give the FREDers more to work with too.
A scripting language also has more features "out of the box" that would need to be coded into a revamped sexp system (as mik said, it's like reimplementing LISP). Lua would give coders more flexibility than sexps because of its language features.
-
it doesn't _need_ a gui to be efficient, that's just an easy-of-use tool - sexp structure is pretty simple to understand as you've seen me write sexps off the top of my head in this thread and my signature
there is no scripting language that overcomes the disadvantages it has when it comes to games - scripting languages are for non-realtime ops, and for web page serving, etc - not for realtime high performance applications.
-
:sigh:
Define me a new function with SEXPs.
Define me a new class with SEXPs
Do operations with floats with SEXPs
Show me a function that returns a value without messing up the conditional its a part of in SEXPs
Show me a way to implement functions without having to edit five separate values in different places in SEXPs
Show me the extensive modules in SEXPs that would let me do network operations
Show me the ability to expand the SEXP system via modules
Show me how I can multithread with SEXPs
There is a reason that Python is slower than the SEXP system. It provides a lot of things that the SEXP system doesn't.
In addition, I hear still here people talking like Python isn't being compiled into bytecode and then run. Python is being compiled into bytecode at program start. This bytecode is evaluated every frame. There is no parsing occuring every time Python is used. Past the first time python.tbl is parsed, the file is never opened again.
Kazan brought up a link I posted with Python: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=python&lang2=gcc&sort=fullcpu
Although he obviously didn't read it or else he would be pointing out the 234x difference. (Apparently Python doesn't like extreme numbers of recursive functions). Which is something which shouldn't be happening.
Oh, and the tests are grossly inaccurate because there's no 'fully-featured SEXP' option. Python and SEXPs are both coded in C; I'm comparing raw C to Python in that example. It's not iterating through switch statements or cycling through nodes to figure out what the instructions are like SEXPs would be.
So to say that because SEXPs are coded in C and are therefore as fast as C is a gross fallacy.
AFAIK the benchmarks were run taking compile time into account. And, well, see above bolded text.
Also, python isn't intended to be a replacement for the SEXP system. I see it as being a step more than that; a way to perform lower-level operations on an individual mission or mod basis.
And just to reiterate reasons for dislike of the SEXP system, the postfix operator system is just another hurdle to overcome when learning to write with it. A GUI editor is unreasonable (IMHO) because it means that you're spending a lot of time sorting through menus even if you already know what functions you want to use. It has a number of problems and limitations, not the least of which is that it's frustrating to code functions for, no matter how simple.
Before it can be Python or Lua's equal, those have to be fixed. Then, IMHO, we can honestly argue processor time.
And finally, I'm not convinced that SEXPs are going to be so much incredibly faster than Python or Lua for any reason except their simplicity. Python is, after all, coded in C as well and was designed as a scripting language from the start, AFAIK, so it stands to reason it'd have a decent parser (compared to SEXPs which were implemented only to provide mission scripting).
Edit: Oh, and I have no confidence in this massive SEXP overhaul happening in the same amount of time...hell, Python's already in and has more abilities than the SEXP system, so go figure.
But I already asked about using SEXPs for the HUD system before, as I couldn't get a full expression system working and hadn't thought up using another scripting system, and that never happened. The overhaul that's being proposed is pretty major, and would take awhile to do & test & work all the bugs out of. There are over 100 SEXPs, each would have to be ported to the new system, for one...
-
processor time is more important from the get go - we have four developers opposing and one in favor
i'd say "it's a no brainer" it's dead
-
I don't care what developers think. I'm more interested in what modders think.
Developers can just code features into the game source directly.
That's not to say I'm totally ignoring you guys. At least I hope not as I wrote a whole post responding to what you and Goober are talking about. I haven't contested that SEXPs are faster than Python because they probably are. I have absolutely no proof, I'm just making an educated guess as are you.
Mostly I think that a scripting language is better than trying to expand the SEXPs to duplicate the abilities of that scripting language.
Lua has a PS2 port going on. Now, it is possible that the people working on that are totally misguided and will find that the PS2 is totally unable to run a scripting language due to the "high" memory and CPU requirements. But I think they'd figure out whether or not it's feasible before embarking on such a project.
Why am I sticking with Python. Mostly because the alternative, upgrade the SEXP system to be as good as Python, is just reinventing the wheel. Python's already in. I can throw hooks wherever I like, granted in a somewhat hackish manner, but it's still there. I could implement vector and angle and matrix classes and let people replace the physics calculations with a Python script that would do the job.
Plus Python is built to be compiled on-the-fly; you could edit the physics calculations on the fly rather than recompiling them with VC++ every time.
I'm not familiar with Lua and nobody seems to care for it who doesn't want Python (even though it is used in a number of well-known games) so I'm not looking into it, although I did breeze through the documentation and it seems an attractive alternative.
-
I guess I've failed to draw the comparison I was thinking of.
If a word processor, which is designed to open a text file and parse the text and formatting merely to display on screen, has a noticeable delay in loading a file that is as small as 1.5 MB, then think about how much more CPU work a script, or, more likely, a set of scripts might take? Scripts which must be parsed not merely to display formatted text on screen, but to execute some sort command set, recieve return from the execution, and move on through the script or scripts.
On second thought, perhaps a better analogy would be the difference between loading a copy of mIRC with a few aliases vs starting up a copy of mIRC that has a heavy set of scripts to load on startup, plus scripts that execute a lot of commands in the background while the program is running, and then going on to one of those HUGE mp3 channels on Undernet with all the warp scroll, having a huge back buffer for chat windows, and global chat logging on. Pretty soon, you start to notice things dragging.
-
Originally posted by Kazan
processor time is more important from the get go
I'd argue that the programmer's time is more important than the processor's. I also trust the judgement of the professional game developers (such as Inquisitor, who seems sympathetic to WMC's cause) who use scripting languages on a daily basis to develop complex, real-time games.
Originally posted by CaptJosh
I guess I've failed to draw the comparison I was thinking of.
If a word processor, which is designed to open a text file and parse the text and formatting merely to display on screen, has a noticeable delay in loading a file that is as small as 1.5 MB, then think about how much more CPU work a script, or, more likely, a set of scripts might take? Scripts which must be parsed not merely to display formatted text on screen, but to execute some sort command set, recieve return from the execution, and move on through the script or scripts. [/B]
Perhaps it's best for you to start reading others' posts. Read this:
Originally posted by WMCoolmon
Python is being compiled into bytecode at program start. This bytecode is evaluated every frame. There is no parsing occuring every time Python is used. Past the first time python.tbl is parsed, the file is never opened again.
-
I did read that. I was going back and trying to correct a misperception about what I was originally trying to say in an earlier post.
Just tack this on the end of what I last posted:
However, bytecode compilation on program start would seem to change things. How much it would change them, I'm not qualified to say.
-
I don't think anything you guys say is going to change my mind, since Python is wholly optional (It's optional to compile it in, it's optional to use scripts at all, either will result in basically nil performance difference).
I think there's immeasurable gain to be had right away from implementing a scripting system, far beyond what upgrading the SEXP system would do. The developers of the Unreal, Homeworld 2, Battlefield 2, Tribes 2/Torque game engines and many others agree. I think this gain is worth the increased processor power and memory usage. I think that, in the long term, upgrading the SEXP system to have all the features of one of these scripting language would be A) a waste of time since it's already possible via said scripting languages, and B) would cause an increase in processor and memory usage similar to what using a scripting language would.
I don't want to waste my time arguing about this anymore.
http://www.hard-light.net/forums/index.php/topic,35914.msg744514.html#msg744514
-
*Bump*
Status report...
I've been looking into getting Lua working in fs2_open and have it at roughly the same level of completion as Python.
In addition I've found this nifty little thing called LuaJIT (http://luajit.luaforge.net/), which has its counterpart in Python in the psyco (http://psyco.sourceforge.net/) project.
What these do is compile Python and Lua functions as machine code, as best possible. What this means is that it's approaching the level of being as fast as C, and/or SEXPs. I've got the LuaJIT library as part of my codebase right now, and working (except for the lua IO library), much like the OGG library.
The downside: They only work on x86. I'm not sure what'll happen on 64-bit or Macintosh processors.
-
Here's the C code for creating a ship, providing a ship object to python, and setting the speed of that ship object.
typedef struct lua_ship
{
ship *shipp;
} lua_ship;
static int lua_msn_newShip(lua_State *L)
{
char *ship_name = NULL;
char *class_name = NULL;
vec3d pos;
angles ang = {0,0,0};
if(!script_parse_args(L, "ssfff|fff", &ship_name, &class_name, &pos.xyz.x, &pos.xyz.y, &pos.xyz.z,
&ang.p, &ang.b, &ang.h))
return 0;
//New matrix
matrix ori = IDENTITY_MATRIX;
vm_angles_2_matrix(&ori, &ang);
//Find the class index
int si_idx = ship_info_lookup(class_name);
if(si_idx < 0)
{
//couldn't find it
return 0;
}
//Create the ship
int s_idx = ship_create(&ori, &pos, si_idx, ship_name);
//Make the lua ship object, if the ship was created
if(s_idx > -1)
{
//Make the lua ship object and set the ptr to NULL
lua_ship *lsp = (lua_ship*) lua_newuserdata(L, sizeof(lua_ship));
luaL_getmetatable(L, "ship");
lua_setmetatable(L, -2);
lsp->shipp = NULL;
lsp->shipp = &Ships[s_idx];
return 1;
}
return 0;
}
static lua_msn_ship_setSpeed(lua_State *L)
{
lua_ship *lsp;
vec3d vel;
if(!script_parse_args(L, "ufff", SCRIPT_UDATA("ship", lsp), &vel.xyz.x, &vel.xyz.y, &vel.xyz.z))
return 0;
//Set the speed
Objects[lsp->shipp->objnum].phys_info.vel = vel;
//We're done!
return 0;
}
static const script_func_list lua_msn_ship_funcs[] = {
{"setSpeed", lua_msn_ship_setSpeed},
{SCRIPT_END_LIST},
};
//LIBRARY define
static const script_object_list lua_msn_lib_obj[] = {
{"ship", lua_msn_ship_funcs},
{SCRIPT_END_LIST},
};
static const script_func_list lua_msn_lib[] = {
{"newShip", lua_msn_newShip},
{SCRIPT_END_LIST},
};
That all makes up the Mission (abbreviated to "msn") library. So to add that, plus the grl and base libraries...
static const script_library_list Lua_libraries[] = {
{"grl", lua_grl_lib, NULL},
{"msn", lua_msn_lib, lua_msn_lib_obj},
{NULL, lua_base_lib},
{SCRIPT_END_LIST},
};
I've set it up so that the init functions will take those and run the required Lua functions on them.
As a result you can do this from Lua script:
my_ship = msn.newShip("GTD Rampart", "GTD Orion", 10, 15, 20)
my_ship:setSpeed(0, 0, 3000)
Well, with one small hitch; for some reason, the Lua 'ship' object isn't getting set as the right userdata type.
-
Originally posted by WMCoolmon
Mission (abbreviated to "msn")
Oh noes!
Is abbreviation necessary? If so then maybe you should call it fsm instead. :D
-
Yeah, it's funny how standard coder abbreviations work out to names that sound bizarre (f y cn rd ths, y shld b a prgrmmr). EG "graphics local" = grl = girl, "mission" = msn
For *final* lib names, I was thinking using four-letter words (no, not those four-letter words) for all the global libs; three-letter words would be used for local definitions. Object types would keep their full name to keep total obfuscation from happening. (Except for maybe "jump node"..."node" seems to work nicely...yes...)
-
Originally posted by Kazan
we have four developers opposing and one in favor
two in favor.
it'd be nice to have the option.
-
Took another look at this.
I was able to get the class working properly, except Lua crashes shortly after setting the ship speed.
On the plus side, it looks like once you have a class, it's easy to define array indexing functions. So...
Lua
Ship["hull"] = 1000
C
static int lua_msn_ship_elem_set(lua_State *L) {
char* var_name;
float* new_hull;
lua_ship* lsp;
if(!script_parse_args("usf", SCRIPT_UDATA("ship", lsp), var_name, new_hull)) {
return 0;
}
if(!stricmp(var_name, "hull")) {
lsp->shipp->hull_strength = new_hull;
}
return 0;
}
//Also, add it to the object functions
static const script_func_list lua_msn_ship_funcs[] = {
{"set", lua_msn_ship_elem_set, SCRIPT_GET_FUNC}, //<-- this one
{"setSpeed", lua_msn_ship_setSpeed, NULL},
{SCRIPT_END_LIST},
};
That's all educated guess right now; I need to break apart one of the Lua auxlib functions before I can do it like that.
I think the crash may be caused by LuaJIT, unfortunately. I figure I'll try compiling with the vanilla lua libs and see if the crash still occurs. I've already had LuaJIT reliably crashing when I try to load the Lua IO library... :doubt:
On the plus side, I seem to have managed to get precompiled functions working.
Edit: Removal function guess:
lua_pushstring(Ssn, lib_name);
lua_gettable(Ssn, LUA_GLOBALS_INDEX);
lua_pushstring(Ssn, func_name);
lua_gettable(Ssn, -2);
lua_pop(Ssn, -1);
-
BTW if anyone has some opinions on general syntax or libraries or functions that should be included, now's the time to air them. The three major items on the to-do list are:
- Get object-oriented programming working (without consistent crashes)
- Get LUA working as an expression system
- Figure out how to remove functions/libraries/objects once they're added.
-
how big will out list of game data variables be? also the ability to access any pof data of a model, and to get coorinates in absolute and relative coordinates (relitive would be usefull if newtonian ever gets implemented). like if i need to know where a point in a dock path is, i can get it in absoluute coordinates, or relitive to any ship in the mission.
-
stuf like that would almost exclucively be in local (relitive to the object it's on) coordanants, though a global_space(vector) function would probly be easy.
-
Hmm, how about making a special local vector and separate world vector classes?
Or, making a vector class, special local class, and special world class; the vector class would hold the vector in local and world coordinates, the two 'special' classes would be gotten by calling a function to return them.
Or (:p) using specific names for functions, eg "grl" for local graphics, "grw" for global-vector based graphics.
The list of game data variables would be as big as it needs to be. For the functions currently provided, at least major ship and weapon variables.
-
access to pof data would be good to have as well. id like at some point to be able to script custom sensor modes as well as hud gauges. also would there be a way to implement custom keyboard comands via scripting that would actually appear in the control config.
-
Originally posted by Nuke
also would there be a way to implement custom keyboard comands via scripting that would actually appear in the control config.
I would think that'd be a pretty bad idea given the possible platform and i18n issues. If it were thought out pretty well then perhaps a similar idea could be implemented, but without it being restricted to particular configs.
-
There's an easy way to take care of that, taylor, but its a touch bloaty (not Offce XP bloaty).Just slightly bloaty. the SDL documentation has a lead.
-
#1 on the to-do list is pretty much done.
Just need to set it up for special functions.
-
just use something like the imulse system that quake had. you had several impulses that could be referanced in quake c and bound to controls in the quake config files. set up the config screen to read a table that lists custom controls and a bitflag which is stored as a global integer. then simply provide that integer to the scripting system.
-
OK, I've done something insanely evil.
I've abstracted Python and Lua to the point that either can be used. At the same time, if both are compiled in. :p
Separate libraries/functions/objects would be needed for both, since they each call functions and object methods directly.
Usage:
$Script: [
--Lua goes here
]
$Script: {
#Python goes here
}
$Script: #Python goes here
:D
Edit: Yes, you should be able to link the SEXP system in as well.
-
damn, the rest of the devs are gonna flame you for that. i dont mind cause i really want scripting :D
is there an exe available?
also can you add the variables that the lead indicator operates on for testing, i want to try to make that k-12 radar sight i always wanted :D
-
Originally posted by mikhael
There's an easy way to take care of that, taylor, but its a touch bloaty (not Offce XP bloaty).Just slightly bloaty. the SDL documentation has a lead.
But you may be assuming that the current key reading code is sane. :) Some of it is strangely hardcoded to deal with mission issues and the freaky way that languages are delt with. I'd feel better about it if we were just using SDL but we don't under Windows yet and it will be a while before we do.
But even using SDL there are a couple of places where the platform dictates several things (there is a small German fix that is done under Linux but not under OS X since it's not needed there). It took several weeks for me to coerce the German keyboard layout to work 100% thoughout the code. Don't really want to go through that again on a larger scale.
Maybe when all of that code is cleaned up it would be easier to do, but for now everything works and changing it would mean a rewrite. That's not to say that Nuke's question can't be revisited again when the code makes better sense, but for now it's not really an acceptable option.
-
OK, a more complete to-do list:
- Fix special operators for objects (eg "+" "[]" "<=" and such)
- Provide functions with the script_state class to get and set global variables
- Figure out how to do temporary objects/variables
- Reintegrate LuaJIT into the project (I've been using stock LUA in case of bugs with LuaJIT)
- Figure out how handle return values (Edit: In a multi-scripting friendly way, I have a simple function that handles pretty much all data types for Lua)
- Clean up the code
- Add comments to the code :nervous:
- Integrate what's done on Python into the new system.
That's all for Lua, save the last one. I don't plan on working more on the Python stuff except to get what's already in there working again.
return values
What's interesting about Lua is that it allows multiple return values for functions. Barring the obvious mathematical impossibility :p it's quite nifty.
However, it does mean that whenever you want to return a value you must explicitly say "return value"; in Python, you could actually do it implicitly via a variable; hence the bracketed and non-bracketed Python.
It does raise an interesting conundrum of how to handle it though. Disallow more than one return value? Or leave it optional.
And automatically toss in the "return" value for Lua, and make that the default scripting language used w/o brackets, or leave it explicitly defined?
Here's an example of what I mean..
Here's now:
$Ship: GTF Ares
$Shield strength: [return 2 * 25] ;;Lua
$Shield strength: [
somevar = 2 * 25 ;;<-- this is also valid Lua here
return somevar ;;<--
]
$Shield strength: {} ;;Python; impossible to return anything here, I believe, so shield strength would always be 0
$Shield strength: 2 * 25 ;;Python again.
Or I could make it like this:
$Ship: GTF Ares
$Shield strength: [return 2 * 25] ;;Lua
$Shield strength: [
somevar = 2 * 25 ;;<-- this is also valid Lua here
return somevar ;;<--
]
$Shield strength: {} ;;Python; impossible to return anything here, I believe
$Shield strength: 2 * 25 ;;Lua again, with "return" manually added in automatically
-
bloody firefox crashed and I lost my response. Here's the shorter version.
taylor: The only part of FS2 that I ever made a stab at working on was the input code. I laughed, I cried, I screamed in fear. I've been so traumatized I never went back. I also recommended ripping the whole thing out and starting over with something agnostic. I was making absolutely no assumptions. Second, I wasn't actually suggesting using SDL, I was just pointing out that in the docs they describe an agnostic interface, which, of coure, is unnecessary if you ever do go to SDL (which I think would be nice, but again, not what I was advocating).
WMCoolmon: make those global variables/constants accessible in an a global array (dictionary would be even better if lua supports that, python does). That way all you need is introspection to find out what global variables there are without having to hardcode accessors/mutators for all of them.
-
I was planning on just providing get() and set() functions, if that's possible, that would use the scripting system's environment. to store the values.
-
Originally posted by mikhael
taylor: The only part of FS2 that I ever made a stab at working on was the input code. I laughed, I cried, I screamed in fear. I've been so traumatized I never went back. I also recommended ripping the whole thing out and starting over with something agnostic. I was making absolutely no assumptions. Second, I wasn't actually suggesting using SDL, I was just pointing out that in the docs they describe an agnostic interface, which, of coure, is unnecessary if you ever do go to SDL (which I think would be nice, but again, not what I was advocating).
Some of if is being rewritten but not enough in my opinion (I'm doing the rewrite). We are going to go with SDL on all platforms eventually and when that happens it will be cleaned up and work a bit better.
Wasn't aware of an agnostic interface idea in the SDL docs. That's certainly something I'd like to take a look at. Got a link to it, or just which section it's in?
-
I can't find it now. It might have been a user addition that's been purged since. When I just did a quick run through a moment ago its not there. IIRC it was just a matter of ignoring keycaps and reading scancodes and taking the local system's standard codepage to report back what that specific system thought a scancode really meant. There was some discussion in the addenda between other users who had success, and others who had trouble (said discussion probably being why it got purged out).
-
Meh! (Re-rails thread)
Now that I have this committed to CVS...all this is in C, so if you're just interested in scripting with Lua, ignore this and see my recent build. :p
Note that while I'm keeping Python in for now, I'll end up removing all support for it if noone expresses interest in coding for it after awhile.
Scripting extension how-to for Lua in fs2_open
Right now scripting is very easy to do, but also somewhat limited. I haven't added a function to let you get the result of evaluating an expression; but you can provide functions and objects.
First of all, find the "Housekeeping" line. You will not need to change anything below that.
The important structs
script_lua_lib_list - An array of libraries
script_lua_func_list - An array of library functions.
script_lua_obj_list - An array of objects provided by a library
script_lua_obj_func_list - An array of object methods.
Important defines
LUA_NEW_OBJ() - Creates a new object in Lua and returns a pointer to it.
LUA_UDATA() - Used with script_parse_args to check an object's type and store it to a pointer
LUA_RETURN_OBJECT - Return this when you've created an object with LUA_NEW_OBJ that you want to return.
Important functions
script_parse_args - Parses args provided to a function, using a format list that specifies the destination arguments.
b - boolean
d - double
f - float
i - int
s - string (Pointer to a char*)
u - userdata (Using LUA_UDATA for the argument)
script_return_args - Like parse_args, except returns the specified values. Lua can have multiple return values. If you have created a new Lua object with LUA_NEW_OBJ, note that it counts as a return value (I provide a 'u' placeholder)
How-to
Look at the existing functions I have in there. It should be pretty straightforward. Adding libraries, functions, and objects is done by simply adding arrays and defining function bodies.
General scripting usage
Once you have a script_state global, and have called Create*State for it, that scripting subsystem should be fully initialized. Yes, you should be able to create multiple states...I don't advise it though.
Parsing code for later use
Call script_state::ParseChunk(). This will return a script_hook, which can be used later for...
Running code
Call script_state::RunBytecode() with the script hook from ParseChunk(). This will return 1 if it succeeds. There's no way to get return values from code yet, at least not in a non-hackish way.
You can actually use script_parse_args() with GetLuaSession() after calling RunBytecode with Lua to get return values...that won't work at all for Python though, and somewhat breaks the abstraction I'm going for.
-
id probibly need to see some hevily commented example scripts to understand what you just said.
-
Originally posted by WMCoolmon
Meh! (Re-rails thread)
Now that I have this committed to CVS...all this is in C, so if you're just interested in scripting with Lua, ignore this and see my recent build. :p
Note that while I'm keeping Python in for now, I'll end up removing all support for it if noone expresses interest in coding for it after awhile.
.....
-
now you know why i dont try to program for the scp :D
-
If python remains in, WMC, I'll use it. :)
-
It's not so much a matter of using it as coding in the stuff for it. Most people seem to prefer Lua, so I'm trying to stick with it, although it's a toss-up as to which API is worse :p (Python, with its vague function descriptions and single type, or Lua, with its lowlevel stack functions with cconfusing names/descriptions)
-
OK, I've just committed a fix to the code that enables operators...that'd be stuff like "+" "-" etc etc.
Would anyone be interested in a FS2_Open LUA API how-to? This would be covering things like how to add classes and objects defined in C to Lua.
-
Yet another commit.
This one adds the ability to treat C pointers to objects (eg "ship" or "ship_info" structs in Freespace) as actual objects in Lua.
Basically, procedure is, if you just want to pass a pointer to an object, you use the LUA_CVAR macro with lua_parse_args() and lua_return_args(), with a "p" format character.
If you actually want to throw a whole class/struct into Lua, you use LUA_NEW_OBJ to create it, then the LUA_CVAR macro with lua_parse_args() to get it.
(Note that in Lua, an object itself is passed as an argument to a function; so if you had GTF_Hercules:setSpeed(3), the first argument would be the GTF Hercules object, the second argument would be 3)
Meaning: more efficiency, less overhead, easier to code in new Lua objects, etc. :p
-
it seems like you will need to know alot about internal functions to get data from the game to be used in script. also is the scripet executed on a per frame basis or another timeframe or does it have to be running in its own little loop?