Itches, Glitches & Anything Else...

[greebo]

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?

[Fidcal]

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)

[greebo]

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?

[Fidcal]

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.

[greebo]

@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.

[OrbWeaver]

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.

[greebo]

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++.

[Tels]

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

[jdude]

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.

[greebo]

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.

[jdude]

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.

[greebo]

Tracked here: http://bugs.angua.at/view.php?id=575

[SneaksieDave]

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.

[greebo]

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?

[SneaksieDave]

Nice! Thank you, that's exactly what I was looking for, and I didn't even see it there. I guess I subconciously dismissed that line as just a divider.

[mohij]

@greebo: I tried the _black/_white/_fog materials in both shaded an non shaded view, and they are shown in both. Could you give some more information on the bug where materials aren't shown? Perhaps I misunderstood it...

[greebo]

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?

[mohij]

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.

[Tels]

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?

[mohij]

@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?

[greebo]

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.

[SneaksieDave]

*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...

[greebo]

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.

[mohij]

Yes, exactly same behaviour that I experience.

[greebo]

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.