Itches, Glitches & Anything Else...

[OrbWeaver]

Some of them are used, some of them aren't. I can't off the top of my head remember why.

[SneaksieDave]

I looked at the def of the two items in question. The guard is (1 .5 0). The candleflame has no editor_color definition.

 

Lemme see how a color change on the guard affects the editors, brb.

 

Edit: interesting, the guard ragdoll had the color defined, not the guard. Adding that does change his color. So I assume that dark green is a default color. Can that be made accessible? It would clear much of this whole (minor) problem up.

[greebo]

No, that's the ragdoll, but it should have the same colour anyway. The builder_guard inherits down to monster_default (defined in doom3\base\pak000\def\monster_default.def). The colour should be the same as for the ragdoll (orange).

 

The candleflame inherits from light (defined in pak000\def\misc.def), and should be pure green (0 1 0).

 

Maybe this is some inheritance issue?

[SneaksieDave]

See my edit above. Okay, so when I changed it explicitly on the guard definition, I got a purple guard. So, perhaps inheritance yes. It still makes me wonder if that nasty green is a default color defined somewhere, since both of these completely different (and TDM-custom) objects were the same color. If so, if that could be exposed to the user, it would make any and all undefined-color objects changable in the UI to suit a user's needs.

[greebo]

Yes, it appears to be a default colour defined in the Doom3EntityClass constructor. I don't know what OrbWeaver has planned here, so I will wait for him to reply.

[OrbWeaver]

It seems there are two issues then:

 

1. Default entity colour not configurable, this should really be available in the Colours dialog.

2. Inheritance is broken (known issue).

[SneaksieDave]

Thanks, I'll track it if it's not already by the time I stop by.

[greebo]

The latest SVN revision seems to crash on map changes, I'm currently investigating it (in case you wonder). I don't know exactly what it causes to, but I will find it, just don't hold your breath till tomorrow morning.

[OrbWeaver]

I can't compile the latest revision (1163), there are still references to BrushDoom3 which seems to no longer exist.

[greebo]

Oh, I really screwed up this revision, it seems. I hope it's not urgent to you, because I can't promise that I'll fix it till I fall asleep.

[OrbWeaver]

No, it's not urgent. It's unlikely I will do anything until tomorrow anyway.

[SneaksieDave]

Speaking of 'tomorrow morning' - is there any way to have timezone support on the bugtracker? I tried to find it in personal profiles but couldn't. I'm sitting there trying to figure out.. "his post is at this time on the boards, and I'm at this offset, while the fix is marked on this time on bugtracker, but is that before the post, and that's why it's not yet fixed, so I need to wait till........"

 

[OrbWeaver]

If there were timezone support I would expect it to be configured in the "My Profile" area, so it would seem to me that there isn't. I wouldn't be surprised if greebo has hacked it in by the time I wake up tomorrow, however.

 

Of course, if you really want to make sure you are using the latest version there is only one solution.

[SneaksieDave]

I will probably do that at some point in the future when things are more "nearing completion" (not the right word, as software is always evolving, but you know what I mean), maybe even to attempt some personal tweaks for myself that didn't fly too well as requests on the bugtracker.

 

The daily SVN version on FTP is cool though, because it's not just me who can get to it - anyone with access can enjoy it hot out of the oven.

[OrbWeaver]

Oh, is it daily? I didn't realise, I thought greebo was producing the builds manually on an ad-hoc basis.

[SneaksieDave]

It seems to be daily, but I'm not sure if greebo has it automated or not.

[greebo]

No, it's not daily, I upload it as I consider a feature as finished. I didn't upload anything yesterday, for example, because I couldn't solve that one crash.

[OrbWeaver]

That's what I thought. It would be quite cool to have an automated nightly build, but this would require a suitable server to build and upload it.

[greebo]

Select Complete Tall should be implemented now, I hope I got it right as I never used this much. New snapshot is on FTP.

[SneaksieDave]

Any idea where I might fix this? http://img113.imageshack.us/my.php?image=pathsfm6.jpg

 

Since removing and replacing the XML files, I'm getting a double maps folder. /maps/maps does not exist. I browse all the way back to root and then back to maps, and it still happens on next launch. I load, save, reload, and it still happens on next launch. I back up, back up, forward, and reload, and it still happens on next launch.

 

I didn't find a reference (at least nothing obvious) to fix this in the XML files. It's not a big deal, it's just irritating, so I didn't report it (plus it's probably specific to my install).

[OrbWeaver]

I've seen that myself, I have no idea what is causing it though. Clearly the map folder is set correctly since you are browsing it, so I don't know why the widget is showing two maps folders.

[SneaksieDave]

If I may plead my case. (Hopefully this won't be too hard a sell... If I get long winded here, I'm just trying to be thorough. Thought about this all night.)

 

I know it hasn't even been a week since entry 166 was mentioned the first time (about wysiwyg point-and-click selection old style in cam only), but I'm asking if we could revisit it. I know it's been suspended (by me in fact), but I'm sorry, I've tried using it this way over the past few days, and it's proving to be very difficult/frustrating/even impossible (multi - see below) to use. For an extreme example, imagine a map of docks, or a city with a sewer. Almost every single selection click in the cam will be an undesirable selection on the first try, because it will always select the water brush(es) below first and foremost, even though you can't see them because you are up in some closed tower, 80 feet above the ground. For a more normal example, imagine any large map where func_statics are prevalent. Or, within a mansion, you're trying to do some renovation, but every click you do selects some door, or a couch, or an AI, out of sight and all the way across the map.

 

"Alt-shift!" I hear. I realize alt-shift select works, but that's really a secondary tool for when it's needed, not really the primary selection method (point, click). Moving the constant necessity for alt-shift from the ortho views to the cam view is really only swapping one difficulty for another (though this is definitely better for ortho views - the prioritized entity selection is excellent and must-have; it just doesn't go well with the cam view). But worse, alt-shift select is of little use when you are trying to select multiple items in the cam view, just try it. The cam used to be the most powerful point and click 3D multi-select vehicle, but that's no longer the case.

 

I don't know the source at this time, but of course with the old selection method, a click always selected what was in front of the click; simple and straightforward. New logic needed to be added to say, "sometimes what's in front is not what the user wants; check to see if there are any entities under the mouse, and if so, select those first instead." This is excellent for the orthos. What I'm suggesting/requesting is that for cam selection clicks only, that part of the logic is skipped, and just use the old logic instead, so that we're back to single point-click selection. In 3D space, that's all that's really needed.

[greebo]

I'll look into it.

 

Currently there is no distinction between camera and orthoviews from the SelectionSystem's point of view, so I'll either have to add some arguments somewhere that get passed down or query which type of view is currently active.

[greebo]

Fixed. The camview behaves as before in terms of selection priority.

 

The higher priority (Entity over Primitives) can be toggled via the preferences as well for those who don't like the entities being selected first.

 

The changes are not yet committed, as sourceforge.net appears to be down right now, but I've uploaded a new build to FTP.

[greebo]

I get a weird crash during the load of a map (in radiant/map/MapPosition.cpp):

// Sanity check
if (entity != NULL) {
	const std::string savedPos = entity->getKeyValue(_posKey);

	if (savedPos != "") {		<<< ------------------ crash here
		// Construct the vectors out of the std::string
		_position = Vector3(savedPos);
		_angle = entity->getKeyValue(_angleKey);
	}
}

Is a std::string comparison supposed to throw / can a std::string be invalid? It's not always happening, but I can reproduce it every second time I load the map.

 

edit: Maybe it's not exactly crashing there, I'll have to investigate more closely.