Jump to content
The Dark Mod Forums

Objectives Editor Gui


Recommended Posts

Right. For the inventory items it doesn't matter where you place them. They are scooped up into the inventory before the map gets displayed. They just need to be around for the entities to be stored, for cases where the item can be dropped later on, but they are hidden after putting them in the inventory.

Gerhard

Link to comment
Share on other sites

  • Replies 98
  • Created
  • Last Reply

Top Posters In This Topic

Yeah, I guess we'd just have to make our best guess relative to the player spawn, and if they somehow end up in a solid they'll have to be moved. Unless DR can do traces against geometry and find an empty spot? Don't know if it has that capability or not.

Link to comment
Share on other sites

Unless DR can do traces against geometry and find an empty spot? Don't know if it has that capability or not.

 

There's no "easy" way of doing that unfortunately -- to determine the "inside" and "outside" of the map would require the full 3D flood fill.

Link to comment
Share on other sites

We can safely assume that the player is ain a position where he can start to move at least in one direction. Even if he would be confined to a very narrow space, he woul dhave to at least move in onde direction. So if you can do traces you should easily find such a direction with 8 or 16 traces IMO. Not much really, considering that this would take place only once.

Gerhard

Link to comment
Share on other sites

The easiest thing to do is simply to put the new entity very close to the info_player_start, such as 16 - 32 units. We can generally assume that the player start is not going to be touching a wall, so no matter which direction is used the new entity should have a pretty good chance of being inside the map (and if it isn't the user can always move it).

 

It's not really worth adding in traces and intersection tests just to place a new objectives entity IMO, this is going way beyond what an Objectives Editor should be dealing with.

Link to comment
Share on other sites

Yes. Right. I wouldn't fuss with it to much. After all, if the mapper would have to move it, it's not really that much a of a problem. We just should mention this somewhere, that placing an objective MIGHT cause a leak and in this case the mapper has to move the corresponding entity.

 

In my last map, I created an inaccessible room for such things. It also has the advatage that I always know where that stuff is located. But of course this is not really required. It doesn't really cause any problems because this room will never be seen anyway.

Gerhard

Link to comment
Share on other sites

In my last map, I created an inaccessible room for such things.

 

Yeah, I thought that might be an easy idea, to have a map that just has a single room with all the traditional starting gear in it, that mappers could just import right into their map.

Link to comment
Share on other sites

In my last map, I created an inaccessible room for such things. It also has the advatage that I always know where that stuff is located. But of course this is not really required. It doesn't really cause any problems because this room will never be seen anyway.

 

That's interesting, if you can have a separate inaccessible room but the map still compiles, the flood fill must be able to cope with disjoint sections. I guess this explains why you can't have a single entity outside the map -- it probably does a flood fill starting from EVERY entity in order to catch everything.

 

(Nothing to do with Objectives, just an interesting observation).

Link to comment
Share on other sites

I'm not sure, but you might have to set a light in such a room as well. If you don't put a light in it, it considers the room to be leaking for some reason. Or you got a compile error, not sure which as I haven't done this for some time now.

 

EDIT: Just tested it and it doesn't require it. I seem to remember that there was something. Maybe it was just that it needed to be textured. Which would make sense, because this is required for the leaking check.

Gerhard

Link to comment
Share on other sites

The component specifier stuff is horrific. Two "specifiers", with type enum, string and int parameters, along with a string and int parameter for the component itself. It's like the Windows API with its lParam and wParam stuff, except worse.

 

Why not just have obj1_1_param1 and obj1_1_param2, which are both string parameters interpreted by the component in a type-specific manner? I don't understand the need for hard-coded string and int parameters at both the component level and the "specifier" level (and I don't understand the need for a typed "specifier" at all).

Link to comment
Share on other sites

  • 2 weeks later...

I wrote up a design, it was met with general approval at the time, so I wrote it that way. :)

 

The specifier is there because the component type alone doesn't tell the parser what variables the FM author wants to look for with this component. For example if the FM author puts in a KO component, what do they actually want to check, KO of a particular AI specified by name, KO of a particular team specified by name, or just KO's among all AI? Once the specifier type is parsed, the system knows which variables to check on the AI that's been KO'd to see if it completes that particular objective component.

 

The reason that there's space for two specifiers is that some cases allow for two specifiers. For example, COMP_AI_FIND_BODY : Which AI do you care about finding a body, and which bodies do you care about them finding? You could specify that a particular AI should not see a particular corpse, both by name, or a particular team should not see a particular type, i.e., team mansion guards should not see AI bodies of type human (rat bodies are okay). The second specifier is not needed in most cases though.

 

I don't see how you could operate without the specifier. You could make a component type for every specifier, like KO_ByName, KO_ByTeam, KO_Overall, but then you'd end up with a huge list of possible components for every sensible permutation of component type and specifier type. To me it seemed cleaner to separate them.

 

If you don't like the specifier being an enum, how else would you prefer it to be read in? I guess it could be a hashed string instead of an enum. As for string specifier value and int value, I agree there's no need for that in retrospect. It could just be converted to numeric as needed in the parser.

 

I'm not too keen on rewriting the objectives parsing and event handling at this point, since I've still got more high-priority stuff I haven't yet finished, but if you or anyone else wants to, it's pretty self-contained in /src/MissionData.* It could probably be done without requiring much knowledge of the SDK library.

Link to comment
Share on other sites

My preferred way of specifying this would be as "source=value" pairs, e.g.

 

obj1_1_param1 : "sourceAI=head_guard"
obj1_1_param2 : "interestingBodies=ALL"

 

This means that in the GUI I could just have a set of string parameters, rather than having to worry about parsing enums, and furthermore the set of available "key" options could be different for each objective type rather than requiring fixed "types" as currently implemented.

 

The problem is that at the moment, there is a lot of "hidden knowledge" that needs to be written into the GUI -- which specifier types can be used with each condition type, and what they all mean. With the key=value system all that is required is the list of keys for each condition type, which is far simpler.

 

Unfortunately I cannot look into the SDK myself yet because the Linux build is not ready, but maybe greebo can be persuaded to add it to his task list... ;)

Link to comment
Share on other sites

Me? I have no task list so far. :D

 

Do you need information about what argument type does what? Or do you mean building the SDK under Linux? I believe Nyarlathotep wanted to this, although I don't know how much work this really is. I also don't have a Linux build installed currently (I wait for the next Ubuntu release which is due on April 19th).

 

I can feel your pain about the "hidden information" - writing the S/R Editor was much easier for me after I started working on the S/R system myself (there were quite some undocumented spawnargs present in the SDK that I didn't know of before).

 

Did you check out the SDK code (darkmod_src)? From my experience, reading the SDK code is very easy in comparison to the GtkRadiant codebase, so it might as well help just to have the .cpp files around. It's not as good as actually playing with the code but it's better than nothing.

 

I haven't fiddled around with the Objectives system so far, but I wanted to have a look at this anyway sometime (I planned to look into the "Objective Complete" GUI overlay, which is not yet implemented).

 

To be honest, I still would like to see you getting involved with SDK coding though. ;)

Link to comment
Share on other sites

I have checked out the DarkMod source, yes. At the moment it doesn't even start to compile due to the mismatched filename cases, but this can be fixed.

 

I guess there is no reason why I can't start getting the Linux build working, I'm a bit nervous about making changes which might affect the Windows compilation, because I would have no way of testing this until somebody else complains, but I suppose that's what we have source control for.

Link to comment
Share on other sites

I guess there is no reason why I can't start getting the Linux build working, I'm a bit nervous about making changes which might affect the Windows compilation, because I would have no way of testing this until somebody else complains, but I suppose that's what we have source control for.

 

I guess you don't need to be worried about that. If something is screwed up, because to fit, then we have to fix it. I wanted to look into the linux port myself, but only after we have a decent stable version of the mod.

 

One thing to think about is, to run the mod in a VMWare session (not sure if it really works, but Doom 3 scales very well, so it might be possible) so you can do the windows check without needing to reboot all the time.

Gerhard

Link to comment
Share on other sites

I don't think VMware emulates 3D hardware at all (except on Macs), so unless D3 has a software renderer...

 

I can't play Thief 2 on VMware, for example. :(

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

My preferred way of specifying this would be as "source=value" pairs, e.g.

 

obj1_1_param1 : "sourceAI=head_guard"
obj1_1_param2 : "interestingBodies=ALL"

 

This means that in the GUI I could just have a set of string parameters, rather than having to worry about parsing enums, and furthermore the set of available "key" options could be different for each objective type rather than requiring fixed "types" as currently implemented.

Sure, that would be one way to do it. That would mean the parser would need some kind of hash to convert strings like "AIName" "AIType" "AITeam" "AIInnocence" etc. into an internal enum or function pointers or something. It makes the GUI easier but the parsing harder. :)

 

I would prefer if each component type did not have its own unique sets of specifier keys, because that would mean I'd have to write a different callback function for each component type. Right now there is one general callback that handles all component types, because the specifiers are the same across the board. It knows which data it has to extract from the entity arguments based on the specifiers, so I only need one data extraction and requirement matching function. Having to write one for each component type would definitely make it harder to maintain that code.

Link to comment
Share on other sites

I don't think VMware emulates 3D hardware at all (except on Macs), so unless D3 has a software renderer...

 

I can't play Thief 2 on VMware, for example. :(

 

That wouldn't matter for that purpose. If D3 can run inside VMware, then you can use it to verify that it works, adn doesn't crash. If it looks like crap, it's not a problem, because it wouldn't be intended for gaming anyway. just compiling and running it should be enough to make sure that the changes for fixing a linux issue don't break the windows part.

 

I'm not sure if D3 can run with software emulation, though. There were some screenshots where it worked even with a Voodoo 3DFX card, so maybe it would also work with something like this.

Gerhard

Link to comment
Share on other sites

I would prefer if each component type did not have its own unique sets of specifier keys, because that would mean I'd have to write a different callback function for each component type. Right now there is one general callback that handles all component types, because the specifiers are the same across the board. It knows which data it has to extract from the entity arguments based on the specifiers, so I only need one data extraction and requirement matching function. Having to write one for each component type would definitely make it harder to maintain that code.

 

Normally such things are not a problem if you use an appropriate object-oriented design, such as by having each component type a separate class which is responsible for extracting the information it is interested in. I can't comment really though, having not seen the code.

 

I'm not sure if D3 can run with software emulation, though. There were some screenshots where it worked even with a Voodoo 3DFX card, so maybe it would also work with something like this.

 

I'm pretty sure there haven't been any games which support software rendering since about Thief 1. It's possible that there is a third-party tool which emulates a 3D-accelerated GL driver in software.

Link to comment
Share on other sites

Do you need information about what argument type does what? Or do you mean building the SDK under Linux? I believe Nyarlathotep wanted to this, although I don't know how much work this really is. I also don't have a Linux build installed currently (I wait for the next Ubuntu release which is due on April 19th).

Want to? Yes! But even I don't know exactly how much work it will be. I've been waiting until I knew others would have time to help out in case I got stuck (not to mention when I'd be sure to have time myself). I'm glad OrbWeaver is starting to look into it, though. :D:wub:

 

I didn't know a new release of Ubuntu was coming out this week. I guess I should start then, seeing as how right now I have to reinstall my Nvidia drivers every time I boot in.

Link to comment
Share on other sites

Normally such things are not a problem if you use an appropriate object-oriented design, such as by having each component type a separate class which is responsible for extracting the information it is interested in. I can't comment really though, having not seen the code.

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.

 

Aside from the actual callbacks when things happen, the code is all self-contained in /src/DarkMod/MissionData.* The counter structure for all these events keeps track of objective info and can also be used for end-mission stats later.

Link to comment
Share on other sites

That wouldn't matter for that purpose. If D3 can run inside VMware, then you can use it to verify that it works, adn doesn't crash. If it looks like crap, it's not a problem, because it wouldn't be intended for gaming anyway. just compiling and running it should be enough to make sure that the changes for fixing a linux issue don't break the windows part.

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.

 

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

 

I'm not sure if D3 can run with software emulation, though. There were some screenshots where it worked even with a Voodoo 3DFX card, so maybe it would also work with something like this.

Even Voodoo cards are 3D-accelerated.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...