Jump to content
The Dark Mod Forums

Bugs, patches, etc,.


CodeMonkey

Recommended Posts

#2829: Flashbombs should reduce AI hearing as well.

 

I created a patch for this issue, but, I wanted some feedback on it.

 

1. How much of a hearing reduction should this inflict. (I used 75% which does make it possible to escape, but, might be a bit too much.)

 

2. I implemented it into the AI blind state, which could be a problem, ie, if someone tried to use the blind state for any other purpose expecting only a blinding effect, etc,. (So, is this a good place for it, or should a new state be created, can the game even support multiple AI states at once, etc,. ?)

 

-----

 

General stuff:

 

I also wanted to mention that I've tried building under Visual Studio 2012, and it fails due to "forbidden" macros. (Seems like it will work under 2012, using the 2010 platform toolset, I'll have to confirm this.)

 

I've been looking into using OpenMP, any thoughts? (It looks fairly easy to implement, but I'm not sure about portability, etc,.)

Edited by CodeMonkey
  • Like 1
Link to comment
Share on other sites

1 - Does the sound deafness affects only AI that were "hit" by the bomb, or everyone inside a radius? How long would it last?

 

2 - I guess it would be possible to want to script an event where the AI is blinded only ( + the blind animation - a very powerful (maybe magical) light is activated, the player reflects the sun beam with a mirror right into the guards' eyes), but I dont know how to contribute to the code-related issue.

 

Maybe the deafness could have a falloff - deaf for a second or two, then able to tell which direction the player is coming from (still blind, can only turn), then back to nomal.

Link to comment
Share on other sites

1 - Does the sound deafness affects only AI that were "hit" by the bomb, or everyone inside a radius? How long would it last?

 

2 - I guess it would be possible to want to script an event where the AI is blinded only ( + the blind animation - a very powerful (maybe magical) light is activated, the player reflects the sun beam with a mirror right into the guards' eyes), but I dont know how to contribute to the code-related issue.

 

Maybe the deafness could have a falloff - deaf for a second or two, then able to tell which direction the player is coming from (still blind, can only turn), then back to nomal.

 

1. It works with the existing blind effect, so, it last the same amount of time, effects the same NPC's, etc,. (AKAIK)

 

2. Yeah, that's the concern, that it may cause confusion\issues, etc,. Need to see what the other devs think..

 

-----

 

I'm having issues after installing VS2012.

 

http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c

 

The easy fixes aren't working, so, I have to install\uninstall a bunch of runtimes, etc,..

Link to comment
Share on other sites

The point isn't that AI literally deafened by the flashbomb (they're not, since it doesn't make much noise). The point is that, being blinded, they should be momentarily distracted and not concentrating on listening to the player's footsteps.

 

I'd be fine with having the AI be completely deaf for the duration that they are blind, since we're only talking about five to ten seconds.

 

I implemented it into the AI blind state, which could be a problem, ie, if someone tried to use the blind state for any other purpose expecting only a blinding effect, etc,

 

I don't have a firm opinion on this.

Link to comment
Share on other sites

The point isn't that AI literally deafened by the flashbomb (they're not, since it doesn't make much noise). The point is that, being blinded, they should be momentarily distracted and not concentrating on listening to the player's footsteps.

 

I'd be fine with having the AI be completely deaf for the duration that they are blind, since we're only talking about five to ten seconds.

 

I see, I went with a 75% reduction so that you have a good chance of escape, but, could still be found if you were being too obvious.

 

I don't have a firm opinion on this.

 

Is this mechanism exposed to end users? That would be the primary concern, that it causes issues for end users trying to implement some custom effect in a level.

Edited by CodeMonkey
Link to comment
Share on other sites

2. I implemented it into the AI blind state, which could be a problem, ie, if someone tried to use the blind state for any other purpose expecting only a blinding effect, etc,. (So, is this a good place for it, or should a new state be created, can the game even support multiple AI states at once, etc,. ?)

 

If the "blinded by flashbomb" is its own state, then adding the deafness there is ok. If it is a general "I'm blind" state, then this isn't a good idea (we have f.i. AI that are forever blind, or maybe the mapper wants them to become blind after some event).

 

However, this can all be solved if the amount the hearing is reduced, as well as the time are in spawnargs read from the flashbomb entity. Then you can make different bombs and effects and the code just reads how long to reduce hearing by what amount.

 

Hard-coding such effects is generally a bad idea – because for the next effect you do it again and again and again. Unfortunately we do not yet have generic "effects" framework, where you could specify such things via rules and then have a generic engine execute the rules. That way no code changes would be require for this change at all.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

If the "blinded by flashbomb" is its own state, then adding the deafness there is ok. If it is a general "I'm blind" state, then this isn't a good idea (we have f.i. AI that are forever blind, or maybe the mapper wants them to become blind after some event).

 

However, this can all be solved if the amount the hearing is reduced, as well as the time are in spawnargs read from the flashbomb entity. Then you can make different bombs and effects and the code just reads how long to reduce hearing by what amount.

 

Hard-coding such effects is generally a bad idea – because for the next effect you do it again and again and again. Unfortunately we do not yet have generic "effects" framework, where you could specify such things via rules and then have a generic engine execute the rules. That way no code changes would be require for this change at all.

 

I'm still trying to repair the damage done by installing Visual Studio 2012... :(

 

Anyways, once I get this VS issue sorted, how would you like me to proceed?

 

I'm honestly not sure about the blind state, it "could" control blind NPC's, or it "could" just be for flashbombs, I don't know, that's why I asked, I hoped you guys would know. ?

 

So, I need an answer on that issue.

 

Assuming my patch does conflict with blind NPC's, do you want me to take the spawnargs route? (That would require .def edits too, correct?)

 

Personally, I would just allow for multiple AI states to be executed per NPC.

 

Obviously, this could cause problems if conflicting states are used, etc, and could reduce performance if too many are used, etc,.

 

Not sure if concurrency issues will pop up, etc, but overall, it seems workable.

 

Roughly:

 

class xxx
{
vector<AI_STATE> states;

for (states)
   states[i].Think();
}

// Very roughly...
if (Hit_By_Flashbomb)
{
  NPC.states.Add(Deaf); // Kept separate for versatility.
  NPC.states.Add(Blind); // Kept separate for versatility.
}

 

Then we could just create a new "Deaf" state, and add both "Blind\Deaf" states to the AI when a bomb is used. (This could already be possible, I'd have to really examine how the NPC use the AI states, etc, to know for sure.)

 

I just wanted to throw that out there, I'll implement it however you want. :)

 

Anyways, think about it, figure out if this is even necessary, and which route you want me to take, and I'll get it done. :D

 

----

 

Edit:

 

This VS issue is getting on my nerves, I uinstalled\reinstalled everything related to my dev environment(IDE, runtimes, libraries, everything...), but, for whatever reason, VS isn't installing the required header files, and libraries on a fresh install. (ie, the C++ standard libary literally isn't being installed..)

 

This guy had a similar experience with VS11.

 

http://blackhole12.blogspot.com/2012/03/visual-studio-broke-my-computer.html

Edited by CodeMonkey
Link to comment
Share on other sites

I can't speak about the code issues, but we don't use the blind state for anything else at the moment. There are other ways to accomplish a blind-but-can-hear AI as well, if a mapper decided they wanted that for something.

Link to comment
Share on other sites

It might not hurt. I might allow mappers an easier way to set up temporary blind & deaf states and then release them from those states, e.g., when you have AI waiting in the wings for some triggered events & you want them non-responsive until their cue. (A mute & immobile state would also be useful for that.) I'm not thinking it through very carefully though, how that would differ from the current way of doing it -- e.g., where the mapper just tweaks their acuity settings directly. That's worked ok so far.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

It might not hurt. I might allow mappers an easier way to set up temporary blind & deaf states and then release them from those states, e.g., when you have AI waiting in the wings for some triggered events & you want them non-responsive until their cue. (A mute & immobile state would also be useful for that.) I'm not thinking it through very carefully though, how that would differ from the current way of doing it -- e.g., where the mapper just tweaks their acuity settings directly. That's worked ok so far.

 

If you're referring to my idea, I have no idea how it stacks up to the current system. (I'm still learning what this game engine can do, and how it works, etc,.)

 

Really, the main idea of my suggestion is that you can chain simple effects to create more complex effects, so, basically it comes down to abstraction, rather than tacking the deaf code onto the blind code, and having spawnargs enable\disable\modify the effect, it would be it's own effect with parameters, ie, self contained.

 

It's really the same difference overall, but it seems cleaner to keep things simple\separate, plus it makes it much more reusable, ie, do you really want to remember to set the hearing parameters on the blind state? It even sounds confusing.

 

Anyways, you guys\gals have the final say, until I have better grasp of the game engine, I'm not capable of making such decisions. (Too much room for error, my idea sounds good, but could be redundant, or have unforseen consequences, etc,.)

 

-----

 

Btw, I think I finally fixed my VS install, I had to go through the registry and manuallly remove every reference to "Visual Studio", the down side being that the next time I reboot my PC, it may not start. (Obviously, deleting regisry entries without prejudice isn't a good idea, but, MS left me little choice since their uninstaller left traces that caused the reinstallation to not work properly.)

 

Hopefully, no damage was done to my Windows install, and I still have to try compiling to see if it actually works, but, the C++ standard library is present this time, so, that's promising. :P

 

---

 

Update: VS works again, I've compiled the .exe, and the .dll without issues, if I can reboot, and not end up locked out of Windows, I can call it a success. ;)

Edited by CodeMonkey
Link to comment
Share on other sites

So, I never heard back about OpenMP support?

 

I've been playing around with it myself, and have gained nearly 3-5fps on average, I'm running a stock Doom3.exe, I compiled the DLL using the SSE2 optimizations switch in the compiler, that aside I modified one file to use OpenMP, and that by itself seems to have been the cause of the large FPS boost I've seen.

 

At any rate, it proves my point about fixing some of their custom implementations, I modified idDict, and it seems to be the cause of considerable slowdowns during gameplay based on my findings.

Link to comment
Share on other sites

So, I never heard back about OpenMP support?

 

I'm not a coder, so I can't say yes or no to the concept but if it can improve performance then it's definitely worth looking into. Would probably be wise to create a test branch where all of the OpenMP changes could go and if it was stable, could be merged back into the trunk for 1.09 perhaps.

Link to comment
Share on other sites

I'm not a coder, so I can't say yes or no to the concept but if it can improve performance then it's definitely worth looking into. Would probably be wise to create a test branch where all of the OpenMP changes could go and if it was stable, could be merged back into the trunk for 1.09 perhaps.

 

The best approach would be to carefully pick out the most used, or most intensive code to implement it on, rather than trying to put it everywhere.

 

idDict, is a good example, it's used by many of the games systems, so, a few simple edits there, can affect large portions of the game, yet, it's easier to track changes here, than it would be if you were making thousands of broad changes to random code, etc,.

 

So, I don't think there will be too many problems, and the potential gains are amazing. (OpenMP let's you run ANY code you want across multiple cores on a CPU in parallel.)

 

Here's how easy it is to implement.

 

for (int i=0; i < 1000; i++)
{
// Do something..
}

 

That's an example of a normal "for" loop. (This code does not take advantage of multicore CPU's, it will run on a single core, regardless of how many you have.)

 

#pragma omp parallel for
for (int i=0; i < 1000; i++)
{
// Do something..
}

 

This is how you implement OpenMP support.

 

This code will now run much faster because it will be executed on multiple threads across mutliple cores on your CPU. (ie, a quad core might run this code 3-4 times faster since it's now being executed in parallel across all your cores.)

 

OpenMP automatically figures out how many threads to make, and how many cores you have, etc, so, the code will only get faster as more cores are added. (It doesn't hurt single core performance either, it simply executes the normal loop in that case.)

 

----

 

I should note, OpenMP has many directives for use in specific scenarios, but, most are just as easy to use as shown above.

 

Here's a guide I've been using.

http://bisqwit.iki.fi/story/howto/openmp/

Edited by CodeMonkey
Link to comment
Share on other sites

I think it's worth pursuing. Hopefully the others will drop in with their opinions soon.

 

MPI is another possibility, it's part of Boost, which is already being used by TDM, however, it looks a bit harder to use.

 

----

 

Anyways, I've got v1.08 compiling now, and I'm taking some time to see how it all works, there were a LOT of changes since v1.07.

 

As far as contributing goes, hopefully now that I have a newer version it will become a bit easier. (There weren't many issues related to v1.07 that I could just jump in on, most were too complex(AI, etc,), or required input from the team about design choices, etc,.)

 

I'd be better suited to fixing actual broken code logic, at least until I'm on the same page as everyone else. (Even then, it can be an issue.)

 

Here's an example:

 

There seems to be issues with controls, for example, holding the "toggle" button for the lantern causes it to repeatedly turn on\off. (That's just one example, there are many little control issues, I've gotten stuck in "crouch" mode, etc,.)

 

Part of the problem seems to stem from not having a fully integrated key state tracking mechanism.

 

In C#, I would do something like this.

 

Dictionary<key, bool> PreviousState;
Dictionary<key, bool> CurrentState;

void UpdateStates()
{
PreviousState = CurrentState;

// Check the current states
CurrentStates = some method of updating them. (Likely, iterating, and testing each key.)

// Example Update
foreach (Key k in BoundKeys)
	if (ReadRawState(k) == true) // Key down, tested with input API. (GetAsyncKeyState\DX\GL\Whatever.)
	   CurrentState[k] = true;
	else
	   CurrentState[k] = false;
}

// AKA: KeyDown
bool KeyPressed(Key k)
{
// If the key wasn't pressed in the last state, but is pressed now, it was just "pressed".
if (PreviousState[k] == false && CurrentState[k] == true)
	return true;
else
	return false;
}

bool KeyHeld(Key k)
{
// If the key was down in both states, it's being held.
if (PreviousState[k] == true && CurrentState[k] == true)
	return true;
else
	return false;
}

 

That's rough code off the top of my head, but, it shows a mechanism for more easily tracking key states.

 

As you can see, while fixing the control issue would be nice, my idea of fixing it, would require a massive change to how keys are handled, and could have negative effects on the project. (ie, I don't feel comfortable doing it, since I don't fully understand the ramifications of altering the current key handling mechanism.)

 

This would however make the bug with lantern\compass\spyglass toggles easy to fix.

 

if (KeyPressed(toggleKey))
  // Do action. (ie, toggle lantern\compass\spyglass, etc,.)

 

This code wouldn't allow the bug to occur, since the state tracking code can tell the difference between pressed, and held keys. :)

 

Edit: Speaking of broken code, why are the code tags ruining the tabbing on my code samples. ? (It's fine in the editor view.)

Edited by CodeMonkey
Link to comment
Share on other sites

I think I'll just go back to offering code that I think will be useful, you can use it at your discretion, modify it as needed, etc,.

 

Here is a SUPER generic class for handling input, it should work with about any code, if properly fitted. (You'll need to update it somehow, as shown in my last post.)

 

#include <map>

template <class T>
class InputManager
{
   public:

       // Previous State
       std::map<T, bool> PreviousState;

       // Current State
       std::map<T, bool> CurrentState;

       // Key Pressed
       bool KeyPressed(T key)
       {
           if (PreviousState.at(key) == false && CurrentState.at(key) == true)
               return true;
           else
               return false;
       }

       // Key Released
       bool KeyReleased(T key)
       {
           if (PreviousState.at(key) == true && CurrentState.at(key) == false)
               return true;
           else
               return false;
       }

       // Key Held
       bool KeyHeld(T key)
       {
           if (PreviousState.at(key) == true && CurrentState.at(key) == true)
               return true;
           else
               return false;
       }
};

 

Example Usage:

 

#include "InputManager.h"

int _tmain(int argc, _TCHAR* argv[])
{    
   InputManager<int> input;

   input.PreviousState[1] = false;
   input.CurrentState[1] = true;

   Print(input.KeyHeld(1));
   Print(input.KeyPressed(1));
   Print(input.KeyReleased(1));

   system("pause");
   return 0;
}

Edited by CodeMonkey
  • Like 1
Link to comment
Share on other sites

Well, I wouldn't give up on submitting specific things just yet. :) The coders here need to see that you can handle TDM bugs and specific tasks. I think once they see one or two things, we would likely then be happy to invite you onto the team as a coder with SVN access. Everyone has been working really hard to get 1.08 out the door, so don't think you're being ignored...it's just that nobody has really had the spare time to check things out.

Link to comment
Share on other sites

Well, I wouldn't give up on submitting specific things just yet. :) The coders here need to see that you can handle TDM bugs and specific tasks. I think once they see one or two things, we would likely then be happy to invite you onto the team as a coder with SVN access. Everyone has been working really hard to get 1.08 out the door, so don't think you're being ignored...it's just that nobody has really had the spare time to check things out.

 

Yeah, it's mainly a personal issue, nothing to do with the team, etc,.

 

I normally only do Windows programming, and rarely in C++, and, having to account for several builds, across several OS's, and compilers, etc, not to mention working with such a large unknown codebase(Read: I'm NOT very familiar with the game engine), is making it hard to find a place to contribute directly. :(

 

Anyways, the code above is pretty cool, it can be externally updated, and initialized, thus, no changes are really needed to the class itself, and you can retrofit it to work with about any system since it uses a generic type T, so, hopefully it can be useful in cutting down on the number of input related issues.

 

As for getting on the team, etc, we'll just have to see how it goes, either way works for me, I'm just trying to help out if I can. :D

Edited by CodeMonkey
Link to comment
Share on other sites

I find the multi-core optimizations you're talking about very exciting. If it can be done without hurting the stability of the game, even if only for a few portions of the engine...that would be quite a big help to our players who have multiple cores but are still getting sluggish performance.

  • Like 1
Link to comment
Share on other sites

Multicore 'optimizations' can actually slow things down

 

trololololol.

 

It depends if a method is hot and for how long it is hot and if the data has no 'previous data dependencies' and if it doesn't take longer to 'join it up' for a usable state than doing it in one core. In games it's very hard to do without changing algorithms (or in general) because the hot areas are only hot for very small amounts of time/small amounts of data and cache locality is vastly more important.

 

But wtf i know, knock yourself out. Just remember to profile the same thing before and after.

Edited by i30817
Link to comment
Share on other sites

Multicore 'optimizations' can actually slow things down

 

trololololol.

 

It depends if a method is hot and for how long it is hot and if the data has no 'previous data dependencies' and if it doesn't take longer to 'join it up' for a usable state than doing it in one core. In games it's very hard to do without changing algorithms (or in general) because the hot areas are only hot for very small amounts of time/small amounts of data and cache locality is vastly more important.

 

But wtf i know, knock yourself out. Just remember to profile the same thing before and after.

 

Don't be that guy....

 

------

 

Parallelism has been used in many games, and applications with great success, it's all about implementation, and code design, etc,.

 

Anyways, if you have any real knowledge of parallel programming, feel free to contribute that knowledge to the project in a more beneficial way than, meh, it probably won't work. ;)

Link to comment
Share on other sites

I too was idealistic once, but it was about superior data structures instead of parallelism.

O(1) retrieval of a map, always better than linear searching in a array for any data right?

 

Wrong. The data is fucking tiny and it being in cache is more important. Etc.

 

 

Ok, maybe it's possible for the level load process if it is doing some post processing. Maybe not, since the bottleneck there is probably disc access which can't be 'partitioned' unless you use RAID.

Edited by i30817
Link to comment
Share on other sites

I too was idealistic once,

 

The most intensive programs in the world are scientific, and they rely on multiple CPU's, multiple cores, and GPU stream processors, etc,.

 

but it was about superior data structures instead of parallelism.

O(1) retrieval of a map, always better than linear searching in a array for any data right?

 

Wrong. The data is fucking tiny and it being in cache is more important. Etc.

 

What does any of that have to do with parallel processing?

Link to comment
Share on other sites

So, I never heard back about OpenMP support?

 

I've been playing around with it myself, and have gained nearly 3-5fps on average, I'm running a stock Doom3.exe, I compiled the DLL using the SSE2 optimizations switch in the compiler, that aside I modified one file to use OpenMP, and that by itself seems to have been the cause of the large FPS boost I've seen.

 

At any rate, it proves my point about fixing some of their custom implementations, I modified idDict, and it seems to be the cause of considerable slowdowns during gameplay based on my findings.

 

Could you please post that patch somewhere for review? Sounds something we like to add.

 

I'd also like to add that I'm not ignoring you, just that with v1.08 and a lot of real-life issue there was basically no time for me to respond to you. Sorry about that.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

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

    • 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
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...