Author Topic: Question: A script to be included to code  (Read 3020 times)

0 Members and 1 Guest are viewing this topic.

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: Question: A script to be included to code
the problem is there is no sane way to break up your script into more sections for organizational, debugging and modularization purposes. right now theres no way of getting around this problem in lua without using dofile. this will not work in the future. so something at the engine level needs to be done in order to make this possible. replacing dofile with something that automatically resolves the file path is a good idea. being able to explicitly run multiple lua files in a specific order for a single hook in the scripting table, and let the file system determine where the lua files are same way it would find a texture. thats also very good idea.

one of the major problems with scripting is the lack of integration with systems that the engine should manage internally. input is the best example. in the same way lua shouldnt care where its running from, lua also shouldnt care what keys are bound to what, only what the command is and what its state is. lua in its current state only seems to give low level information about whats going on with various input devices, so the script has to recreate some of the engine's functionality for itself, running in parallel to the engine's system and seriously confusing people who play mods as to why they have two sets of keybinds to deal with. so i can see where your getting at.
« Last Edit: January 31, 2010, 02:47:38 am by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Iss Mneur

  • 210
  • TODO:
Re: Question: A script to be included to code
[snip]
hmm.

I didn't realize that the scripting in FSO was so far removed from the engine.

I guess that goes on the list now as well.
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: Question: A script to be included to code
scripting these days seems like something growing on the codebase that has trouble dealing with basic game logic. it often has to re-create basic engine internals from scratch, i mean simply to use the keyboard for script input requires writing an input system from scratch, then you have to rely on either hardcoded keyboard commands or some parsed file that has to be edited in notepad to change the bindings. it is kinda reminicent of quake 1 and 2 mods (of course when quake 3 rolled around it had a scriptable interface to fix those problems). its not as bad as it was in the early days, when wmc felt the need to change names of functions (or changing get/set functions to virtual variables) in each build. i actually have an archive of scripts that used to work well and now dont work at all. most of it is obsolete crap but a few gems, like freespacelancer and my advanced turret scripts are somewhere it there. makes me think of how much of lua.cpp was written by scripters with little c expirience (im probibly the best example of that). essentially whenever i want to do something in scripting that cant be done, i go into lua.cpp copy an existing similar function, and edit it to make it look up whatever peice of information in the various structs that has whatever info i need, often with read and write access without understanding the consequences of changing that data on the fly. amazingly it usually works and wont break retail so long as it dont use scripting. lua.cpp has turned into an epic mess of ineffitient code and most of the functions are 90% identical.

dont get me wrong, lua is awesome and many popular games make use of it. its unappreciated and not used by many. freespace is so easy to mod that most modders would rather use tables and the events system to accomplish things. and there are so many new features added every month that its hard to keep up with them, let alone find things to do with scripting that cant be tabled in by next week. it kind of creates an environment where modders arent very innovative and wont implement a feature unless it can be done by adding a couple lines to the tables. and if something they want isnt available they could easily find a member of the scp to implement it for them (i remember when you had to sacrifice a small animal or two to get them to add a feature for you). when i was modding quake 1&2 you couldnt just model something and stick it in the game immediately, you always had to write code before you could use it. unless you did maps, which was incredibly difficult (as a directory filled with unfinished partially compiled quake maps on my hd would attest).  my experience with quake-c was one of the reasons i supported scripting. i thought that if that system was in freespace it would be awesome. but quake was built around quake-c, all the gameplay was defined by it. unlike with freespace that had all of its gameplay defined and then had scripting thown on after the fact with a few interfaces to various aspects of the game. its one of the things that attracted me to freespace modding was how simple it was to work with. if your models were solid and your tables didnt have errors in them you could roll out models like crazy. the only thing thats hard to do is to mod gameplay, which is where scripting comes in. i just wish it exposed more of the engine and was more versitile and more intuitive to work with.
« Last Edit: February 04, 2010, 09:52:55 pm by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN