Jump to content
The Dark Mod Forums

Things that could be improved


Berny

Recommended Posts

On 4/25/2022 at 1:22 AM, thebigh said:

One cool effect I'd like to see is a key ring. No more cycling through numerous keys in your inventory, keys you grab go on the key ring which then opens any door to which you have the right key.

On 4/27/2022 at 9:38 AM, OrbWeaver said:

Not just a cosmetic issue in fact — it would be better gameplay for a guard to stop and enter a "Huh?" state for a couple of seconds, giving the player a cue that he had been spotted and giving time to run away, rather than have the guard act as if nothing was wrong and then suddenly enter a combat state.

Perhaps this could be solved fairly straightforwardly by setting different delays for the various levels of state transitions. I.e. transition from 0 (unalerted) to 1 (huh?) could be instant, but the further transition from 1 to 2 or more (actual attack) could be significantly longer.

Mappers can manipulate the levels at which state changes happens as well as the ai's acuity in regards to visual, acustic and tactile stims. And this is the case since I joined the forum over ten years ago. Obviously, different mission require different setups due to the differences in geometry, average distance and lighting etc... to work optimal, but unfortunately most - if not all - mappers don't bother with this 'technical' stuff.

On 5/9/2022 at 11:46 PM, datiswous said:

Putting the dds folder in the root tdm folder does it, so you have the same folder structure as in the pk4, you don't need the other extracted files and folders though. You don't have to repack it. Be aware that if tdm updates the file in a future update, you won't notice it because you're overruling it. Therefore it's important to remove all the files and folders that you don't want to override from the dds folder.

To sum it up:

  1. extract the dds folder from tdm_gui01.pk4 and put that folder in the tdm-root
  2. remove everything that you don't want to override from that folder.
    So in this case keep /guis/assets/objectives/parchment_ingame.dds (including that folder structure)

I'm not an expert and there might be a better way, but this seems to work.

Might be something for a plugin, to darken all readable assets in all missions.

 

An easier way would probably be to alter the gui files. Images can be toned down there and the toning factor could be a variable, so it could be turned into a setting adjustable via the options menu. It would also allow to alter the factor based  on the lightgem value so that the readables are brighter if the player is in a well lit area and darker if he is standing in the shadows (which sounds kinda cool now that I think about it).

  • Like 1
  • Thanks 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@datiswous

It's a dirty hack, to be honest, as it was just a proof of concept. Basically there are two things going on.

1. An infinite loop, that takes care of clearing the inventory if the player is not looking at a door.

2. An alternative version of the frob action script on the door that takes care of finding the correct key in the players inventory and switching to the lockpick, if the correct key is not in the players possesion.

As stated in the video this setup works with one lockpick. But due to the minigame in TDM having several picks is nonsense either way and only present as it was like that in the original games.

These are the scripts (this stuff is actually still lying around on my harddrive :D:

1. Inventory clearance (switching away from the lockpicks (this is to disguise them in the inventory, as the player doesn't have to use them actively)

void test()
{
	while(1)
	{
		
		if ($player1.getImmobilization("")!=2048 && $player1.getCurInvItemEntity().getName()=="lockpick")
		{
			$player1.getNextInvItem();
		}
		
		
		sys.waitFrame();
	}
}

Immobilizations are set by the game if the player is doing something specific, normally to somewhat restrict his moving capabilities (e.g. making him slower). From player.h

// Player control immobilization categories.
enum {
	EIM_ALL					= -1,
	EIM_UPDATE				= BIT( 0),	// For internal use only. True if immobilization needs to be recalculated.
	EIM_VIEW_ANGLE			= BIT( 1),	// Looking around
	EIM_MOVEMENT			= BIT( 2),	// Forwards/backwards, strafing and swimming.
	EIM_CROUCH				= BIT( 3),	// Crouching.
	EIM_CROUCH_HOLD			= BIT( 4),	// Prevent changes to crouching state. (NYI)
	EIM_JUMP				= BIT( 5),	// Jumping.
	EIM_MANTLE				= BIT( 6),	// Mantling (excluding jumping)
	EIM_CLIMB				= BIT( 7),	// Climbing ladders, ropes and mantling.
	EIM_FROB				= BIT( 8),	// Frobbing.
	EIM_FROB_HILIGHT		= BIT( 9),	// Frobbing AND frob hilighting (not sure if needed or if EIM_FROB can disable hilight also)
	EIM_FROB_COMPLEX		= BIT(10),	// Frobbing of "complex" items (not a door, lever, button, etc)
	EIM_ATTACK				= BIT(11),	// Using weapons 
	EIM_ATTACK_RANGED		= BIT(12),	// Using ranged weapons (bows)
	EIM_WEAPON_SELECT		= BIT(13),	// Selecting weapons.
	EIM_ITEM_USE			= BIT(14),	// Using items
	EIM_ITEM_SELECT			= BIT(15),	// Selecting items.
	EIM_ITEM_DROP			= BIT(16),	// Dropping inventory items.
	EIM_LEAN				= BIT(17),  // Leaning
};

Dunno if the numbering has changed or the logic is a bit different, but immobilization 2048 refers to one of the frobs (but it is two to the power of eleven, so I am a bit confused here, one would have to test if it is still valid).

 

 

The frob_action_script on the door (you have to set that via the respective spawnarg):

void advancedDoorFrob(entity door)
{
	if (door.IsLocked()) 
	{
		$player1.setCurInvCategory("#str_02392");
		$player1.setCurInvItem(door.getKey("used_by"));
		sys.waitFrame();
		entity key=$player1.getCurInvItemEntity();
		if(key==$null_entity)
		{
			$player1.setCurInvCategory("#str_02389");
			$player1.setCurInvItem("lockpick");
		}
		else
		{
			door.ToggleLock();
		}
	}
	else
	{
		door.ToggleOpen();
	}
}

The code basically switches the inventory item to the key used by the door currently frobbed. If such a key isn't present in the players inventory, no item will be selected (aka null_entity) and we switch to the lockpick. Otherwise the door will be unlocked. This only happens if the door is still locked, though, otherwise it just gets opened/closed.

 

In all honesty, I would prefer a different implementation nowadays, but this gives you an impression of how this can be set up.

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

6 minutes ago, wesp5 said:

Is this something that could be added to the core game?

Why not simply share scripts and entity definitions amongst those who want it? I don't mind switching between keys. It makes me aware of what room I'm opening the door to. Lockpick switching gets tiresome, but having three levels of locks (triangle, snake, and both) is still realistic, so you don't have to make every lock a triangle-snake-triangle combo as a mapper.

I'm also sure that you can facilitate key management, by simply scripting to remove a key which has opened all the doors it can open in a map. Again, that's up to a mapper to program.

Edited by Nort
Link to comment
Share on other sites

53 minutes ago, wesp5 said:

Is this something that could be added to the core game?

This has been discussed back then (note that the tdm version used in the video is 2.01, the video is 8 years old).

 

The conclusion was that the majority of the users share the opinion expressed by @Nort. Mappers are obviously free to use such setups in there fms. Also, it's mostly been common to not add features for the feature's sake.

 

And this isn't something that is better per se. In some type of missions having to search for the correct key might even improve gameplay (horror missions for instance).

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Different clothes sets, Outdoor coats / Cloaks & capes; for Outdoorsy use? Also - rough fur coats or thick burlap type garments for the lower classes...(guards / watchmen with thick cloaks?) It rains & snows sometimes right?

Its just a few palette swaps on a texture - tweak away 😉

 

Also - on the topic of too much sameness; extra voice sets for civilians? Seems like its 1:1 - for most of them, with few variants elsewhere too.

 

And: Automatic door closers - Everywhere!? shouldn't this be quite uncommon in the setting, only on say kitchen / mansion doors? some half-rotten wood shack in the depths of a forgotten forest, would be fortunate to even have a working door...

Link to comment
Share on other sites

32 minutes ago, Melchior said:

Different clothes sets, Outdoor coats / Cloaks & capes; for Outdoorsy use? Also - rough fur coats or thick burlap type garments for the lower classes...(guards / watchmen with thick cloaks?) It rains & snows sometimes right?

Its just a few palette swaps on a texture - tweak away 😉

 

Also - on the topic of too much sameness; extra voice sets for civilians? Seems like its 1:1 - for most of them, with few variants elsewhere too.

 

And: Automatic door closers - Everywhere!? shouldn't this be quite uncommon in the setting, only on say kitchen / mansion doors? some half-rotten wood shack in the depths of a forgotten forest, would be fortunate to even have a working door...

 

Everything you suggested is doable, it just needs someone or a group of people, to make the resources (textures, sounds, scripts etc)

So as you posted, "It's just a few palette swaps on a texture - tweak away"
Yes, please do. Use your favourite image editing program, open the texture files and make something. The UV maps are already made, you can make a copy of a garment texture and modify it to your hearts content.

https://wiki.thedarkmod.com/index.php?title=Textures

 

It seems strange that people continue to request things like this, like this is a pro dev house with paid employees. No one here gets paid to make stuff, it's done on a personal basis of wanting to contribute. So sometimes, people spend days and weeks and months working on something, like vocal sets and get burned out and have 0 interest in making more.
 

So if you have some recording equipment, record something and submit it to the team for evaluation for inclusion.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

8 hours ago, Melchior said:

And: Automatic door closers - Everywhere!? shouldn't this be quite uncommon in the setting, only on say kitchen / mansion doors? some half-rotten wood shack in the depths of a forgotten forest, would be fortunate to even have a working door...

This is a mapper decision. By default, doors do not close automatically. However, it is possible to set the to do so and normally used in haunted mission (because it is spooky 😬)

For the rest, like @AluminumHaste said. If it is easy, why don't you do it yourself. If you can't do it yourself, it maybe isn't that easy ;)

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

43 minutes ago, Obsttorte said:

This is a mapper decision. By default, doors do not close automatically. However, it is possible to set the to do so and normally used in haunted mission (because it is spooky 😬)

For the rest, like @AluminumHaste said. If it is easy, why don't you do it yourself. If you can't do it yourself, it maybe isn't that easy ;)

I assume that they close to activate visportals, to provide you with good framerates. I could just assume that some citizen saw the door was opened and closed it, while you weren't looking.

Link to comment
Share on other sites

On 6/3/2022 at 8:18 AM, Obsttorte said:

In all honesty, I would prefer a different implementation nowadays,

My own Idea is that there is a running script in the background with a variable with a number in it. Every key that you pickup runs a function that ads a number to the variable. Every number total will unluck a specific amount of doors (with the keychain). So for example key 1 and 3 have numbers 22 and 47, which together gives 69. Nr. 69 opens 2 (or more) specific doors. Maybe it's possible to add numbers to a vector and then check if the number excist in the vector? The key will not be added to the inventory as an item, you just have one keychain (not shure if that's possible, but I think so). Anyway, something else to tinker with..

Link to comment
Share on other sites

26 minutes ago, datiswous said:

My own Idea is that there is a running script in the background with a variable with a number in it. Every key that you pickup runs a function that ads a number to the variable. Every number total will unluck a specific amount of doors (with the keychain). So for example key 1 and 3 have numbers 22 and 47, which together gives 69. Nr. 69 opens 2 (or more) specific doors. Maybe it's possible to add numbers to a vector and then check if the number excist in the vector? The key will not be added to the inventory as an item, you just have one keychain (not shure if that's possible, but I think so). Anyway, something else to tinker with..

Unless you are completely revolutionizing game systems right now, are you talking about every key being a flag bit in for example a byte? I don't think it would be good programming to add it as just a fixed byte length, and I think it's probably added as a "Does the player have it?" flag in some regard already. All the keychain needs to do, is manage those flags, and I think that's best left up to a core programmer, but I guess you could probably make a script if you knew how many key you have in a level. At least that's how I imagine things to work in this engine.

Link to comment
Share on other sites

2 hours ago, Nort said:

and I think it's probably added as a "Does the player have it?" flag in some regard already. All the keychain needs to do, is manage those flags

Ah right. I read here: https://wiki.thedarkmod.com/index.php?title=Inventory  that you can make an inventory item stackable ( inv_stackable ) and then there's inv_item_id which can be set to every seperate key (?), so then you don't really need a script.. Or maybe it's not that simple..

Edit: Acording to https://wiki.thedarkmod.com/index.php?title=Doors#Keys doors use the key-name instead of the inv_item_id

Well I guess maybe on key pickup a script could run that checks if inv_item_id of the picked up key is a certain nr. (or string) certain doors will be unlockable by the key-stack.

Edited by datiswous
Link to comment
Share on other sites

@datiswousTwo thoughts (or cents, so to say):

As @Nort stated, the usual approach is to use bits if it is just about whether a key is present or not. So each key would be represented by a power of two. I don't really see why the player should be able to open door 69, just because he can unlock 22 and 47 (as in your example, which I probably misunderstood).

The reason for the bit approach are to not waste unnecessary resources. The downside is, that it is a bit abstract. And as this will not hurt performance a lot, the bit approach is not necessary here, though.

Stackable items are items like flashbombs. Note, that even though there appear to be several entities in the inventory, it is actually only one. Using it, will decrement the counter, and if it reaches zero, the item gets removed. You can obviously not differentiate between objects if it only one.

 

Now, how will one go about this?! The most straightforward approach is, that if the player frobs a key, it gets removed (not added to inventory!) and a spawnarg is set on the world entity, denoting that the player has the key. Note, that if you readout a spawnarg on an entity that has not been set, it will return 0. So we just add something like "name_of_key" "1" to the world entity. If the player frobs a door, the modified version of the script will readout that spawnarg which is either 0, if it hasn't been set as the player hasn't picked up the key yet, and the door stays locked, or 1, which will lead to the door beeing unlocked.

 

So basically two script functions:

// the frobaction script used by our keys
void frob_key(entity key)
{
	string name_of_key = key.getKey("inv_name");
	$world.setKey(name_of_key, "1");
	key.remove();
}
// door script
void advanced_frob(entity door)
{
	if (door.Locked())
    {
      float unlocking_key = door.getFloatKey("used_by");
      if (unlocking_key)
      {
        door.ToggleLock();
      }
    }
  	else
    {
      door.ToggleOpen();
    }
}

This is without the lockpicking mechanism. I would have to check, whether the immobilization is still correct (as stated above, the number confuses me). Note that this is untested code that came to my mind. It probably includes wrong written stuff and has the potential to destroy the universe. Use with caution :)

  • Thanks 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

1 hour ago, Obsttorte said:

Stackable items are items like flashbombs. Note, that even though there appear to be several entities in the inventory, it is actually only one. Using it, will decrement the counter, and if it reaches zero, the item gets removed. You can obviously not differentiate between objects if it only one.

The interesting fact is that whenever you pick up an item (even loot), the entity is only hidden and remains in the world, while incrementing a counter in your inventory signifying that you're considered as possessing such an item. You could probably check whether an item is hidden to determine whether the player has taken it.

The pitfall is probably when dropping stackable items, since I believe items lose their identity when they're stacked, so when you drop items from a stack new entities are spawned.

Well, what we really could use is a robust, in-engine way of determining whether the player has an item in his inventory. You can currently only check the current inventory item of the player.

  • Like 1
Link to comment
Share on other sites

@Dragofer: I don't really see the issue here, actually. As mentioned above, if you really need to know whether the player has an item, you can either setup the item so that it leaves a note (what I suggested with the world entity) or use the objectives system. But the first approach is already pretty straightforward.

 

What are you looking for that cannot be achieved with the suggested method.

7 hours ago, Dragofer said:

The interesting fact is that whenever you pick up an item (even loot), the entity is only hidden and remains in the world

That is probably necessary for the ai to be able to detect whether something has been stolen. In addition, entities that appear the same to the player doesn't have to be coding-wise. The flashbomb lying around for you to pickup, the one(s) in your inventory and the one that you throw to blind your foes appear all the same to the players, as they would be in the real world, but from a programmers perspective they aren't.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

13 hours ago, Obsttorte said:

As @Nort stated, the usual approach is to use bits if it is just about whether a key is present or not. So each key would be represented by a power of two. I don't really see why the player should be able to open door 69, just because he can unlock 22 and 47 (as in your example, which I probably misunderstood).

I don't understand the part about bits and byte flags, so I ignored that. I also had to look up the power of two aspect. Aperarently one needs to know mathematics to understand basic (C) scripting. The idea that I wrote about is loosely based on programming/scripting understanding, but I don't really know much about it and therefore it is mostly conceptual.
I thought it was best to write it down anyway so that others can correct me and we all can possibly learn something (which might have happened).

The idea is that the key nrs 22 and 47 give number 69, where an if statement would check if number of (keyring)variable = 69 and then a definded amount of doors can be unlocked by the keyring. But it was an earlier idea and possibly bokers.

(I definitely have to read some more on scripting)

Anyway, thanks for the info so far.

Edited by datiswous
typo
Link to comment
Share on other sites

16 minutes ago, datiswous said:

I don't understand the part about bits and byte flags, so I ignored that. I also had to look up the power of two aspect. Aperarently one needs to know mathematics to understand basic (C) scripting. The idea that I wrote about is loosely based on programming/scripting understanding, but I don't really know much about it and therefore it is mostly conceptual.
I thought it was best to write it down anyway so that others can correct me and we all can possibly learn something (which might have happened).

The idea is that the key nrs 22 and 47 give number 69, where an if statement would check if number of variable = 69 and then a definded amound of doors can be unlocked by the keyring. But it was an earlier idea and possibly bokers.

Anyway, thanks for the info so far.

Okay, I think that you're describing bit flags. They work like this:

Imagine that you straighten out that keyring into a line of keys, which has either been obtained, or not. We can number the keys 1-8 and formulate it into a simple question: "Has each key been obtained?" Then the keyring could look something like this:

1 2 3 4 5 6 7 8
Y Y N Y N Y N

A single state of a key, as either retrieved or not - "Y(es)" or "N(o)" - is typically expressed as "True" or "False", in numerical form "1" or "0". This means that stored on a computer, the key would actually be this:

1 1 0 1 0 1 0

This is itself a number: 1101010. However, the computer stores numbers in a binary format, which means that instead of each number to the left of the first, being worth ten times more, it's only worth twice of that value. This gives us a numeral system which is concise and efficient. In it, the rightmost state is worth 0 or 1, the next state is worth 0 or 2, the next state is worth 0 or 4, and the next state is worth 0 or 8. We can then add up all of these numbers together, to get a human decimal value. In the keyring above, we'd get 1+1+0+1+0+1+0 = 64+32+0+8+0+2+0 = 106

 

Edited by Nort
Link to comment
Share on other sites

The bits are the digits and the byte the whole number (a bit simplified). It basically means that you use a number of which each digit represents a specific state. Similar to how they work in everyday life, where each digit corresponds to the amount of different numbers (ones, tens, houndreds, ...), just that now they stand for different keys. But as stated this level of abstraction is not needed here.

10 hours ago, datiswous said:

Aperarently one needs to know mathematics to understand basic (C) scripting.

Yes, but it is mostly 6 grade maths :)

10 hours ago, datiswous said:

But it was an earlier idea and possibly bokers.

I dunno if it is bokers, as it depends on what you are trying to achieve. I think I just don't understood exactly that. My interpretation of what you have written was that one key (22) opens door A, the other (47) door B, but having both (69) also allows to open door C. The last part doesn't make sense to me, so you probably meant it differently.

 

Just for learning sake as you implied: The bit approach would be like one key is 10, the other is 100. Having both corresponds to 110. But it also works the other way round, as there is no other combination of keys that lead to that number. Or more in detail: Say you have 4 keys.

  • key 1 corresponds to 1
  • key 2 corr. to 10
  • key 3 corr. to 100
  • key 4 corr. to 1000

So depending on which digits are nonzero, you can exactly say which keys the player possesses. Is the number 1011? Then he has key 1, 2 and 4.

The power of two stuff comes into play as computers use binary numbers, not bundles of tens. The math is the same, though. The number bundled is completely free to choose, has not always been ten in the past (just think of the clock or the names of the numbers) and is only ten nowadays because we have ten fingers. :)

Edited by Obsttorte
Typo, see @datiswous post below.
  • Thanks 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

18 minutes ago, Obsttorte said:

Or more in detail: Say you have 4 keys.

  • key 1 corresponds to 1
  • key 2 corr. to 10
  • key 3 corr. to 100
  • key 4 corr. to 1000

So depending on which digits are nonzero, you can exactly say which keys the player possesses. Is the number 1011? Then he has key 1, 2 and 3.

You mean 1,2 and 4 right? 😉

But yeah that's what I meant actually, but I gave a really bad example (maybe I even confused myself). But the bit approach does make it more clear.

Link to comment
Share on other sites

2 minutes ago, datiswous said:

You mean 1,2 and 4 right? 😉

Yes, he meant 1, 2 and 4.

In programming, "vectors" are sets of values, yes, but typically numerical values describing different concepts, like for example a 3D vector is typically a group of X, Y and Z positions. In physics, a vector instead describes the X, Y, Z direction of a force. Bits and bytes are much more basic than that, and are handled much, much differently than vectors are.

Link to comment
Share on other sites

@datiswous: Argh, typo. I was in a hurry. Corrected.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

More suggestions:

1) Make the mission completed marker more visible. The little green tick that's currently used is barely visible.

2) An option to disable or lower the volume of the mission complete jingle. It's blaring and loud and and a poor way to end what may have been an hour of gameplay in near silence.

Link to comment
Share on other sites

The comment about the mission complete marker (to be honest, I've no problem with it) reminds me of something I would like, which is some way of marking my missions with a personal rating, something like a number between 0 and 5 that I could filter on if I come back and want to revisit.  For me 0 would mean "don't play this, you hated every minute", 1 is "really didn't like this very much", 2 is "meh, some elements of interest", 3 is "pretty average", 4 is "that was decent", and of course 5 for all those superb missions out there (Iris, Requiem, In the North (maybe a 4.5 for me), etc).

Am afraid there are missions where I start it and think "nope, not for me"; it'd be nice to mark this in the mission list (with a red cross maybe).  So many missions now, and some I haven't played for so many years, it's hard to keep track.

Link to comment
Share on other sites

10 minutes ago, Araneidae said:

Am afraid there are missions where I start it and think "nope, not for me"; it'd be nice to mark this in the mission list (with a red cross maybe).  So many missions now, and some I haven't played for so many years, it's hard to keep track.

There is a simple hack you can do to filter missions, just go into the fms folder and create a new folder called "great missions" or "missions to try later" and just drop missions into it. This will prevent them from appearing on the mission select list.

 

Edited by Wallace
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

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

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...