Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

I recall changing the grid preferences in the latest release. I think the preference setting was missing completely in 0.9.4, and I adjusted it.

 

What do you want to achieve?

Link to post
Share on other sites
  • 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

I thought the grid size default in 0.9.4 was 8? Fairly sure it was usually that when first opened. That's what I prefer. It now defaults to 64. I have a feeling if remove 0.9.4, install 0.9.5 again and set the pref to 1 and then remove 0.9.5 and re-install 0.9.4 it will be back to 8 (as if there were some division by 8 somewhere)

Link to post
Share on other sites

I can't quite remember, but it could be that I fixed a bug in the grid restore code (the one that reads the grid size from the XMLRegistry).

 

(Why would you want to switch between 0.9.4 and 0.9.5 back and forth in the first place?)

 

So it might well be possible that the 0.9.4 setting is not correctly interpreted by 0.9.5, but after the first shutdown the default grid setting should be properly saved. Or are you saying that it doesn't get saved after you exit 0.9.5?

Link to post
Share on other sites

I don't want to switch between 095 and 094 for its own sake but just for this one purpose of getting the default grid size 8 back in 094. And yes, it worked, I re-installed 095 and changed the grid size to 1 then when I re-installed 094 it is back to 8 OK so problem solved.

Link to post
Share on other sites
  • 2 weeks later...

@OrbWeaver: I noticed a warning emitted by VC++:

 

1>dm.objectives\ce\specpanel\NoneSpecifierPanel.cpp(24) : warning C4390: ';' : empty controlled statement found; is this the intent?

 

There is an extra semicolon in there, I assume that was not intentional? I'm not sure whether gcc displays this warning, so I thought I'd post it here.

Link to post
Share on other sites

Ah yes, that was indeed a mistake, thanks. I wondered why I was still getting a GTK assertion on shutdown even after adding that code.

 

I think that's the first time I've heard of VC++ emitting a useful warning that GCC does not have.

Link to post
Share on other sites

VC++ has some good and some bad habits. It really depends on you as a programmer whether its bad habits are allowed to kick in. 99% of the time, I can code just as I did with gcc without running into any troubles.

 

I've seen three compilers now (MinGW/gcc3, gcc 4 in Linux and VC++) now and I can say that VC++ is at least as fast as gcc in Linux (which sets the bar quite high). The MinGW/gcc3 compiler is a lame duck in comparison to the other two. I wouldn't want to switch back to MinGW if I had to make a choice.

 

In some areas, the VC++ compiler is more anal than gcc4 (e.g. warnings about converting double to float, gint to bool, signed/unsigned comparisons and such.). Also, with _HAS_ITERATOR_DEBUGGING turned on (in debug mode), VC++ can get really anal about STL invalidated iterators being dereferenced or iterators increased beyond their valid range. This is freakin slow, but really keeps you on track when it comes to safe use of STL iterators.

 

The bad things are that it allows for the "goto crossing initialisation" error to occur and that it has some problems with the callback templates pointing to private member functions. And it complains about using the "this" pointer in the member initialiser list, which is stupid. Another bad thing is the case-insensitivity in #include directives, but that's a general Windows issue. Apart from the compiler, the IDE is superior to Eclipse by far. The debugger is really cool, so you get spoilt really fast, if you're used to std::cout-debugging-style as in MinGW/Windows (I don't miss that at all, believe me).

 

The overall positive thing is that we can get the best out of both worlds with using both gcc4 and VC++.

Link to post
Share on other sites
The overall positive thing is that we can get the best out of both worlds with using both gcc4 and VC++.

 

Best illustration on why you should create cross-platform programs :wub:

"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 post
Share on other sites
I have an itch with the editor. When you have a lot of entities and you make one target another it takes a long time to load up the target list, even if you don't want it, if you want to just type stuff in.

By "target list", do you mean the dropdown field in the Entity Inspector? That's presumably the auto-completion stuff which slows things down. Don't know what we can do about that, except disabling the auto-completion.

Link to post
Share on other sites
By "target list", do you mean the dropdown field in the Entity Inspector? That's presumably the auto-completion stuff which slows things down. Don't know what we can do about that, except disabling the auto-completion.

 

Yea the box where you type stuff in which also functions as a dropdown list. Perhaps we should have an option to disable the auto-completion, because I never use it anyways and it really slows things down when maps get larger.

Link to post
Share on other sites

In trying out the above, I saw the first case where a recent change (I think?) causes a minor problem. At some point recently, it seems the entity properties list on the entity inspector became locked to show exactly 6 rows? In the past, the bottom part of the dialog stayed fixed, and the property list resized. This was a bit of a pain, because if you wanted more rows, you had to accept losing other screen real estate because the lower half was fixed in size.

 

Now, the lower half adjusts in size. ^_^ However, the problem is now the opposite. If we want to show fewer rows, or reclaim screen real estate, we can't, unless we crush the bottom half of the inspector, and overlap controls. (See image).

 

I actually do like this change better, as I like seeing more property rows, however it can cause minor problems as seen in the image. As a fix, how about both halves of the inspector can be resized by putting a sizebar at the position indicated in red? That way if a user wants 4 rows (as I do) they can do it. If they need a huge lower half for whatever reason, they can do it. If they want it really small, for tons of screen space, they can do it.

post-58-1202754613_thumb.jpg

Link to post
Share on other sites
As a fix, how about both halves of the inspector can be resized by putting a sizebar at the position indicated in red? That way if a user wants 4 rows (as I do) they can do it. If they need a huge lower half for whatever reason, they can do it. If they want it really small, for tons of screen space, they can do it.

There is a sizebar in the EntityInspector already. It's below the spawnarg's value textfield. Or do you mean that the sizebar should be somewhere else?

Link to post
Share on other sites

Hm, maybe we were doing different things.

 

- Open DarkRadiant

- Create a brush

- Select a Face

- Open the Surface Inspector

- Type _black in the shader name field and hit enter.

 

Does this work on your end?

Link to post
Share on other sites
Hm, doing it exactly that way I get
Definition not found: _black

That seems logical since there really is no shader called _black or _white. Or should that work?

 

I wrote my own shaders that include _black/_white/...and so on. And those do work.

 

_black should work as they are build-in shaders, maybe your DR is outdated?

"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 post
Share on other sites

@Tels: No, I still get definition not found after svn co. But maybe this is the real bug, since the material that was selected before stays (it does not change to "shader not found").

@greebo: Did you try to select a material different to "shader not found" before setting to _black?

Link to post
Share on other sites
Hm, doing it exactly that way I get
Definition not found: _black

That seems logical since there really is no shader called _black or _white. Or should that work?

edit: Yes, this should work. These shaders starting with the underscore are a special case, they work both in the material definitions as well as stand-alone shader name. Wrong info, nevermind this.

Link to post
Share on other sites

*butts in*: That process with _black doesn't work for me, either.

 

Before opening the Media tab, I get:

Definition not found: _black

 

After, I get:

setShader

 

but I see no change in the camera view; it still shows the default 'not found' texture. Apparently the surface is updated to use _black though, at least in the shader name...

Link to post
Share on other sites

Ok, sorry, false alarm. I went in and tried to apply _white to a face, but this didn't work in-game. I could swear I read it somewhere on modwiki, but I always tested it with _black only (and this of course gives a black texture == not found...)

 

So I guess this is a non-issue, I'll close the issue report.

Link to post
Share on other sites

This is the link that was misleading me:

 

http://www.modwiki.net/wiki/Texturing#Dyna...Internal_Images

 

It says: "The engine has a set of internal image maps that are used for various special purposes. These images can be reference in material shaders and they can also be applied to surfaces as if they were materials in their own right." Which doesn't seem to be right.

 

Only _nofalloff seemed to work in my test map.

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.


×
×
  • Create New...