[WMCoolmon]

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)

Code: [Select]

----------------------------------------------------------------------------
-- 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

[Goober5000]

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:

Code: [Select]

weapon.damage() * target.shield_strength() + weapon.damage() * 0.5is equivalent to

Code: [Select]

((weapon.damage() * target.shield_strength()) + (weapon.damage() * 0.5))is equivalent to

Code: [Select]

(+ (* 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.

[mikhael]

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.

[WMCoolmon]

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

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):

Code: [Select]

;;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:

Code: [Select]

$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

[kasperl]

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.

[Nuke]

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.

[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

[kasperl]

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

That can be fixed using a few lines, I'd wager.

Code: [Select]


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:

Code: [Select]


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?

[WMCoolmon]

Probly not.

Also, parabolas are fun.

Code: [Select]

$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
}

[Nuke]

so let me het this straigt, all code will be written in python.tbl and the modules would be internal?

[kasperl]

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?)

[WMCoolmon]

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.

[Kazan]

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.. I'd say the Postfix notation SEXP trees are _MORE_ readable due to the use of () in the operator convention.

[taylor]

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, .  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.

[Nuke]

freespace memory usage has never bothered me. im dirt poor and if i can afford a gig of ram then anyone can .

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.

[StratComm]

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.

[karajorma]

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).

[Inquisitor]

Oi, this is what I get for ignoring engineering titled threads.

Python has advantages, mostly in support and readability. It's 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.

[Kazan]

WMC 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

[aldo_14]

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.