[Aardwolf]

Bumped, for great justice.

The RTS mod looks like it might be getting revived soon, and I'm rethinking some stuff about it. There are some things we will want to be able to do, and aren't entirely sure whether or not it can be done (efficiently) yet.

There are a few areas that I'm thinking about right now. Among these are:

1. Making the ship AI (particularly for the player's ships) more RTS-like -- almost a complete override of the ship AI. I'm not sure what the best way to implement this would be. If you've got any ideas, lemme hear 'em.

2. In-engine support for our metadata system. Basically, the engine would keep a variable list of fields for each ship that scripting could interact with, so we could look up or assign values for each ship of fields we create at runtime with the scripting system. Fields would preferably be creatable on a ship-per-ship basis, but being able to set default values or user-defined functions to come up with a default value if none exists for a certain field would also be handy.

3. Some UI things. Right now the main things I can think of are drawing the boxes around selected ships, making selections, and picking targets for actions. Right now all of these are handled by our scripting thing, and I'm not going to ask that they be entirely pushed to the engine level. However, I think it might be useful to have the following util functions:

• A function which determines what ships are within (or completely within) a certain screen rectangle (possibly given certain constraints or, more easily doable, a subset of ships to check for).
• A similar function, but instead returning a single ship which is the 'best' one. I'm not sure how the metric would be set up in general, but in our case we'd probably give it a single screen coordinate and possibly a subset of the ships in play, and it would figure out which one we are 'clicking on' (like the way most RTS's do unit selection). The only problem here is that most RTs's can safely treat units as circles or ellipses (or ellipsoids), and that might not work for this ... especially considering that fighters are kinda small and their ellipsoid might easily intersect that of something larger; picture trying to select a GTF Loki that is flying through the holes in a GTM Hippocrates.
• A function to return the bounding box of a ship's targeting brackets (that is, where they would be drawn if it were targeted. This might come in handy for other modders as well if it came with an option to draw the brackets, or if there were a function which did so.

WMCoolmon (or whoever else who knows about this), how doable do these requests sound? (Ask for clarification if you need it!)
I hope the feature freeze doesn't prohibit doing anything with scripting...

One last thing... I'm not sure if this is already doable or not, if it is how, if not I think it might be useful:

4. A system for modifying textures without using render-to-texture. (My graphics card doesn't even support frame-buffer objects, so I can't use RTT anyway). Basically this would blit sprites to some pixel/texture data somewhere, and then it would glTexImage2D(...) that data into a texture. This would be useful for things that need to be done with a texture but are effectively a 2d display (like the radar in Nuke's interactive cockpit demo).

[Goober5000]

Split for great justice.

(and unstickied )

[Aardwolf]

Woot, free sticky!

[Grimper]

The only problem here is that most RTs's can safely treat units as circles or ellipses (or ellipsoids), and that might not work for this ... especially considering that fighters are kinda small and their ellipsoid might easily intersect that of something larger; picture trying to select a GTF Loki that is flying through the holes in a GTM Hippocrates.

I think it would be easier just to prevent ships from intersecting in the first place, by not letting them fly through holes and such. Putting an invisible wall (actually it doesnt have to be invisible if the view is gonna be top down, but I hope the view can be changed anyway) in the holes would prevent this.

Most RTS games these days use a similar system.

[Aardwolf]

That would make it very difficult for fighters to fly back into fighterbays.

[Grimper]

Don't put invisible walls on the fighter bays then. A fighter your ordering somewhere else might want to pass through a ship with holes in it, thus giving a reason for invisi walls, but it wouldn't go into a fighter bay by itself much unless the player specifically ordered it to.

[Nuke]

i dont know i think those problems could be overcome wth the right selection tools. say you want that fighter thats hiding in the hole in the arcadia to come out and kill something. you could selcct the whole area, then click a filter button to screen out the fighters. then give those orders. ot you can have a wing indicator which is a set of brackets that indivate a fighter wing. then get down to an individual fighter with a selection screen.

the engine already seems to have a top down mode but that type of gameplay has issues, like rendereing certain turrets useless. because everything is forced to a flat plane. where nothing would ever enter its fov. if you design a mission on a flat plane, then naturally the ships will want to fly shortest paths and therefore would stay close to the plane. you might occasionally get a figter to want to do something stupid and leave the "box". there you can do something like what you have with the subspace model, replace it with an invisible textured box model that keeps everything contained in the flyable area. something tries to leave it hits the invisible wall.

[Droid803]

Well, if you use a 3d-camera system with 3d movement like in Homeworld/HW2, selection wouldn't be a problem, would it? (plus it'd also be moar awesome).

Not that I know of what I'm talking about.

[WMCoolmon]

1. Making the ship AI (particularly for the player's ships) more RTS-like -- almost a complete override of the ship AI. I'm not sure what the best way to implement this would be. If you've got any ideas, lemme hear 'em.

Someone(TM) is working on a more modular AI system. Maybe _argv, I don't really know. I looked in the "status" thread on the internal but they weren't there, so they're either not a SCP member or they haven't updated that thread.

2. In-engine support for our metadata system. Basically, the engine would keep a variable list of fields for each ship that scripting could interact with, so we could look up or assign values for each ship of fields we create at runtime with the scripting system. Fields would preferably be creatable on a ship-per-ship basis, but being able to set default values or user-defined functions to come up with a default value if none exists for a certain field would also be handy.

I don't think this would be too difficult for someone to do, since you could model it after the arrays used for other things, like SEXP variables. There is some code to provide this functionality for all scripting hooks, not just ships, but I never worked on it enough that it worked and was usable.

3. Some UI things. Right now the main things I can think of are drawing the boxes around selected ships, making selections, and picking targets for actions. Right now all of these are handled by our scripting thing, and I'm not going to ask that they be entirely pushed to the engine level. However, I think it might be useful to have the following util functions:

• A function which determines what ships are within (or completely within) a certain screen rectangle (possibly given certain constraints or, more easily doable, a subset of ships to check for).
• A similar function, but instead returning a single ship which is the 'best' one. I'm not sure how the metric would be set up in general, but in our case we'd probably give it a single screen coordinate and possibly a subset of the ships in play, and it would figure out which one we are 'clicking on' (like the way most RTS's do unit selection). The only problem here is that most RTs's can safely treat units as circles or ellipses (or ellipsoids), and that might not work for this ... especially considering that fighters are kinda small and their ellipsoid might easily intersect that of something larger; picture trying to select a GTF Loki that is flying through the holes in a GTM Hippocrates.
• A function to return the bounding box of a ship's targeting brackets (that is, where they would be drawn if it were targeted. This might come in handy for other modders as well if it came with an option to draw the brackets, or if there were a function which did so.

1) Sounds reasonable.
2) Something like FRED does? I'm not quite sure what you're saying but if I have it, that sounds reasonable as well.
3) Sounds reasonable

With all of these functions, they sound more like a helper toolkit kind of thing. Some extra care should be taken to make sure that they're implemented as such, and not just lumped in with some of the other lower-level things. ie if the functions in there now are various types of Legos, these sound more like buying spaceships and stuff pre-made out of those legos. However, they do sound pretty similar to the getScreenCoords function.

WMCoolmon (or whoever else who knows about this), how doable do these requests sound? (Ask for clarification if you need it!)
I hope the feature freeze doesn't prohibit doing anything with scripting...

One last thing... I'm not sure if this is already doable or not, if it is how, if not I think it might be useful:

4. A system for modifying textures without using render-to-texture. (My graphics card doesn't even support frame-buffer objects, so I can't use RTT anyway). Basically this would blit sprites to some pixel/texture data somewhere, and then it would glTexImage2D(...) that data into a texture. This would be useful for things that need to be done with a texture but are effectively a 2d display (like the radar in Nuke's interactive cockpit demo).

There doesn't seem to be any focus on scripting in the project roadmap atm, which is both good and bad. Good, because there's a lot of extra leeway for someone to go in and work on features. Bad, because nobody is doing it atm.

I think #4 is really only doable with some kind of software emulation of RTT. Because all RTT does is do all that ("blit sprites to some pixel/texture data somewhere") but on the video card. So that would mean you'd need to go through and rewrite all the 2D graphics functions to have the code to support that. You'd probably also have to do a lot of bmpman and lowlevel graphics library work to make it work without the rest of the code really knowing what's going on. So this would be the hardest request to fulfill so far, and it's getting harder to justify since all the newer graphics cards should support RTT.

What graphics card are you using?

[Aardwolf]

Oh wow. I forgot about this (well, I got a bit confused by the thread split and subsequent events)

Someone(TM) is working on a more modular AI system. Maybe _argv, I don't really know. I looked in the "status" thread on the internal but they weren't there, so they're either not a SCP member or they haven't updated that thread.

The improved turret AI code, or something more general?

(...)

I don't think this would be too difficult for someone to do, since you could model it after the arrays used for other things, like SEXP variables. There is some code to provide this functionality for all scripting hooks, not just ships, but I never worked on it enough that it worked and was usable.

That's good to hear.

With all of these functions, they sound more like a helper toolkit kind of thing. Some extra care should be taken to make sure that they're implemented as such, and not just lumped in with some of the other lower-level things.

(...)

However, they do sound pretty similar to the getScreenCoords function.

Yeah, that was sort of the point. It is certainly possible to figure out what ships have their center points inside a selection box, or what the closest center point to the the cursor is, but I don't think these would be the best way of making selections; think about what would happen if a small ship and big ship got close together on the screen, or a big ship (or the Colossus ) stuck into the selection box or the area the user clicked. To handle these situations I think a hard-coded (i.e. built into the engine) function would be better than writing a script function.

I hope the feature freeze doesn't prohibit doing anything with scripting...

There doesn't seem to be any focus on scripting in the project roadmap atm, which is both good and bad. Good, because there's a lot of extra leeway for someone to go in and work on features. Bad, because nobody is doing it atm.

Nobody doing it, right... so you don't want to sell your soul to the RTS Mod? *quietly tucks wad of bills back into pocket*

I think #4 is really only doable with some kind of software emulation of RTT. Because all RTT does is do all that ("blit sprites to some pixel/texture data somewhere") but on the video card. So that would mean you'd need to go through and rewrite all the 2D graphics functions to have the code to support that. You'd probably also have to do a lot of bmpman and lowlevel graphics library work to make it work without the rest of the code really knowing what's going on. So this would be the hardest request to fulfill so far, and it's getting harder to justify since all the newer graphics cards should support RTT.

What graphics card are you using?

I'm using an Intel 945GM Express integrated graphics card. I guess for this one I was figuring that there were GL functions that would be able to do 2D blitting faster than the 3D rendering alternative. I don't know for sure, I usually stay out of that topic in the OpenGL man pages.

It's nice to know everything (or most of it) sounds feasible.

[WMCoolmon]

The modular AI system basically consisted of a bunch of function pointers you could redirect to whatever you wished, IIRC...so it was more of an "everything AI code" update.

I'm not really interest in working on SCP stuff in general right now. I'm sticking around to provide support but I don't plan on directly coding anything. Adding scripting functions to existing librarys or handle types should be really easy for anybody who knows basic C, plus whatever the relevant functions are for the subsystem they're implementing (in this case, mouse and 2d-3d subroutines).

And for the last question, I don't really know what the answer would be. If you're working with images, working on the card itself would almost certainly be faster because the texture wouldn't have to be reloaded from the HDD or system ram. With lines and other shapes, it might be faster to do it with the raw speed of the CPU. I'm a bit surprised that the 945GM doesn't support RTT since it's so new, even though it's integrated. The changes involved would still be pretty complex though. The only way I could see around that is if you just did something that circumvented bmpman entirely - eg doing something in scripting that would more or less amount to a hack, but would be virtually invisible between computers. That would also be extensive in and of itself, you'd have to expand the 'texture' handle to include a variable to note whether it was a real bmpman handle or a dummy handle for the software RTT, and then make sure that worked with all the other functions and also deal with if somebody tried to attach that handle to a ship texture or something like that.

So to be honest, I don't have a complete idea of how hard that will be, but the lower bound would probably put it on the level of being a 'hard' request - if only because you'd be messing with delicate subsystems.

[Aardwolf]

If anybody still cares about us...

• A function to return the bounding box of a ship's targeting brackets (that is, where they would be drawn if it were targeted. This might come in handy for other modders as well if it came with an option to draw the brackets, or if there were a function which did so.

This currently looks like the biggest thing we need. Wanderer has helped me narrow down a slowdown to the bounding box get function I wrote, but it doesn't look like there's anything to it that can be optimized. If I get a chance, I'll look for relevant stuff in the SCP code, and see if I can write something up and give it to someone who can put it in the right place to make it work.

I'm going to delete the post I made in the other thread which is almost identical to this one, since it's almost identical anyway.

Edit: I've written up a C++ function which would I think might work. It would need a proper name and might require some consideration about return type and argument types, but it looks good to me (although I can't really test the thing). What we'd need is for it to be put in properly (either in trunk if the code freeze is over (is it?) or in a branch if it isn't), and for someone who knows how to do it to set it up so we can call it in Lua.

C++ function: http://fsscp.pastebin.com/m1a9ad10b

As for the Lua syntax, I reckon something like this would be good:

Code: [Select]

--gr.setColor as needed beforehand
x1, y1, x2, y2 = gr.drawTargetingBrackets(object, draw=true, padding=5)

If the C++ function returned FALSE, the Lua function's return values would all be nil.
Otherwise, they would be the bounds of the box (i.e. the values returned in the *int parameters to the C++ function).

The draw argument of the Lua function corresponds to the want_to_draw argument of the C++ function, and the padding argument to the Lua function corresponds to the padding argument of the C++ function.



So, how do I get this done?

[Aardwolf]

Shamelessly, too

I'm going to see if I can still build from SVN. If I can, I'm going to add in and test this little gem I wrote: http://fsscp.pastebin.com/m299aac9b

Edit: I've run into some small issues with it, but I'm dealing with them as I come across them. I'll reupload the function and any related notes (namely about added #include directives) when I get it working.

Edit II: I've got it *almost* working. The only problem is for nonstandard resolutions it draws the brackets in the wrong place. I'm sure this has a fix, but not knowing what it is doesn't help. Here's the code, containing (as comments) where it belongs, what other changes it needs, and a more detailed assessment of the problem:

http://fsscp.pastebin.com/m2831356b

Edit the Third: I got it, and committed it to the RTS Mod SVN. Unfortunately, the feature only exists in the binary I built, so I've uploaded that and provided a web link in the SVN. Windows only, I'm afraid.

Here's the working code, in case someone is able to go ahead and put it into the SCP's SVN:

http://fsscp.pastebin.com/md9784bc

It includes in the comments at the top info on what file it goes in and the added #include directives needed. If I knew how to create a .patch file I would do that, but I don't, so I can't.

[karajorma]

If you're using TortoiseSVN then making a patch is as simple as right clicking on the directory and choosing Create Patch from the menu.

[Aardwolf]

Wow, cool! I'll get right on that...

Edit: it looks like a plain-text file, so I'm using [code][/code] tags. File extension is .patch

Code: [Select]

Index: lua.cpp
===================================================================
--- lua.cpp (revision 5245)
+++ lua.cpp (working copy)
@@ -11,10 +11,12 @@
 #include "graphics/font.h"
 #include "globalincs/linklist.h"
 #include "globalincs/pstypes.h"
+#include "hud/hudbrackets.h"
 #include "iff_defs/iff_defs.h"
 #include "io/key.h"
 #include "io/mouse.h"
 #include "io/timer.h"
+#include "jumpnode/jumpnode.h"
 #include "lighting/lighting.h"
 #include "mission/missioncampaign.h"
 #include "mission/missiongoals.h"
@@ -8053,6 +8055,102 @@
  return ADE_RETURN_TRUE;
 }
 
+// Aardwolf's targeting brackets function
+ADE_FUNC(drawTargetingBrackets, l_Graphics, "object Object, [boolean draw=true, int padding=5]",
+ "Gets the edge positions of targeting brackets for the specified object. The brackets will only be drawn if draw is true or the default value of draw is used. Brackets are drawn with the current color. The brackets will have a padding (distance from the actual bounding box); the default value (used elsewhere in FS2) is 5.",
+ "number,number,number,number",
+ "Left, top, right, and bottom positions of the brackets, or nil if invalid")
+{
+ if(!Gr_inited) {
+ return ADE_RETURN_NIL;
+ }
+
+ object_h *objh = NULL;
+ bool draw_box = true;
+ int padding = 5;
+
+ if( !ade_get_args(L, "o|bi", l_Object.GetPtr(&objh), &draw_box, &padding) ) {
+ return ADE_RETURN_NIL;
+ }
+
+ // The following code is mostly copied from
+ // void hud_show_brackets(object *targetp, vertex *projected_v)
+ // in hudtarget.cpp
+
+ if( !objh->IsValid()) {
+ return ADE_RETURN_NIL;
+ }
+
+ object *targetp = objh->objp;
+
+ int x1,x2,y1,y2;
+ int bound_rc;
+
+ int modelnum;
+
+ switch ( targetp->type ) {
+ case OBJ_SHIP:
+ modelnum = Ship_info[Ships[targetp->instance].ship_info_index].model_num;
+ bound_rc = model_find_2d_bound_min( modelnum, &targetp->orient, &targetp->pos,&x1,&y1,&x2,&y2 );
+ if ( bound_rc != 0 ) {
+ return ADE_RETURN_NIL;
+ }
+ break;
+
+ case OBJ_DEBRIS:
+ modelnum = Debris[targetp->instance].model_num;
+ bound_rc = submodel_find_2d_bound_min( modelnum, Debris[targetp->instance].submodel_num, &targetp->orient, &targetp->pos,&x1,&y1,&x2,&y2 );
+ if ( bound_rc != 0 ) {
+ return ADE_RETURN_NIL;
+ }
+ break;
+
+ case OBJ_WEAPON:
+ Assert(Weapon_info[Weapons[targetp->instance].weapon_info_index].subtype == WP_MISSILE);
+ modelnum = Weapon_info[Weapons[targetp->instance].weapon_info_index].model_num;
+ bound_rc = model_find_2d_bound_min( modelnum, &targetp->orient, &targetp->pos,&x1,&y1,&x2,&y2 );
+ break;
+
+ case OBJ_ASTEROID:
+ {
+ int pof = 0;
+ pof = Asteroids[targetp->instance].asteroid_subtype;
+ modelnum = Asteroid_info[Asteroids[targetp->instance].asteroid_type].model_num[pof];
+ bound_rc = model_find_2d_bound_min( modelnum, &targetp->orient, &targetp->pos,&x1,&y1,&x2,&y2 );
+ }
+ break;
+
+ case OBJ_JUMP_NODE:
+ modelnum = targetp->jnp->get_modelnum();
+ bound_rc = model_find_2d_bound_min( modelnum, &targetp->orient, &targetp->pos,&x1,&y1,&x2,&y2 );
+ break;
+
+ default:
+ // should never happen
+ Int3();
+ return ADE_RETURN_NIL;
+ }
+
+ x1 -= padding;
+ x2 += padding;
+ y1 -= padding;
+ y2 += padding;
+ if ( draw_box ) {
+ if( !(g3_in_frame() > 0) )
+ {
+ g3_start_frame(0);
+ draw_brackets_square(x1, y1, x2, y2, false);
+ g3_end_frame();
+ }
+ else
+ {
+ draw_brackets_square(x1, y1, x2, y2, false);
+ }
+ }
+
+ return ade_set_args(L, "iiii", x1, y1, x2, y2);
+}
+
 #define MAX_TEXT_LINES 256
 static char *BooleanValues[] = {"False", "True"};
 static const int NextDrawStringPosInitial[] = {0, 0};


[karajorma]

Yeah, patch files are plain text files with a different extension. Same with .diff if you ever see those.

[Aardwolf]

Yeah, I saw that was another option for file type to save as in TortoiseSVN as I was making that.

[Aardwolf]

Back to the business of RTS Requests... (and such a profitable business, is it not?)

I don't know if this is doable on non-Windows operating systems, but (assuming it is), is a function to constrain mouse movement to a specific rectangle (or to reset it to be unconstrained) doable? This would as I see it be mainly useful for GUI-things, i.e. not in-game (although the RTS Mod has a place where it could come in handy, for clicking on the mini-map).