Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...

Recommended Posts

  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

Same sorting issues with sound (now that I can hear them ^_^). I'm not sure at the moment if that's in the definitions or could/should be handled in DR (doubtful) but it's currently a hassle to find any TDM-based sounds in the sound browse thingy. This is likely the former, though (def/TDM ordering issue, not something for DR).

Link to post
Share on other sites

From DarkRadiant's point of view, all the shaders are the same and can only be qualified by their name. The problem is that there are so many sounds from vanilla Doom 3.


I have already thought about adding an option to skip the base/ folder during startup, but this would imply some other issues like missing light shaders and particles (think of smokepuff). Of course the ability to browse through any D3 vanilla stuff would be gone as well.

Link to post
Share on other sites

I think the DoomEdit approach was to list sound shaders underneath the .sndshd file which defined them. This could presumably be done in DR as well (the current flat list was just a proof-of-concept interface, I was assuming that some better organisation would be needed later).

Link to post
Share on other sites

I intend to make a change to the parser library: For now (not committed yet) I created a base class Tokeniser which has whitespace as delimiters and made the DefTokeniser derive publically from it, overriding the delimiters of the base class in the constructor.


I wonder if it's ok to name the base class "Tokeniser" as it also protects quoted content (no tokenising is happening within quotes), which is a thing Tokenisers don't do usually, right? I'm a bit unsure here, as I need it to parse spawnargs (space-delimited). My intention was also to create a Tokeniser that is useable as base class for a future MapFileTokeniser.


Should I make the protection of quoted content an option? Should I create a completely stand-alone Tokeniser class that just wraps a boost::tokenizer and leave the DefTokeniser alone? What would you suggest?


edit: Ah, it seems there are some handy char_separator tokeniser models available, which will certainly be enough for a Tokeniser base class. I'll go that way and leave the DefTokeniser alone as specialised solution.

Link to post
Share on other sites

When I wrote such code, I usually passed in an escape charter which can be used to escape quotes.


So for example:


This is a "test sample"


will create four tokens, while


This is a \"test sample\"


will create five tokens out of it. the escape character simply means that the next character will be treated like any other character without special meaning. With this you can default the escpae character to 0 in which case it is not used.


Another thing you might consider is to allow multiple cahracters as token indicators. Like this


Tokenize("This is\ta \"test sample\"", " \t", '\\')


Where in this case the '\t' (tab) and ' '(space) is considered to be an indicator where to break the tokens.


Link to post
Share on other sites

Thanks, I already took the boost solution, which can almost instantly used out of the box, and I can define as many delimiters as I want:

typedef boost::char_separator<char> CharSeparator;
typedef boost::tokenizer<CharSeparator> CharTokeniser;

CharSeparator _separator;
CharTokeniser _tok;
CharTokeniser::iterator _tokIter;

// Constructor
StringTokeniser(const std::string& str, 
			const char* delimiters = " \t\n\v\r") :
_tok(str, _separator),

This class wraps around an internal boost::tokenizer and provides some convenience methods like nextToken(), hasMoreTokens() and such.


I'm not sure if the idea with the escape character will be of use for DarkRadiant, because there aren't any string streams with escape characters involved, but it's still not a bad idea of providing an optional escape character.

Link to post
Share on other sites

As far as I am aware the DefTokeniser should work fine for all Doom 3 text-based content, since the same rules are used in all of them: C-style and C++-style comments, protection of quoted content, whitespace as separator.


What is the need for the new Tokeniser solution? Is there some specific syntax in the map file which cannot be parsed by the DefTokeniser?

Link to post
Share on other sites

I needed it to parse the control points of the NURBS and CatmullRom curves, which are space-delimited, and I wanted to replace the homegrown StringTokeniser which was previously used for this.

Link to post
Share on other sites

It would work here as well, that's true, but I didn't want to use a tokeniser designed for DEF files to simply parse a space-delimited string, it appeared a bit overkill to me. Screwdriver for screws, hammer for nails. :)

Link to post
Share on other sites

This camera movement through DR is great. When right clicked I can move freely turn and strafe and rise and fall just with mouse and cursors. Was it always like that? I knew about the mouse but I had been using it mainly just to look round and then disengaging it to use the cursor keys, strafe keys, and rise and fall keys, and tilt up and down view keys! Phew! Those DoomEd keys were conceived by an octopus. I had been thinking of changing those keys for a long time but not until I was familiar with the main other defaults in DR. Now I don't need to.


PS, Is there a fly mode in game itself like in Dromed? Having to run and climb everywhere to test a mission would be slow in some missions.

Link to post
Share on other sites

Wow! That is awesome - much better than in Dromed. Seems to me that there are certain commands and cvars that all DM betamappers ought to be aware of. I have a full list but I wouldn't know where to look and many might not even imagine a fly mode. Suppose someone finds out after five years struggling? Maybe there is a case for a favourites list or betamappers short list on the wiki? Maybe also include the full lists if that is not copyright. DM wiki should be self-sufficient if possible.


For example those for testing visportals (I have to keep looking them up myself) and notarget, god, etc. If there is no object I'll start a wiki but if anyone would like to post here their top 10 most used console commands with good description of what they do then I'll add them - or add them direct once I get it up (perhaps I should rephrase that.)



Betamappers Need To Know Console Command And Cvars:


god = god mode. Will not take any damage. *


noclip = fly in game for testing. Use movement keys to go up/down where pointing. Goes through solid. Stays put so you won't fall when stop moving. *


notarget = AI ignore you (though they will notice suspicious things like extinguished torches.*


r_showPortals 1 = shows visportals as wireframe in-game for testing, red is closed, green is open.


r_showtris 2 = shows what is currently rendered as wireframes.


r_useScissor 0 = shows geometry outside the visportal rectangle that Doom still sends to the video card but tells it not to render. IS THIS IMPORTANT ENOUGH? WANT TO KEEP THIS LIST SHORT.




* Only effective when map already loaded and need to re-use each time map loaded.

Link to post
Share on other sites

OK, did a quick check of the wiki under console and commands earlier but not a full search. If I do a short list I'll add a link to the user settings and also add an extra link in the main list pages.


Anyone think of any other important ones that betamappers should know?

Link to post
Share on other sites

This is what I've setup in my DoomConfig.cfg:


bind "h" "toggle r_showtris 1 0"
bind "k" "toggle r_skipbump 1 0"
bind "l" "toggle r_showlightcount 1 2 3 0"
bind "o" "toggle r_shadows 0 1"
bind "p" "toggle r_showprimitives 1 0"
bind "v" "toggle r_showportals 1 0"

This is useful for optimising your map and finding the most rendering-intensive scenes. Apart from that I think it's definitely noclip I'm using most frequently.

Link to post
Share on other sites

I just never think about binding keys to these commands! Good idea. Though I'm short of keys I can use some.


BTW, is it possible to create a separate textfile list of commands named say go.cmd and then just enter 'go' in the console?

Link to post
Share on other sites

I don't know. I read a while ago about an Autoexec.cfg which can be used to fire commands on Doom 3 startup, but I don't know if this can be called in the console and if it works at all.

Link to post
Share on other sites

I'm seeing text overrun in the texture browser. Maybe it's longer filenames now or maybe I'm only just noticing it or both! Anyway, all I can think of is put text on two lines and force wrap? I've tried the two views and also enlarged full screen and this sometimes reveals some of the text that was obscured but not always. This is what I see...



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.

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.

  • Create New...