DarkRadiant 1.7.4 pre-release test

[Bikerdude]

plus a new "Floor Selection" feature, which had been requested long ago:

Oh man, thanks Greebo. This is very much appreciated!

 

Right, can someone tell me where/how to use this feature..?

[greebo]

Right. I've improved the floor algorithm to prevent further "falling" through the floor when hitting the command repeatedly, and for models the lowest possible vertex is now used as start point of the floor trace. Here's a x64 build, I'm skipping the 32 bit build as it's late already:

 

x64: http://www.dramtheth...7.4pre3-x64.exe (obsolete, see first post)

 

Btw: the feature can be accessed in the left toolbar, right below the "Snap to grid" icon. Alternatively, bind a shortcut to the "FloorSelection" command.

[Bikerdude]

ta.

[AluminumHaste]

Wow that's fast fixing greebo thanks.

[AluminumHaste]

EDIT: Removed

[motorsep]

This means that the entities you have currently selected gets floored to the ground. For example you create a stool or a bed, use this and the entity does stand on the ground nicely, without you having to do this manually.

 

As most models don't have their origin at the bottom and the distance between the origin's z-coordinate and those of the bottom plane doesn't neccessarily have to be a factor of an often used grid size, this is extremely useful and will safe the mappers a whole lot of time.

 

Cool feature, but what about objects that hang on the walls, ceiling, flying enemies, etc. ?

 

EDIT: Nm, I didn't notice second page So select the object, press a button, get object dropped to the floor. Got it. Cool feature, Greebo rules

Edited September 2, 2013 by motorsep

[motorsep]

Hmm.. I am not sure if that was the issue in previous versions, but no matter what I tweak in the .game file for a new game (except paths) it has no effect. I tried to change "_default" texture to "textures/common/caulk" and DR still uses "_default" texture for every new brush I create o.O (I deleted user settings from C:\User\me\AppData\Roaming\ and restarted DR)

 

What am I missing? What am I doing wrong? Thanks.

 

P.S. Saw Reload Shaders > Reload Materials, cool stuff, thanks Greebo.

[grayman]

Be careful 'flooring' moveables.

 

Having moveables sitting directly on the floor in DR leads to them possibly falling through the floor at run-time.

 

It's better to leave them sitting above the surface beneath them, and let TDM settle them onto the surface at spawn time.

[grayman]

I'm trying out the 'floor' option.

 

Very nice.

 

I notice that the 'floor' option treats no_draw surfaces as if they were visible surfaces.

 

Mappers planting objects on no_draw should keep this in mind:

 

1 - AI should probably be planted on top of no_draw, since they're going to treat it like it's really there.

 

2 - Objects (like furniture) should have any no_draw they're sitting on hidden before hitting the 'floor' button. If you have carpet on the floor and a no_draw carpet surface sitting on top of it, you want your furniture to end up on the floor, not on the no_draw.

[Bikerdude]

If you have carpet on the floor

I noticed that the flooring works on even 1 unit patched based rugs that I have created :-)

[Sotha]

I tried to FLOOR info_player_start in DR 1.7.4 (x64) (sep 1 2013).

 

It crashes DR. Happens every time. So mappers, be careful before trying to floor things. Save first.

[motorsep]

No crash here.

[Obsttorte]

I think sotha is working under linux. Under that DR crashes from time to time for me, too. While under windows it works flawlessy.

[Sotha]

Nope, it's on windows.

[greebo]

Have you been using the "Make room" feature before hitting the Floor command, by any chance?

[Sotha]

Yes, actually I have.

[greebo]

That's good, because I've fixed that issue, it's been reported by AluminumHaste before.

 

Here's the new x64 build: http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.7.4pre4-x64.exe

[AluminumHaste]

Excellent, thanks for the quick fix! What about the issue with brushes?

[Obsttorte]

Have you been using the "Make room" feature before hitting the Floor command, by any chance?

Just out of curiosity, what does the one have to do with the other?

[grayman]

An old problem with the Readable Editor has come back with the recent DR version.

 

Edit 9/12: Aaaannnd it's started working again. Must be tempermental.

 

I'm currently using the latest rev of DR to work on ws2_homeagain127.map. The "127" is just my version number, which I bump up occasionally.

 

I have my readables in xdata/ws2_homeagain.xd.

 

When I select an existing readable in DR, the Editor properly shows its content, so it's having no problem finding the entry in the xd file. If I make a change and Save, I get an error dialogue:

 

"You have imported an XData definition that is contained in a PK4, which can't be accessed for saving. Please rename your XData definition, so that it is stored under a different name."

 

My guess is that it's trying to save in xdata/ws2_homeagain127.xd, which doesn't exist, so DR assumes the content came from a PK4, even though it had successfully read it from ws2_homeagain.xd.

 

Shouldn't the Editor put the content back into the file it read it from?

 

Edit: I tried what I thought would be a workaround: I renamed my xdata file to

 

xdata/ws2_homeagain127.xd

 

Then I started DR, opened ws2_homeagain127.map, opened an existing readable in DR, made a change, and tried to Save it, only to encounter the error dialogue again.

 

So atm it appears I'm unable to make changes to any of my readables.

 

I've not had this problem for a loooong time, and suddenly it has reappeared.

[Obsttorte]

Is the file writing-protected? (Just a guess).

[grayman]

Is the file writing-protected? (Just a guess).

 

No.

[nbohr1more]

How hard would it be to grant the editor the ability to move the light_center and offset attached flame particles

to match it's location so you can easily reposition the apparent light source within a volume?

 

(Presuming you wouldn't want to rebuild all the light definitions with the particles attached to light_center rather than

the light origin).

 

May I submit a tracker for this?

[motorsep]

Why can't you copy/paste coordinates to your entity?

[Obsttorte]

Why can't you copy/paste coordinates to your entity?

Specify that.

How hard would it be to grant the editor the ability to move the light_center and offset attached flame particles

to match it's location so you can easily reposition the apparent light source within a volume?

Set light_center on flame etc.. !?

If this don't work, create the holder and flame model seperately.