Objectives Editor Gui

[sparhawk]

Ah, but that's the point - it may not run at all. Thief 2 actually refuses to run under VMware (it displays an error dialog and then quits). Doom 3 may be the same.

 

It may, but it doesn't have to.

 

I probably should have said "I can't run Thief 2" instead of "I can't play Thief 2".

Even Voodoo cards are 3D-accelerated.

 

I know. But I think there are also OpenGL software renderers, at least under Linux, so it would be worth a test to see if Doom3 refuses them or not. Don't know if there are software OGL libraries for Windows, but for Linux tehre defginitely are some, so it might work to run Linux in a VMware with Doom.

[OrbWeaver]

Yeah, I guess you could just have a base component class with a generic function that handles a general set of keys and then read additional keys as needed. I just didn't think of that when I was setting this up. I just slapped something together that worked, so I don't claim it's the most elegant code or anything. I really doubt I'll have time to rewrite it any time soon though.

 

I think I will start trying to get the Linux build to work (not just for this, I would like to get back into modelling and mapping, and having a functioning installation is important for this), at which point I can look into this code. It may be that changing the Objectives code to accept a simpler specification system is less work than encoding large amounts of knowledge into the GUI, so I would rather not do the latter without having at least looked into the former.

[sparhawk]

When you start on the linux port, you must be aware that not only the code will be needed to be adjusted with the filenames. I bet that our main mod will also have issues with the paths, in the material files and animations. So this will also have to be taken care of.

[OrbWeaver]

I don't think that the virtual Doom 3 paths used in def files will be a problem, since (1) this would also be a problem with DarkRadiant, which I always run on Linux, and (2) all of the Doom 3 paths are platform independent, using a standard forward-slash, case-sensitive convention (basically the same as Linux anyway). If there were such issues with the def files I suspect that I would have encountered them already.

[greebo]

@OrbWeaver: What's the status of the Objectives Editor, i.e. what's missing? It looks quite good already, but I don't have an overview about what you planned to implement. I can help out if you have trouble finding the time or motivation.

[OrbWeaver]

Off the top of my head, I think most of the necessary infrastructure and data structures are in place. Remaining tasks are to implement the required set of ComponentEditors (there is only one partially-implemented ComponentEditor at the moment), add the necessary code for saving and loading Component information to/from entity spawnargs, and some miscellaneous features which have been left unimplemented (such as the "activate at start" checkboxes in the main Objective Entity list).

 

I was also planning to adding a second layer of switchable GUI panels for each Specifier type, so that the Entity Name specifier would present a button to browse the available entities, the Entity Class specifier would browse the list of entity classes (which in turn requires moving the Entity Class browser into the eclassmgr module rather than the main GUI) etc. The first one of these is implemented for the None specificer and just displays a static message.

 

By all means feel free to take on the task if you want to see it done more quickly (i.e. at any time before the impending heat death of the universe).

[OrbWeaver]

I thought that the "Add Objectives Entity" button was broken, but it seems that it is actually working -- only the target_tdm_addobjectives entity is no longer visible because the small box that represents a non-model entity is not rendered.

 

Have there been any changes that affect the rendering of such entities? I seem to recall a discussion about these boxes, but don't remember if any changes resulted.

[greebo]

I thought that the "Add Objectives Entity" button was broken, but it seems that it is actually working -- only the target_tdm_addobjectives entity is no longer visible because the small box that represents a non-model entity is not rendered.

 

Have there been any changes that affect the rendering of such entities? I seem to recall a discussion about these boxes, but don't remember if any changes resulted.

I'll have a look - maybe there is some layering issue, but it's probably easy to fix.

[greebo]

Hm, it works fine on my end, I can create as many entities as I want, all show up as yellow small boxes with arrows.

[OrbWeaver]

Now I think of it, I haven't finished re-downloading the mod and my DarkRadiant is set to Doom 3 base, so maybe this is the standard behaviour if the entity type is not recognised (it is not very good behaviour in any case, since it is not at all obvious the entity has even been created).

[greebo]

If you don't mind, I will try to shove up some free time to look into the Objectives Editor to pave the way for the pending 0.9.7 release. I figured it's better to work on the Objectives GUI first before I start a new one for the Conversation system - the objectives are far more important.

 

I'll probably need to get a grip of the ComponentEditors you mentioned, but I assume it won't be too hard.

 

Do you have any changes in your local working copy that are not checked in yet?

[OrbWeaver]

If you don't mind, I will try to shove up some free time to look into the Objectives Editor to pave the way for the pending 0.9.7 release. I figured it's better to work on the Objectives GUI first before I start a new one for the Conversation system - the objectives are far more important.

 

Sure, this is long overdue and you will get it done a lot more quickly than I will.

 

I'll probably need to get a grip of the ComponentEditors you mentioned, but I assume it won't be too hard.

Do you have any changes in your local working copy that are not checked in yet?

 

I don't think I have any changes, but I will check when I get home.

 

The ComponentEditors are not that hard, they are basically the same idea as the PropertyEditors in the Entity Inspector. There are actually two levels of dynamic widget construction in the Objectives Editor: one to create a widget for each Component type (i.e. the "Kill" component editor can say something like "Select the object to be killed"), and another to create a widget for each Specifier type (so that an "Entity" specifier could provide a selection button for existing entities, rather than a plain text box).

 

In order to get the plugin into a usable state, the main tasks are:

 

1. Create ComponentEditors for each of the Component types, even if most of these are very basic (or identical).

2. Create SpecifierPanels for each of the Specifier types, these could all be simple text boxes to start with rather than fancy buttons.

3. Make sure that all component/specifier stuff is parsed from the spawnargs (I believe it is written but not read at the moment).

 

After this the fleshing out of individualised component/specifier editors can take a more leisurely pace.

[Ishtvan]

On the objective system side, I was thinking we might want to make a string name that the mapper can use to refer back to each objective. Reason being, objectives can get added ingame, and it's bad to have the label of the objective correspond to the order in which it was added. A mapper could have something like two target_addobjectives that could each add a new objective and could be triggered in either order (based on which part of the map the player chooses to explore first, for example). Then you wouldn't know which was which when addressing those objectives later. Maybe this has been fixed already, but I don't think so.

[greebo]

Well, this would be easily possible from DarkRadiant's point of view, I just need to adjust the regular expression when looking for objective-related keys.

 

But on the other hand, I estimate that the issue you mentioned will not occur in at least 98% of the maps.

[greebo]

Ok, as a first step, I added ComponentEditorPanels for all the COMP_YYY types available in the game code. They are not really working yet, as this will be the next step, I suppose.

 

One thing I noticed is that objective components can have an arbitrary number of arguments, which was not considered by the objectives editor before. I added the data structures and hopefully this can be handled by the component editors themselves rather easily. I'm at 80% understanding the existing framework (it forced me into learning two new idioms, which is a good thing), but overall I'm in the picture now.

[OrbWeaver]

One thing I noticed is that objective components can have an arbitrary number of arguments, which was not considered by the objectives editor before.

 

Oh, you mean the Specifier::MAX_SPECIFIERS should not be 2, but that an arbitrary number of specifiers should be accomodated? I did not realise the code allowed for this.

 

Ultimately the design was that each ComponentEditor would have a fixed number of Specifier edit panels based on the requirements of the component type, so I guess if certain Component types require 3 or more specifiers than the MAX_SPECIFIERS value should be increased. If there is a Component type which accepts a variable and unbounded number of specifiers, this could be harder to accomodate.

 

I'm at 80% understanding the existing framework (it forced me into learning two new idioms, which is a good thing), but overall I'm in the picture now.

 

I'm curious as to what new idioms were in the ObjectivesEditor which you haven't seen already?

[greebo]

Oh, you mean the Specifier::MAX_SPECIFIERS should not be 2, but that an arbitrary number of specifiers should be accomodated? I did not realise the code allowed for this.

No, the components can have an arbitrary number of string arguments, which are specified by a spawnarg like this:

"obj1_1_args" "1 3 atdm:playertools_health_potion" // space-delimited

I added an additional _arguments string vector to the Component class to reflect this, plus the necessary accessors (WIP).

 

I'm curious as to what new idioms were in the ObjectivesEditor which you haven't seen already?

Namely these are the typesafe enum idiom and the virtual constructor idiom. Although I just realised that I already used a pattern very similar to the virtual constructor idiom in the AI State/Task framework I wrote last year (without knowing about the term). Instead of defining virtual create() methods, I employed string-mapped boost::function objects which point to the correct static CreateInstance function.

 

Memory-wise it's more lightweight, as you don't have to store actual instances of the classes in the library, just the boost::function objects - not too much of a difference, actually. Overall, one can just refer to this as "factory" approach, I guess.

 

Remember that I don't have formal computer science education - I never took real classes where these things are presumably bashed into people's heads, I just learned from reading code and books. Nevertheless I'm very interested in these types of things, even if it's just to understand other people's code faster.

 

In case you're interested, I can recommend the Effective C++ and Effective STL books by Scott Meyers, they consist of 80% useful stuff, 10% not useful/known stuff and 10% real eye-openers. My next C++ book I'll order will be Efficient C++, hopefully I'll get around to read it too.

[greebo]

Status update: the component editors are mostly functional now. The objectives plus components in test/objectives.map are now correctly parsed and can be edited.

 

Things missing:

- the mission success logic

- the mission failure logic

- the "enabling objective" handling

- the userfriendly display string of components (arguments are not included in the string, for instance)

 

and possibly a million other things.

 

For starters, I'll just add a string edit field for the success/failure logic.

[Ishtvan]

We could conceivably tell them if their mission/objective logic is valid when they enter it in the box. We could parse the objective identifiers out of the spawnargs and then parse the logic in the same way as in the SDK.

[greebo]

We could conceivably tell them if their mission/objective logic is valid when they enter it in the box. We could parse the objective identifiers out of the spawnargs and then parse the logic in the same way as in the SDK.

Yes, that's the long-term goal and would be quite convenient for the mapper, I suppose. For now I'll just go with the text box and rely on the mapper not to type some nonsense into that entry field, it's better than nothing. As soon as the Objective Editor is stable/feature complete we can iterate over it to make it more convenient and powerful.

 

The current status is:

- The Objective editor layout has been changed a bit to create more room for the objective's properties.

- The difficulty option (which level the objective is applicable to) is done.

- The "enabling_objs" spawnarg is supported (also just a text field for now).

- The mission_success_logic and failure_logic strings are supported (including the difficulty-specific ones).

- Fixed a number of smaller issues.

- The objective GUI is saving their size and position between sessions.

 

Next up will be the userfriendly display of the objective components plus the completion_script / failure_script spawnarg support.

[greebo]

Status update: I think all objective spawnargs and features can now be controlled via the GUI. I'm currently working on the user-friendly component display, which is a bit tricky (and admittedly not that important), but we're almost feature-complete now.

[Ishtvan]

Great! That should make things exponentially easier for mappers to set up objectives now. We may also want to point out that this system can also be used for conditional scripting, using hidden objectives with a completion script that you want to be run under the condition you defined with the objectives editor. Incidentally, I wonder if we could link it into your "effects" system so that effects can happen when an objective is completed, to make it even more userfriendly?

[greebo]

Yes, it's almost done now, I think we can easily have a test version ready by the end of the week. After a short review of the plug-in, we're ready to release DarkRadiant 0.9.7.

 

Incidentally, I wonder if we could link it into your "effects" system so that effects can happen when an objective is completed, to make it even more userfriendly?

Hm, it would take some consideration, because the effects scripts are designed to work with the sr_-prefixed spawnargs and are meant to run "locally" on the entity. The objective scripts are global, so this would probably take some design implications. Not sure if it's worth it right now, but as soon as a mapper comes up with a "real" use case for such a system, I'm happy to come up with a solution.

[Ishtvan]

Hmm, maybe objectives could trigger a set of mapper-filled in target entities when they're completed or failed, and those entities could put out a stim with effects?

 

I'm not sure a mapper is going to come up with something on their own, we may have to do a tutorial on how to use objectives for conditional scripting. But I guess your point is that we shouldn't spend much time on it if no one's going to use it? I just thought it might save some mapper time vs rube-goldberg setups, since it is already designed to detect when various things happen.

[greebo]

I like the idea of triggering things when one objective is completed or failed. This is as easy to define as the completion/failure script settings and sounds quite powerful. I think I'll add support for this when I get home.

 

(Technically, it would be trivial for mappers to write that activate() call in the completion script, but I learned that mappers don't tend to like scripting at all or are even afraid of it. Currently only Dram and angua are using scripts in their maps.)