[Aardwolf]

I have messaged Nuke--with whom I was working on this project--about this idea, but he has not yet responded, so I don't even know for certain if he is interested in resuming this project at present. As such, consider the following post with a mostly hypothetical intent.

My idea was to put some (most) of the RTS mod's code in C format, rather than doing it in Lua.

My thinking is that this would improve speed and would allow it to be more event-driven, rather than state-driven. As an example, our current 'mouse-click' code is triggered not by an event but by a test of whether the mouse is pressed against a record of the state during the previous frame. An event-driven version of this would fix the problems that occur with low framerates (like being able to click for a duration shorter than the frame, thus not triggering a click event but triggering events that currently rely on whether or not certain invisible weapon objects are in play--a system which works but feels very icky to me, and I'd gladly do away with given half the chance.

We might need a little help from a coder, but I hear they are hard to come by, so drop-in advice is just as appreciated as realtime coaching/work.

I was thinking that a launcher flag to toggle RTS mod features on or off would be useful, but Goober5000 said that doing so would be a 'very bad idea'. I still believe a launcher flag might be a good way to do it, but I think what triggered that remark was the idea of conditionally loading an external TBL file depending on the checked-or-unchecked state of that launcher flag, which could cause a crash or some other sort of error if the flag were checked but not such TBL were present.

So my current idea for external media/etc., which is still in need of expert advice: A launcher flag, plus a new set of table entries, or an optional table. The table entries/table would still be parsed, but they wouldn't be used (unless someone else finds a concurrent and compatible use for the data). The optional table would be checked for, but if it isn't found, it would have to NOT crash, but instead just move along and assume default values/properties. Goober suggested ai_profiles as a place to put such data, is that a good choice?

As for the sort of data/table entries we would need, we need to store information about ship costs, special (RTS) orders accepted, resource carrying capacity, jump drive charge time, etc., either on a per-ship-class basis, or on a ship type basis. Or both.

To make things easy, if Nuke thinks it is a good idea, I would request (but am not making such a request yet) that a coder could make functions to process input and manage the display for us, as well as pointing out the names and how to use all the functions that are necessary to get state info, trigger actions, etc. (probably as the need arises, rather than presented in advance and then being unnecessary/insufficient); effectively, someone we can quickly ask how to perform a certain task, and get a simple "like this..." or "for what, NO that's a bad idea, instead do this" answer.

[Charismatic]

They the got a pic already, thats a good start. Keep fighting the good fight.

[Nuke]

i think a hybrid idea would work, we continue and make the mod primarily as a lua script, but adding features to the engine, parts of the scripting system, ect. to support the concept.  i dont want to add a bunch of code to the engine for rts mods only, id ratter add functions that can be used by everybody for a variety of mod ideas.

[Aardwolf]

EDIT! This post is assuming a highly-scripted future of this mod. Even so, I think some of the features we are requesting would come in handy.

I'm starting a list of some features we will need and may end up making. For now, non-members: treat this as a wishlist, but tell us if you plan to help in advance, and tell us if there's already a way to do something!

I'll try to categorize and Color Code them, but the categories may get changed as later edits are made to the list.

Script Events ("Action Hooks"):

• Mouse Pressed
• Mouse Released (duh)
• Mouse Moved
• Key Pressed (I know a lot of people (SoL included) who would love this one (Do a BARREL ROLL!))
• Key Released (naturally)
• On Mission Start
• On Mission End (maybe)

More Script-Accessible Stuff:

• Metadata system (allows scripters to tag additional data fields onto ships)
• Ship copy (get all ship data and store it, used in the RTS mod when a ship completes a jump-out)
• Ship paste (retrieve copied ship data and create a new ship with all of that data, scripting changes as needed)

Colors:
Lime Green - Completed/already exists
Red - Aborted/unnecessary
Purple - Someone please do this for us (and the rest of the community, too!)
Orange - Teach us and we will do our best (And I'll try to keep Nuke off it while he's hopped up on goofballs and whatnot)

[karajorma]

I was thinking that a launcher flag to toggle RTS mod features on or off would be useful, but Goober5000 said that doing so would be a 'very bad idea'. I still believe a launcher flag might be a good way to do it, but I think what triggered that remark was the idea of conditionally loading an external TBL file depending on the checked-or-unchecked state of that launcher flag, which could cause a crash or some other sort of error if the flag were checked but not such TBL were present.

I'm 100% with him on this one. Using a launcher flag for this should be a last resort not your starting point. The SCP have in general been trying to avoid adding new command lines for over a year now. And I don't think any have been added which actually change game logic (only things like

• As soon as you add a command line flag you have to deal with the problems caused by users switching it on and off. Look at the constant stream of people having problems with -jpgtga even though Turey's Installer turns it on by default for an example of this. You're going to have people turning it on when playing other FS2 mods ("Ohh! Play BtRL as a RTS game! I'll turn that one on!") and turning it off when playing your mod.
• Having a command line flag prevents you from doing a RTS-sim mod where some of the missions are RTS and some are standard. It also prevents you doing a Hostile Waters-esque hybrid of the two. Which would be a huge shame as that's something I would absolutely love to see the engine do.
• Having a command line flag boxes off the features you add so no one else can use them. Both the TBP and WCS flags do something similar and are very annoying if you want to use one of their features without having to drag in all the others. If you let everyone use your features they'll get bug tested faster and harder than if you wait for you to find them. You also give the other coders more reason to help you out. Their mods might want that particular feature too. Don't make yourself the only coder interested in your project by making yourself the only person using that code.
• Once you start providing code that others can use it makes them more inclined to include your requests in what they are doing. Many of the things you said you wanted are things that would be useful outside RTS games. I've already been working on a system to make it possible to change any ship in the mission based on the value of a variable. If you use that with your stuff you instantly get Homeworld style persistence of fighters and capships across missions.
  

So with that in mind I think you should try to integrate this as much as you can with the standard FS2 game rather than trying to go it alone with your own tables and flags no one else can use.

So why don't you draw up a list of what you need and what you want and then we can discuss how to turn them into code that everyone can use?

[Aardwolf]

Wow, thanks for the info. I've got a better understanding of the issue now.

What I was planning when I started this topic was more of a complete overhaul of the mod, with most of the scripting being changed to source code. Nuke didn't really like that idea, though, and said we should do a hybrid (See above).

Still, I think it might be good to code some of the stuff, perhaps allowing it to be enabled using a script, in-mission sexp, mission flag, etc. There are many ways it could be done; it could even be made possible to enable it more than one way (that is, to have scripts + mission flags both capable of enabling it, or some other combination, or all 3). If someone could suggest another way or present a decent (not too long, not too short) list of possibilities, I think that would be a good start. Most of my very colorful post up above depend on how far our mod leans toward scripting vs c++.

Now, once again, I find myself drifting further from what Nuke seems to have envisioned; perhaps a compromise can be reached. Here's an idea: one or more ways to enable multiple sub-features of the RTS project, as well as a general 'enable all' and/or 'enable with specified options' means of doing it. The problem I am foreseeing right now, though, is that in order to do most of the RTS functionality in c++ code, and still have it be possible to use parts of it individually, a LOT of lua functions, and probably some hooks, will need to be coded--stuff even Nuke + I probably can't do.

I agree, a launcher flag, given the arguments kara has put forth, is not an ideal solution.

Other options, people?

[Nuke]

i really had 2 things i wanted the fsrts to do. the first was to prove the scripting system to modding community in general. the other was to come up with dynamic missions which are generated mostly on the fly.

the current roadblocks are input, which is hackish at best right now, and the ability to better manage orders and way points.  input is pretty bad on an engine wide basis. ive always pushed for a system to better handle multiple controllers, involving more axis commands as well as the ability to add mappable controls (axes and buttons) to the list from script. from what i know about the input situation, its the pilot files that are holding up development there, and those are usually being worked on constantly. input in the fsrts involves an alpha 1 way out in the middle of nowhere and locked in place by script, having all its controls hijacked and used to control the camera. aardwolf doesnt seem to like this, and i sorta agree.

orders and waypoints, while we can create them, we really cant manage them very well. to simply command a ship to move, you would essentially give it a chain of waypoints to follow and then an order to follow it once. this works for the ship a few times, until its order list is full. we also need to clear waypoints because as far as i know were only allowed 32 paths. there are extreme limits to how many times we can issue move commands.

both me and aardwolf are looking at the code, trying to figure out what we can do with it. once i finish my pspew types code, im gonna start looking at scripting and input and see if i can make any changes there that may be useful. i cant speak for aardwolf but im interested in how the fs engine works, and would rather implement a few functions myself that take up coder time to have you all implement it all for us.

[WMCoolmon]

What exactly are you looking for right now?

[Nuke]

we looked through parse/scripting/ trying to figure out how everything works, so that we could add scripting features. but the whole thing seems to be over our heads. also i really don't have time to code anything at all right now with work finally starting to pick up. i got to head that way now. il look over the code again next time i have a day off and try to come up with more specific answers to that question.

[Stormkeeper]

I remember Hostile Waters. That game rocked hard. To bad they didn't do a sequel. Probably cause it didn't get rave reviews and didn't sell.

It might help if you got your hands on the source code of an rts and gave it a once over. It might give you a better idea on how to setup mouse functions and stuff.

[WMCoolmon]

http://www.hard-light.net/forums/index.php/topic,54043.0.html