Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Aardwolf on July 04, 2009, 07:34:00 am
-
So I was wondering how to do the following things. I'm willing to work with the source code (i.e. I'm not relying on existing features), but not willing to rely on 'custom' builds. Id est, changes that cannot be committed to trunk do not suit my needs.
1. Modifying/altering the default Esc behavior, in-mission. What would the best way? That is, so that instead of bringing up the end mission dialog, it could either be modified to do something else, or disabled outright. Since the context I'm interested in is the RTS mod, which is already using extensive scripting, I was thinking a scripting hook with +override capability. However, the people who I mentioned the idea to seemed to think that was overkill. Problem is, although I'm willing to do code changes, I'm hoping to avoid having to use 'custom' builds... so they would have to be changes that are commit-worthy. And flat-out removing that dialog isn't commit-worthy.
2. Drawing a grid. The grid would have a fixed position and orientation (but customizability wouldn't hurt). So far I've been able to do this by having a ship which uses an enormous textured quad as its model. The problem is, this is all kinds of messed up, as far as depth sorting. For example, if any ship goes through it, the stuff on the far side is invisible. Beams that intersect its plane are clipped. Et cetera.
-
:bump: because I still want to hear some replies to this...
-
2. Drawing a grid. The grid would have a fixed position and orientation (but customizability wouldn't hurt). So far I've been able to do this by having a ship which uses an enormous textured quad as its model. The problem is, this is all kinds of messed up, as far as depth sorting. For example, if any ship goes through it, the stuff on the far side is invisible. Beams that intersect its plane are clipped. Et cetera.
I think this would be best done with the Lua Scripting (http://www.hard-light.net/wiki/index.php/FS2_Open_Lua_Scripting) system. I'd suggesting making a post over in their dedicated forum (http://www.hard-light.net/forums/index.php/board,145.0.html) here at HLP, and looking through some of the example (http://www.hard-light.net/wiki/index.php/Tutorial_-_Basic_Scripting) Lua (http://www.hard-light.net/wiki/index.php/Scripting_examples) scripts (http://www.hard-light.net/wiki/index.php/Script_-_Escort_Reticle) in the wiki.
-
Aardwolf is perfectly aware of the scripting... What he is asking - on a brief glance - is a function written in C into the lua.cpp for drawing the grid (assuming there is such C function)
-
Aardwolf is perfectly aware of the scripting...
:ha:
What he is asking - on a brief glance - is a function written in C into the lua.cpp for drawing the grid (assuming there is such C function)
Not quite. I'm considering the options in general for how to do it. Adding scripting support for functions is something I already know how to do, if it is necessary. The issue is, I don't know exactly how it would be done. It's more of a cpp-side question, I guess.
-
I know that Aardwolf is aware of the Scripting system (Aardwolf has made some good changes to it recently)
It's just IMHO I believe it better that people thoroughly explore using the current Lua scripting API to achieve a task, rather than taking the route of implementing the feature as new cpp code with a single Lua API call to it. Lua is there to cut down on the cpp code base bloat!
-
Echelon: Agree totally.
Although I'll argue against code bloat. Once my DX changes go in, we'll have removed almost 11mb of files from SVN. :nod:
-
I know that Aardwolf is aware of the Scripting system (Aardwolf has made some good changes to it recently)
It's just IMHO I believe it better that people thoroughly explore using the current Lua scripting API to achieve a task, rather than taking the route of implementing the feature as new cpp code with a single Lua API call to it. Lua is there to cut down on the cpp code base bloat!
The problem is that the existing lua functions do not seem to cover this eventuality. Normal keys work fine in-game, they can be caught and processed in scripting, but the Escape key can not.
-
The_E: Remember that the escape key is a special one, it is not like other keys.
Importantly, it places a much bigger burden on the script writer to RTFM.
I'd be curious about how things would go if we triggered a script hook for the escape key, and then kept processing normally (ignoring any return from a function).
Any opinions?
-
Well....Adding a script hook for that would work, however, I would like to have the option to catch the escape before the game sees it.
What about this: Change the $On Key pressed hook in such a way that it defaults to passing through keypresses, unless the script specifies some sort of key input handler.