Jump to content
The Dark Mod Forums

Noob modeling/texturing thread


Maximius

Recommended Posts

  • Replies 234
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

You should post a link to that page. I have a fast connection at home but sometimes I gotta use this painfully slow connection.

I looked at the models page on Wiki but didn't see any 'ase scripting' page so not sure what you are looking at.

 

You only need to script objects if you want them to do something, like rotating gears.

 

There are some material lines I know of for issuing normal map commands on your models thru Doom, not sure if that's what you mean.

 

 

http://www.doom3world.org/phpbb2/viewtopic.php?t=9275

 

this link is included under the basic modeling tutorial, the one with the simple cube model that is not textured yet.

 

if the .ASE exporter is a discrete piece of software, perhaps someone could point the way to it?

Edited by Maximius
Link to comment
Share on other sites

Now I see what you are saying. I don't know as I don't use Blender, I'm sure if you post at D3W someone will let you know.

 

Most likely though you do copy/paste it and put in scripts folder. Then possible you just export and there will be .ase in your menu.

 

Let us know if you get it working and it'll get added to Wiki.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Now I see what you are saying. I don't know as I don't use Blender, I'm sure if you post at D3W someone will let you know.

 

Most likely though you do copy/paste it and put in scripts folder. Then possible you just export and there will be .ase in your menu.

 

Let us know if you get it working and it'll get added to Wiki.

 

 

Ill try my Blender.org account first then D3w. In the interim I'm going to bang out some models, I have a four test tube set with a rack at around 300 faces. This can probably be reduced as well.

Link to comment
Share on other sites

Ah yeah, katbits. They got some nice tutorials there too... Anyway I browsed a little for you and those exporters are phyton scripts (.py) and have to be put into a certain directory in order to register with blender.

 

Registering scripts:

To be registered a script needs two things:

to be either in the default scripts directory or in the user defined scripts path (see User Preferences window -> File Paths tab -> Python path);

to have a proper header.

 

Try 'blender -d' to know where your default directory for scripts is, it will inform either the directory or the file with that info already parsed, which is in the same directory of the scripts folder.

The header should be like this one (all double and single apostrophes below are required):

#!BPY

 

# """

# Name: 'Script Name'

# Blender: 233

# Group: 'Export'

# Submenu: 'All' all

# Submenu: 'Selected' sel

# Submenu: 'Configure (gui)' gui

# Tooltip: 'Export to some format.'

# """

where:

Name is the string that will appear in the menu;

Blender is the minimum program version required to run the script;

Group defines where the script will be put, see all groups in the Scripts Window's header, menu "Scripts";

Submenu adds optional submenus for further control;

Tooltip is the (short) tooltip string for the menu entry.

note:

all double and single apostrophes above are required;

you can "comment out" the header above, by starting lines with '#', like we did. This is not required (except for the first line, #!BPY, of course), but this way the header won't conflict with Python tools that you can use to generate documentation for your script code. Just remember to keep this header above any other line with triple double-quotes (""") in your script.

 

Submenu lines are not required, use them if you want to provide extra options. To see which submenu the user chose, check the "__script__" dictionary in your code: __script__['arg'] has the defined keyword (the word after the submenu string name: all, sel or gui in the example above) of the chosen submenu. For example, if the user clicked on submenu 'Selected' above, __script__['arg'] will be "sel".

If your script requires extra data or configuration files, there is a special folder where they can be saved: see 'datadir' in Blender.Get.

Link to comment
Share on other sites

phyton scripts

Python scripts. Spell it with me: P-Y-T-H-O-N. ;)

 

Sorry, but that typo is really starting to get on my nerves. :)

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

Well, since both versions exist only with different meanings (the snake and the general term for plants) it's not really a typo, just a question of what the name for the scripts came from. But then again in "phytoplankton" the "n" is missing, damn it! :D

 

But I am no native english speaker anyway, so minor typos like that could well be tolerated, like we germans (and everyone else) have to do too in our every day life, all in favor of the saying/"common signature": If you find a typo, you can keep it!! ;)

Link to comment
Share on other sites

Well, since both versions exist only with different meanings (the snake and the general term for plants) it's not really a typo, just a question of what the name for the scripts came from.

 

It's from Monty Python.

 

http://www.python.org/doc/faq/general/#why...t-called-python

Link to comment
Share on other sites

It is a typo, because it's not the correct name.

 

I tried to ignore it... honestly I did... and I succeeded for a long time, after many many references to "Phyton". It's just that when you're telling other people who don't know any better that "it's a phyton script"... well, that annoys me. ^_^ People spreading incorrect information is one of my pet peeves.

 

I know you're not a native English speaker as such, but your written English is very good. Good enough that this mistake sticks out at me like a sore thumb.

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

Here are instructions for installing the script, thanks to ratty redemtion at d3w:

 

"copy and paste the code into a new .txt file and rename the .txt extension to .py then save that inside the .blender/scripts folder, it should then show up in blenders file menu/export next time blender is run."

 

I have to figure out what version of Blender I'm running too, that katbits page, which belongs to ratty, has versions for older Blender installs.

Edited by Maximius
Link to comment
Share on other sites

It is a typo, because it's not the correct name.

 

I tried to ignore it... honestly I did... and I succeeded for a long time, after many many references to "Phyton". It's just that when you're telling other people who don't know any better that "it's a phyton script"... well, that annoys me. ^_^ People spreading incorrect information is one of my pet peeves.

 

I know you're not a native English speaker as such, but your written English is very good. Good enough that this mistake sticks out at me like a sore thumb.

Yeah, I can accept that and thanks... ;) I actually know nothing about Python, I just noticed that no one had helped Maximus and so I browsed the blender page for instructions on installing those scripts.

 

I recently tried the technique to create a normalmap from real surfaces, by taking pictures of them while enlightening them from all four sides, one at a time. My example surface is an emblem on one of my cabinets and the result is very satisfying in my oppinion (not perfect tho), so I recorded a little video in case anyone of you is interested... Click me!! :)

 

(I just recorded it in the crazybump preview with parallax deactivated, because I don't know how to script moving lights in doom 3 yet and I also didn't want to make such a fuzz for nothing... ;) )

Edited by STiFU
Link to comment
Share on other sites

I'm trying to open the .ASE exporter in BLender, but I have to save the text file as a .py insteaed of a .txt. How can I go about doing this? The .py suffix is not available under the field "save as file type"

 

You could try to save it as ".txt" and then rename the file, would that work?

"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

What program are you using to save the text file? If it's Notepad, or any other app that uses the standard Windows save dialog, just write the filename enclosed in double quotes, like so: "aseexport.py" (including the quotes). That will override the .txt extension.

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

What program are you using to save the text file? If it's Notepad, or any other app that uses the standard Windows save dialog, just write the filename enclosed in double quotes, like so: "aseexport.py" (including the quotes). That will override the .txt extension.

 

THanks for the info guys. Crispy I think thats the answer,Ill try it now. Here are a few new models I've come up with.

 

Some basic bottles, each about 130:

 

http://aycu12.webshots.com/image/41371/200...10119637_rs.jpg

 

Cooking pan set, not optimized and w/ errors

 

http://aycu20.webshots.com/image/42059/200...53391471_rs.jpg

 

Test tube set 350 polys

 

http://aycu25.webshots.com/image/41184/200...33780028_rs.jpg

 

Mortar and pestles sets, 275 apiece. The interesting thing here is that they are all variations on the same basic design, as are the bottles above. It seems pretty easy to generate some variety with simple models like these, first I try to find a pretty low poly design that looks ok and then just tweak out four or so variations of it. That way your numbers stay consistent too instead of adding polys to add diversity.

 

http://aycu01.webshots.com/image/41680/200...16912859_rs.jpg

 

http://aycu36.webshots.com/image/39355/200...76321956_rs.jpg

 

I did the pots along the same lines but with the intention of keeping them looking alike, as if they were a set.

I need to iron out the kinks though.

Link to comment
Share on other sites

THanks for the info guys. Crispy I think thats the answer,Ill try it now. Here are a few new models I've come up with.

 

Cool. I guess the textures and normal maps make them appear much rounder in game.

 

Btw, please remember that if you do make models, that they are a integer number of units heigh and that the origin is also an integer number of units from the bottom (while still near the center).

 

Technically, you could make f.i. 3 units from bottom to origin, and 3.25 from origin to top, but maybe its better to keep things symetrical.

 

This arrangement makes placing the items in the editor without floating or clipping much easier.

 

(Although it limits the number of different sizes a bit. If things look all o same-sized, using half units for the top part would be a comprimise. But this makes CMs more complicated, and doing thigs like balancing a plank on two wine bottles more complicate, too.)

 

Sorry if you already know this :)

"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

Sorry Tels, I disagree with alot of your post.

I don't think we need to get too anal about every model having its top and bottom on the grid. Grid alignment is important and something to consider but there is leeway IMO.

 

Collision models are NOT more complicated if the top and bottom of an object aren't grid snapped. A plank will not balance on 2 bottles either realistically .Planks can be rotated with the rotate tool to 'balance' on two different height bottles.

 

The important things are:

All objects should have their bottoms on a grid line. It will be very common for objects to be placed right side up and quickly.

The larger the grid line the better. But this has to do also with origins (see below)

 

Other objects like tables should have their top also on a grid line. This is so the bottom of bottles, ect... will align with them and not float or clip. Large things like tables should stick to a fairly large grid size so easy of placement.

 

Objects like tables can have their origins at the bottom/floor level. It doesn't really matter because they won't be moveable. origins are centered for frobbing and moving/throwing...

 

Objects that will be moveable : chairs, bottles, small vases (I say this 'cause we have 10 foot tall vases too), goblets, ect... should have their origins as "close to center as possible". This makes frobbing easier as the player aims at the center of the object.

There is alot of leeway here to, you have to think about the object and not only its center but its "center of mass"

My trophy object has a really skinny bottom and a really fat top. The middle is right in between and might be hard to frob with the origin centered because there is not much width there. So I went more with center of mass and moved the origin up into the fatter part where the player is more likely to focus their frob. If thrown it is more realistic also that an object will rotate more around its center of mass rather than it's actual center.

The bottom should still be on the grid lines but the top really doesn't matter. If someone wants to balance a plank on it, or balance it upside down they can decrease the grid to a very small size and do a more exact placement.

The point is to make standard placement easy but not to try and guess every possible scenerio that some author might choose to place the object.

 

The collision model is based around the objects shape/position. If the top of the object is off grid then the top of collision model is off grid. No biggie. The important thing is that the collision model is simple enough to work, but complicated enough to simulate the shape of the object as close as possible.

------------

 

@ Maximus

As far as the smoothing of the objects. A normal map won't make those bottles appear any rounder than that. They obviously have no smoothing data, hence the sharp corners. You deffinately need to apply a smooth modifier (I believe we talked about this before). A normals map can help make them look smooth but doesn't have the same effect as smoothing does (not mesh smooth -ie adding polys but render smoothing)

 

I think they look pretty good. You should smooth them, then texture them and let us see them in game :)

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Sorry Tels, I disagree with alot of your post.

I don't think we need to get too anal about every model having its top and bottom on the grid. Grid alignment is important and something to consider but there is leeway IMO.

 

Collision models are NOT more complicated if the top and bottom of an object aren't grid snapped. A plank will not balance on 2 bottles either realistically .Planks can be rotated with the rotate tool to 'balance' on two different height bottles.

 

It is almost impossible to get objects to not float or clip into others when the CM is not grid-snapped. It makes placement in the editor really really complicated and it causes a LOT of glitches like floating stuff, or stuff clipping into each other at level start.

 

The only reason this wasn't a problem so far was because virtually nobody ever actually tried to use moveables in their map, with a few rare exceptions.

 

If you ever tried to place 100 moveables in the map and had to manually adjust the placement of each of them you would know what I talk about.

 

Having stuff not grid-snapped is just sloppy working and it will bite us in the long run.

 

Also:

 

The important things are:

All objects should have their bottoms on a grid line. It will be very common for objects to be placed right side up and quickly.

The larger the grid line the better. But this has to do also with origins (see below)

 

Other objects like tables should have their top also on a grid line. This is so the bottom of bottles, ect... will align with them and not float or clip. Large things like tables should stick to a fairly large grid size so easy of placement.

 

 

Objects like tables can have their origins at the bottom/floor level. It doesn't really matter because they won't be moveable. origins are centered for frobbing and moving/throwing...

 

Objects that will be moveable : chairs, bottles, small vases (I say this 'cause we have 10 foot tall vases too), goblets, ect... should have their origins as "close to center as possible". This makes frobbing easier as the player aims at the center of the object.

There is alot of leeway here to, you have to think about the object and not only its center but its "center of mass"

My trophy object has a really skinny bottom and a really fat top. The middle is right in between and might be hard to frob with the origin centered because there is not much width there. So I went more with center of mass and moved the origin up into the fatter part where the player is more likely to focus their frob. If thrown it is more realistic also that an object will rotate more around its center of mass rather than it's actual center.

The bottom should still be on the grid lines but the top really doesn't matter. If someone wants to balance a plank on it, or balance it upside down they can decrease the grid to a very small size and do a more exact placement.

The point is to make standard placement easy but not to try and guess every possible scenerio that some author might choose to place the object.

 

The collision model is based around the objects shape/position. If the top of the object is off grid then the top of collision model is off grid. No biggie. The important thing is that the collision model is simple enough to work, but complicated enough to simulate the shape of the object as close as possible.

 

If you read my post carefully, you will see that I agree with you. In fact, I cannot see how you cannot agree with my post, and then state the absolutely same again, just with different words.

 

!?

"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

Ok ok Tels. You're right. Now start modelling some shit so you know what I'm saying would you?

 

First off like I said. Having the top of a collision model of the grid and the top of the object off the grid doesn't matter at all.

 

You said that the top's should be aligned, can we agree on that?

 

You say that I need to place objects in a map, you think I haven't tested every single object I've made in a map?

 

Having stuff not grid snapped at the top, is not going to bite anyone in the ass. Other than stuff like tables that something will set on. Your post made it sound like EVERY objects top needs grid snapped. But why? What's wrong with the top of a bottle not being on a grid line? 'cause someone might try to balance a plank on it?

 

---

recap your post:

 

You said keep the bottom and top on the grid:

 

Technically, you could make f.i. 3 units from bottom to origin, and 3.25 from origin to top, but maybe its better to keep things symetrical.

 

 

(Although it limits the number of different sizes a bit. If things look all o same-sized, using half units for the top part would be a comprimise. But this makes CMs more complicated, and doing thigs like balancing a plank on two wine bottles more complicate, too.)

 

 

I said the top doesn't need to be on a grid line. I also said that this does not make the CM more complicated. I also said that a plank can be rotated to fit different sized bottles if someone intends to do that.

 

You said things should be symetrical, but keeping them symetrical has no concern as to the center of mass.

 

I just don't see the point in making every object exactly x grid unit high. If the bottom is on a grid line it will set apon another object nicely. If someone wnats to make a stack of bottles then they can deal with a small grid size and more meticulus set-ups. Like I also said we can't worry about every possible scenerio an author might come up with.

 

Why does a bottle need to be exactly 3.25 uints high? so some author that decides he wants to balance one upside down doesn't have to use a small grid. Almost any object no matter how far off the grid is gonna come close to a very small grid line. So close in fact that under 99% of circumstances any floating that occours will not be visible to the player.

So if the top of that upside down bottle doesn't exactly hit a grid line then it really is not that big of a deal and is certianly not going to bite us all in the ass later.

------

 

I'm trying to elaborate and let new modellers know exactly what they should do and WHY. Your post is slightly misleading and doesn't explain why/why not grid snapping matters.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Ok ok Tels. You're right. Now start modelling some shit so you know what I'm saying would you?

 

Dude, chill out. Seriously, don't get worked up just because we discuss stuff.

 

As I already stated, I do not have the tools to do modeling.

 

First off like I said. Having the top of a collision model of the grid and the top of the object off the grid doesn't matter at all.

 

Exhibit A:

 

post-144-1200850754_thumb.jpg

 

This is how far stacked crates will be _apart_ visually when their CMs _touch_.

 

Now explain to me how this can be good?

 

You said that the top's should be aligned, can we agree on that?

 

Obviously only for objects where you want to ever stack something on top of them. This rules out any "round" object, like a carrot, or flowers, bushes etc.

 

Anything else (static table, wine-bottle etc) where you ever could balance something on top of it needs to have the bottom and top snapped to the grid.

 

You say that I need to place objects in a map, you think I haven't tested every single object I've made in a map?

 

You only tested your objects, but not *every* object. I know this, because there are at least 3 models which have no CM (you cannot place them), there were some with empty CMs (the planks), and there are objects which have their CM quite different from the visual model.

 

Please note that I am NOT saying this is your fault, but I am pointing out this is something we need to fix, regardless of how, why, by whom or when these objets where made.

 

Having stuff not grid snapped at the top, is not going to bite anyone in the ass. Other than stuff like tables that something will set on.

 

You are contradicting yourself in these two sentences. Either it doesn't matter all, or it matters.

 

Clearly, *when* it matters, it matters. :)

 

Your post made it sound like EVERY objects top needs grid snapped. But why? What's wrong with the top of a bottle not being on a grid line? 'cause someone might try to balance a plank on it?

 

Exactly. Crates bottles, pots, buckets, planks, crates, tables, all these would need the top at the grid. Flowers, etc, don't need it.

 

(snipabit)

I said the top doesn't need to be on a grid line. I also said that this does not make the CM more complicated.

 

But it makes _placement_ in the editor more complicated.

 

I also said that a plank can be rotated to fit different sized bottles if someone intends to do that.

 

Rotation does have nothing to do with it. If an object (for instance a crate, bucket, bottle or whatever) is 3.11010012 units heigh, you will have a very hard time to put *anything* on top of it, because the top object cannot be snapped to a grid and touching the lower object at the same time.

 

The best you can achive is slightly floating, or clipping. And both things are bad.

 

(Continued in next post)

post-144-1200850716_thumb.jpg

"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

You said things should be symetrical, but keeping them symetrical has no concern as to the center of mass.

 

I said that being symetrical might make it easier, but frankly, I don't care where the origin is, all I care that the objects are grid-snapped.

 

I just don't see the point in making every object exactly x grid unit high.

 

See my note above. Not every object, but where ever it makes sense.

 

If the bottom is on a grid line it will set apon another object nicely. If someone wnats to make a stack of bottles then they can deal with a small grid size and more meticulus set-ups. Like I also said we can't worry about every possible scenerio an author might come up with.

 

The entire point is: We should. Really. Map authors are out customers, our target, they are to please. And if it as easy as making sure that objects nicely stack, then we *should* do this.

 

I am really sick of games where objects float or stick into each other, and we can easily prevent it without having every mapper wasting countless hours re-arranging objects. (Praxis also tells that people don't do this, and just let the stuff float).

 

(it is double-plus-ungood if the object in question is a moveable, because then the physics will go crazy)

 

 

Why does a bottle need to be exactly 3.25 uints high? so some author that decides he wants to balance one upside down doesn't have to use a small grid. Almost any object no matter how far off the grid is gonna come close to a very small grid line.

 

Close is not good enough. We aren't here to make a sloppy job that mappers have then to plaster over my adjusting their objects.

 

 

So close in fact that under 99% of circumstances any floating that occours will not be visible to the player.

 

Floating objects are bad, even if you think the player won't notice. The wrong shadow (light shining through the crack), and the fact that you can look *through* the crack will give it away.

 

So if the top of that upside down bottle doesn't exactly hit a grid line then it really is not that big of a deal and is certianly not going to bite us all in the ass later.

 

Only if you are not the map author who wants to put something on top of that bottle.

 

I'm trying to elaborate and let new modellers know exactly what they should do and WHY. Your post is slightly misleading and doesn't explain why/why not grid snapping matters.

 

I thought I explained it already, but I explain it again: Quality matters. Ease-of-mapping matters.

 

And again, in case this was lost:

 

Not *every* object has to be grid-snapped. But it would be certainly welcome if we can start with even the cubic objects like crates. Having crates float on top of each other is just...unprofessional.

 

We (well, I) always lament when other games do such things, thinking "Can't they even find someone who grid-snaps their objects!", and then we do the same? I don't think so, we can do certainly better.

 

And to say it again: This does not personally mean just you. I am talking about the project and the team and this includes me (although I am a bit hampered in regard to models).

"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

Making the tops of bottles grid-aligned is pretty pointless, IMO. Bottoms of things should certainly be grid-aligned, and the tops of surfaces that are liable to have stuff placed on them, as baddcog mentioned. If a mapper wants to stack planks on bottles for some reason, then they may have to go through the extra complication of reducing the grid size in the editor. It doesn't make sense to get anal about grid placement when collision models are too primitive to match most objects anyway.

Link to comment
Share on other sites

Making the tops of bottles grid-aligned is pretty pointless, IMO. Bottoms of things should certainly be grid-aligned, and the tops of surfaces that are liable to have stuff placed on them, as baddcog mentioned.

If a mapper wants to stack planks on bottles for some reason, then they may have to go through the extra complication of reducing the grid size in the editor.

 

The point is that with a bottle height of 3.6 units, you can't make the grid small enough to put something on top of that bottle exactly. It either floats, or it clips into it.

 

Since all heights are arbitrary, there is no real reason to not use "3", "3.5", "3.75", or any other (big or small) grid unit for the top of the bottle.

 

Making the bottle 3.6 units heigh just makes it harder for others with no real gain, unless you count on having a lot of different bottles all having a different height for some artistic reasons.

 

The same goes for books, shelves, buckets and anything else where you would want to put something atop.

 

And just because we cannot think of any reason to stack things should not be the limit that we impose on the mappers. You just have to see jdudes map to see some very creative object stacking and placements.

 

It doesn't make sense to get anal about grid placement when collision models are too primitive to match most objects anyway.

 

As long as the model has a reasonable flat top, the CM can match it good enough. For anything that is not flat, you are right, it doesn't matter. But I already said this :)

"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

    • 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!
      · 1 reply
    • 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...