Itches, Glitches & Anything Else...

[greebo]

Moving around in a map via the arrow keys is acting different from previous. It used to be that you could move around in a map with arrow keys the way you'd walk through a map in-game, for instance to get a feel for it. Now, after holding down the arrow for more than a second, it accelerates to some super high speed, I assume intended as a convenience, like when spin controls speed up when held down. Unfortunately, this removes the ability to "walk" through the map (and makes meaningless Prefs | Camera | Movement Speed). Is there a setting we can use to change this back?

Hm, this sounds like some bug. I'll have to check this out - please open a tracker entry.

[Fidcal]

That camera problem where it locks up while rotating because the mouse cursor position has gone outside the camera limits (probably moved onto the orthoview.) I just found it seems cured by increasing the preferences > camera > rotation speed. I had it set on 1 for fine control but by moving it to 4 it seems to have fixed that problem.

[Fidcal]

Any way to get autosave to go in eg, ..\misc\ - that is, not in maps folder? Also tried full path G:\doom3\chalice\chalice_misc\

[greebo]

No, such a feature doesn't exist yet.

[Komag]

I don't know if being able to designate a separate location for the autosave map would be used much. How come you don't want it in your maps folder? Just for neatness' sake?

[Fidcal]

I was hoping that everything in the project folder except misc could be zipped up and distributed. I'm trying to keep it simple. But it is getting more and more messy. There are also screenshots and gamesaves and a few other files generated. Care needs to be taken not to zip them all up. We may well find FMs distributed with lots of unwanted stuff. The only way I can see it now is to list them and at zip up, move them all into the misc folder temporarily.

 

There is:

 

.darkradiant

.bak

screenshots folder

gamesaves folder

snapshots

config.spec

doomconfig.cfg

gamex86.dll

console.txt

[Tels]

We could provide a small script which zips things up?

[Fidcal]

That would be useful if possible, yes. I'm not sure whether it needs a list that goes in or a list to exclude. Probably a list to include:

 

map\mapname.map + dmap files

folders (if present)

xdata

def

textures (all possible asset folders actually)

 

I dunno - you can figure this out better than I can.

[Tels]

That would be useful if possible, yes. I'm not sure whether it needs a list that goes in or a list to exclude. Probably a list to include:

 

map\mapname.map + dmap files

folders (if present)

xdata

def

textures (all possible asset folders actually)

 

I dunno - you can figure this out better than I can.

 

Actually, if you just run the "devel/extract-assets.pl" script on any map file, it will figure out which files to include and zip up. Currently it would also package up SL assets, tho.

 

I guess if we simply remove anything that is not under "fms/", it would then produce the correct list?

 

Could you send me a sample zip of "everything" and tell me under which folder you store it when you work on it? (in fms? in doom?)

[Fidcal]

This is roughly the structure. The player extracts the zip into fms. I'll try to make up a demo one with all possibles:

 

mapname.zip
  L mapname (folder)
  L mapname.pk4
	  L various files, some to be excluded
	  L  maps\map files etc. but not subfolders like snapshots
	  L guis
	  L xdata
	  L etc. every asset folder is possible. Exclude gamesaves, snapshots, and misc

[Flanders]

tdm_nodrawsolid_* textures are not included in the nodraw textures filter.

 

It's only a small change, adding this after line 93 in doom3.game fixes it:

 <filterCriterion 
			 type="texture" 
			 match="textures/common/tdm_nodraw(.*)" 
			 action="hide" />

[greebo]

Thanks, Flanders, is committed.

[SneaksieDave]

Can anyone explain to me what these horizontal lines are that appear when using the Texture Tool with patches? I often see these, and usually ignore them, but I'm trying to figure out if they are just something I'm not understanding in the UVmapping world, or if they're a bug which should be reported.

 

First image shows the diagonals I'm talking about. You can drag the vertexes connected to them around, and it'll actually start to look like you're working with a 3D shape, oddly enough.

 

The second image shows what prompted me to post this question. How the heck does that mapping equal what's shown in the pic? It's as if the patch split in half and rejoined along the back... or something. Bug?

[SneaksieDave]

Another question I wanted to get opinions on before tracking:

 

Anyone ever notice that a bevel is never created in the orientation you want? How many times have you actually *wanted* a sideways bevel? Aren't they usually intended for arches? Yet, they're always created sideways, requiring mind-bending or random pressing of rotate x,y,z buttons to get them right. Every time. Worth requesting a fix for?

[Komag]

Almost all patches come out the wrong way (to me). Like I have a big wide flat brush that I make into a simple patch mesh, I want it to be wide and flat like the brush was but too often it's terribly skinny and on it's side, going from the other narrow dimension of the brush, so I have to turn it and lengthen it all over again.

 

But I live with it, don't know how much work it would be to make it work better.

[Fidcal]

I'm experimenting with presenting different AI & skins & heads in the next startpack. I can put in the head entity as a reference so there is something visible to see, copy its classname and paste it in the def_head value on the AI. The head is not needed of course but it is a useful reference for the mapper and can be roughly lined up on the body. I then set its model so it is not just inherited and change its class to func_group. It can then be left in the map and won't appear in the game. So far so good. But strangely, I noticed if I change the entity name to anything then the model visually disappears like the centre one in the image below. Not serious; if I change the entity name first then change the entity to func_group it seems OK. I'm just curious why this happens though. Is it a func_group thing?

 

[Fidcal]

No, it might be because I was taking a shortcut and just typing in func_group instead of selecting it.

[OrbWeaver]

For group entities (like func_static, and presumably func_group although I've never used the latter), the "model" key is used to determine whether the entity has child brushes, or a model. If the model key is set to the same as the name key, the entity is considered to have child brushes, otherwise the model key is considered to be the name of an actual model used for rendering.

 

I don't exactly understand the problem you are describing, but it sounds like there is some issue with the callbacks that get invoked when you change name and/or model keys.

[AluminumHaste]

Almost all patches come out the wrong way (to me). Like I have a big wide flat brush that I make into a simple patch mesh, I want it to be wide and flat like the brush was but too often it's terribly skinny and on it's side, going from the other narrow dimension of the brush, so I have to turn it and lengthen it all over again.

 

But I live with it, don't know how much work it would be to make it work better.

 

You need to pick which ortho view you want, the patch will be created facing the ortho view that you last used. So if you want the patch facing up then click in the top ortho view. If you want it to be on the side select the X or Y ortho view and the patch will be created oriented facing that view.

 

EDIT: Removed dumb portion

[Fidcal]

For group entities (like func_static, and presumably func_group although I've never used the latter), the "model" key is used to determine whether the entity has child brushes, or a model. If the model key is set to the same as the name key, the entity is considered to have child brushes, otherwise the model key is considered to be the name of an actual model used for rendering.

 

I don't exactly understand the problem you are describing, but it sounds like there is some issue with the callbacks that get invoked when you change name and/or model keys.

I think I've been making 2 or 3 different errors which sometimes cause the head to 'disappear'. One is you must set the model before changing to func_group. Another as you say on one or two I might have used the same name as the model. It all works so long as I'm careful as the actress said to the bishop.

[OrbWeaver]

I know it doesn't make much sense but it works.

 

How would it make more sense?

 

Perhaps some radio buttons in the Simple Patch dialog that allowed you to explicitly choose the direction, with the default set from the current 2D window?

[AluminumHaste]

How would it make more sense?

 

Perhaps some radio buttons in the Simple Patch dialog that allowed you to explicitly choose the direction, with the default set from the current 2D window?

 

Yeah I realized after I posted that, that it makes perfect sense and I've never had an issue with it since the days of qeradiant.

[SneaksieDave]

You need to pick which ortho view you want, the patch will be created facing the ortho view that you last used. So if you want the patch facing up then click in the top ortho view. If you want it to be on the side select the X or Y ortho view and the patch will be created oriented facing that view.

 

EDIT: Removed dumb portion

That's only true of simple patch meshes. Bevels, cones, cylinders (am I forgetting one?) are always created with a particular alignment. The request is that they align with current ortho as well.

[AluminumHaste]

That's only true of simple patch meshes. Bevels, cones, cylinders (am I forgetting one?) are always created with a particular alignment. The request is that they align with current ortho as well.

 

Yeah I was just talking about simple patch mesh conversions of brushes

[jdude]

minor gripe. How come we cannot see the x, y, and scale values for patches?

 

Also, I cannot properly texture any caps except cylinders. Even in texture viewer the inverted bevel cap is just two dots.