Jump to content
The Dark Mod Forums

Recommended Posts

A simple text file that contains a list of deprecated stuff that gets read by DR and can be used to mark the specific assets in question, for example by using a different text color (brown or red for example). In regards to replacing stuff "at some point" I guess it is enough to check whether missions have been updated and if in that case some of the assets in question are not used anymore. This would however only be worthwhile once the list of deprecated assets reaches a length were removing them from the mod would make a noticeable difference in file size, which probably mainly counts for image files anyways, as most other stuff is not that big.

 

The most important part for now should be to create a list of assets that needs replacement, at least to get an idea of how much we are talking about. Secondly feedback from anyone working on the coding side of DR in regards to possible implementations is needed, otherwise we don't need to discuss this aspect any further. Once we have these things sorted we can specify the details.

 

Just my oo

  • Like 1

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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

hmm really? how so..?

  • Stone extensions matching the existing brickwork no longer line up. A lower mantle makes non-moveables now hover.
  • In general, changes in form factor or texture alignment could undo what the mapper has done around a model.

Surely as long as the model dimensions aren't changed, we should be able to just replace the model outright. The issue I mentioned in the OP was just to get the textures fixed, which I beleive R-soul has 99% done.

 

I think I may have to update the OP to clearer about whats reqiured, what cant or can be done etc.

Share this post


Link to post
Share on other sites

I think I may have to update the OP to clearer about whats reqiured, what cant or can be done etc.

I have updated the OP, changes and suggestions welcome -

Edited by Bikerdude

Share this post


Link to post
Share on other sites

A model with a decal poking through the side of the main model -

 

- its the old decal over draw issue and the work around is to move the edge of the decal inward away from the side of the model.

 

ijFiiIH.jpg

Share this post


Link to post
Share on other sites

The decal is actually well within the edges of the rest of the object. The problem seems to be related to the decal shader, possibly the "polygon offset" which is prevents z fighting.

 

Here's a version where I shrank the decal (by chopping bits off) and I think it's as small as it can be. There is an improvement but from some angles the problem is still visible from quite a short distance.

 

stall_test.txt

(change extension to .zip)

 

An alternative is to provide versions of the models (there's also a double version and a cheap version) that have no decals. If their effect is too nice to do away with, the LOD system could be used to only show the decal model at close range.

Share this post


Link to post
Share on other sites

 

It's a DR issue more than a TDM one.

 

The issue is that models cannot be renamed or moved without breaking maps that rely on them.

 

However, it would be nice to remove some low-quality models from DR so that mappers aren't tempted to use them without being aware of the problems. Somehow the problem models would need to be flagged in some way that DR can be made to understand, but that that can still be accessed if needed (in case someone wants to edit a map that uses the older models).

Ideally entities could have two names, a user facing name, and a name that the game uses to keep track of things. For example the old torch is still called torch_01 so that it doesn't break existing FMs that use it, but the user friendly name gets changed to "torch_01_deprecated" when a higher quality version of torch_01 is implemented into the mod, so that someone building a map today will see this and use "torch_01_modern" instead of "torch_01_deprecated". The idea here is that nobody needs to sit there and painstakingly change the name of everything, because initially the user friendly name is just a duplicate of the name used by the game, until the asset is updated. Then the user friendly name of the old asset is changed, to mark that it is outdated without breaking anything,.

Edited by kano

Share this post


Link to post
Share on other sites

1. Hillary Clinton (no explanation needed)
2. Justin Beiber (or any teen idol, such as Miley Cyrus or Brittney Spears)
3. J-Lo (or any pop music icon or tv/movie celebrity, but particularly Jennyvonzewesternbloc)
4. Tess Munster or Blaire White... that's a tough call... I'll say "all social media pundits with a conviction".
5. Everyone involved with the Kardashian's (because they disgust me)

These are the worst role models for anyone to have, IMHO.

  • Like 1

Share this post


Link to post
Share on other sites

In terms of game models

1. Lara croft... nah.

I think all candlesticks needs a tweak, because they can be used as a doorstops to stop patrols, lock rooms and are often plentiful in a level - unlike boxes or moveable chairs, which allow for the same thing, but also for getting out of bounds or bypassing that locked fence and walking over the roof to find a way the FM maker never considered - I've noticed that there are often less chairs and moveable boxes and bails of stuff in newer FMs. Which is a shame, as they're great for dropping on people or luring everyone into a room and then putting a single box in the doorway, or a candlestick against the door...

Share this post


Link to post
Share on other sites

These are the worst role models for anyone to have, IMHO.

Dude, this isn't even remotely on-topic.

I think all candlesticks needs a tweak, because they can be used as a doorstops to stop patrols, lock rooms and are often plentiful in a level

This is a physics issue, not a model issue.

Share this post


Link to post
Share on other sites

1. That was my sense of humour. Not everyone gets it, but it fills my time until I can join my family.
2. There isn't a "nominate physics issues" thread. Those are models that could do with a little attention, in my humble opinion.

Graphics vs Gameplay.

Who gives a toss what I think, anyway?

Share this post


Link to post
Share on other sites

Who gives a toss what I think, anyway?

Due to the way you are expressing it ... noone.


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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

A simple text file that contains a list of deprecated stuff that gets read by DR and can be used to mark the specific assets in question, for example by using a different text color (brown or red for example).

 

An initial version of this is now implemented in my repository.

 

By defining a file called assets.lst in the top level of a resource directory (e.g. "materials/assets.lst" or "models/assets.lst"), you can tell DR to exclude certain model or materials from the in-editor tree views. The file has a simple key-value format, e.g.

darkmod/candlesticks/some_broken_model.lwo=hidden

Any model or MTR file listed as "hidden" will no longer show in tree views, but will still display as normal if you load a map with the asset in it.

 

Note because of how this is implemented, it works at a file level not an individual asset level, so if you want to hide just one material from an MTR file, you will need to move it into a separate MTR file and hide that entire file (hopefully this isn't too much of a problem since you can place materials definitions in files arbitrarily).

 

Currently this is only implemented for models and materials, which I assume are where the bulk of this deprecation work will need to happen. There is no reason why it can't be extended to other types of assets like sound shaders if necessary, but separate work will be needed for each asset type since they all have their own distinct parsing code.

  • Like 2

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...