[mikhael]

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

[Kazan]

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

[WMCoolmon]

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.

[mikhael]

Kazan has spoken. Everyone pack up and go home. He's absolutely right.

[Kazan]

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

Code: [Select]


( when
   ( is-event-true-delay
      "Start shuttle alpha"
      28
   )
   ( add-goal
      "Bravo 1"
      ( ai-waypoints "Bravo1-way" 89 )
   )
)


here is a complex one

Code: [Select]


( 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 )"

[Goober5000]

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.

[mikhael]

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.

[CaptJosh]

But can you add the scripting layer without creating unacceptable CPU load in game?

[Goober5000]

No no, I understand that point, mikhael.  I know about games implementing stuff through scripts.  I want to make sexps the scripting layer.

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.

[Kazan]

Originally posted by CaptJosh
But can you add the scripting layer without creating unacceptable CPU load in game?

not really

[CaptJosh]

Ok. If that's true, Kazan. Why? What are the technical limitations?

[Kazan]

It's a scripting engine, there is a lot of overhead involved in interpreting script - it's just the nature of text parsing

[CaptJosh]

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?

[Kazan]

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

[mikhael]

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.

[Kazan]

mikhael: make sexp-functions for manipulating the hud - all the basic arithmetic functions are already there

[mikhael]

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.

[WMCoolmon]

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:

Code: [Select]

( when
   ( >
      ( distance
         "Alpha 2"
         "TCS CV-50 Wellington"
      )
      30000
   )

Code: [Select]

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:

Code: [Select]

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

Code: [Select]

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

Code: [Select]

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

[Kamikaze]

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?

[mikhael]

Bless you, Kamikaze. That's exactly the point I was trying to bring across.