More modding questions for the devs

(Fitzsimmons) #1

I couldn’t be at qcon itself, but I’ve got the forums, which should be just as good, right?

[ol]
[li] Is there any hope of seeing an improved GUI system? The D3/Q4 GUIs are cool and all, but they’re really lacking flexibility. For example, the layout cannot be dynamically modified, and they’re really lacking decent callback support. You can call script functions on events, but that really isn’t enough for some nice dynamic behaviour. For example, my Inventory mod uses a gui that is totally made up of hacks and workarounds. Here’s how it works: When the player opens the inventory, it swaps a boolean variable which tells some code in Player to poll every tic (YES, UGLY). When the onClick event is received in the gui itself, it sets a number of GUI state variables which are polled by the aforementioned player code. To determine which box the player clicked in, I grab the cursor position from the GUI and run some calculations on it to see find out which box the mouse cursor was in when the player clicked on it. Also, when the player is moving an item around within the inventory, I have to update two gui state variables every tic to reposition the window containing the image. This nice story is basically just an example of the hacks that have to be used to do anything remotely complex in doom3 GUI. Is GUI system in ET:QW: is it improved at all with greater flexibility? If not, is there any chance of making this a “feature request” from the modding community? I can understand that something like this is probably at the bottom of the priority list, especially if the commercial game itself doesn’t require this type of functionality, but it would be really nice to see. (I can provide a more detailed feature request if this is actually being considered seriously…)
[/li][li]In the qcon modding video, geometric texture generation was cited as one of the features of the new editor, to aide with the generation of megatextures. Is this process customizable in any way? If it works the way I’m thinking it works, TC mods will greatly appreciate some flexibility in this area (you know, in case the map isn’t on Earth, or something like that).
[/li][li]Can we get an official word on built-in AI support? “None” is the answer that’s been floating around, as far as I understand, but I’d like to get it straight once and for all.
[/li][li]There seems to be an “entity count ceiling” at about 1500 in doom3, meaning that if there are around 1500 entities in the view at once, the performance just up and dies. Has this been addressed at all in QW?
[/li][/ol]

Thanks!

(Hakuryu) #2

In the qcon modding video, geometric texture generation was cited as one of the features of the new editor, to aide with the generation of megatextures. Is this process customizable in any way? If it works the way I’m thinking it works, TC mods will greatly appreciate some flexibility in this area (you know, in case the map isn’t on Earth, or something like that).

I would imagine it works like any other game that uses this type of texturing. I can only think of Far Cry off the top of my head, but I’m sure other games and terrain tools have it.

You can set the distribution of each texture based upon the height and angle of any point on the terrain. For example, say we have dirt, grass, and rock textures on a terrain consisting of a river cutting through a valley surrounded by mountains. We want dirt below the water, grass upon flatter areas but not on steep angles, and rock on the mountains and other steep angles.

So we set dirt by elevation, using the height of the river. Anything under this height will be dirt. Grass is set at an elevation higher than dirt, but not high enough to cover flatter areas higher on our mountains. It also needs to be set not to be placed upon any angles greater than 45 degrees for realism. Rock we place elevation over the grass and anywhere over the river that has a slope greater than 45 degrees.

This is a really simple explanation, and I dont know if they have any other modifiers besides height and elevation. In Far Cry, I think 7 layers of textures was the max, but I have no idea if this is even an issue in Quake Wars.

This is quite flexible, but is only a start. It is like using a heightmap for a terrain; a good start and ready to be edited further by hand.

(JJeep) #3

One question that I have is about the player limits, in the videos I think it was mentioned about 24 players running around and fighting. Is that the player limit that’s built into the game, or the limit on that server that you were using?

If it’s the limit built into the game, is this going to be changeable by mod teams?
If it’s the limit on the server you were using, what is the limit that the engine can support and can this be changed by mod teams?

Thanks

(Salteh) #4
(JJeep) #5

[/quote]
sweet, must have missed that preview :slight_smile:

(digibob) #6

Is there any hope of seeing an improved GUI system? The D3/Q4 GUIs are cool and all, but they’re really lacking flexibility. For example, the layout cannot be dynamically modified, and they’re really lacking decent callback support. You can call script functions on events, but that really isn’t enough for some nice dynamic behaviour. For example, my Inventory mod uses a gui that is totally made up of hacks and workarounds. Here’s how it works: When the player opens the inventory, it swaps a boolean variable which tells some code in Player to poll every tic (YES, UGLY). When the onClick event is received in the gui itself, it sets a number of GUI state variables which are polled by the aforementioned player code. To determine which box the player clicked in, I grab the cursor position from the GUI and run some calculations on it to see find out which box the mouse cursor was in when the player clicked on it. Also, when the player is moving an item around within the inventory, I have to update two gui state variables every tic to reposition the window containing the image. This nice story is basically just an example of the hacks that have to be used to do anything remotely complex in doom3 GUI. Is GUI system in ET:QW: is it improved at all with greater flexibility? If not, is there any chance of making this a “feature request” from the modding community? I can understand that something like this is probably at the bottom of the priority list, especially if the commercial game itself doesn’t require this type of functionality, but it would be really nice to see. (I can provide a more detailed feature request if this is actually being considered seriously…)

There seems to be an “entity count ceiling” at about 1500 in doom3, meaning that if there are around 1500 entities in the view at once, the performance just up and dies. Has this been addressed at all in QW?

The GUI system has been re-written from the ground up, and it should proivde a lot more flexibility.

You really really really shouldn’t have that number of entities in view at once, as each of those things is going to have to be frustum culled, portal culled, etc. As much as possible, you’d want items grouped together for batch rendering, and for the culling, as this makes things much faster.

(Salteh) #7

:banana: :moo:

(jimb0) #8

Digibob: thanks for that info… but can you tell if the gui format gone through a lot of changes? or it has just been expanded rather than replaced by something else?

(jRAD) #9

The old GUI system has been completely replaced; the overall syntax of the GUIs is similar to the Doom3/Quake4 format, but you can’t just load a Doom3 .gui file into ETQW without making some changes to it.
If you understand the Doom3 .guis then picking up the new system shouln’t be difficult.