Jump to content
The Dark Mod Forums

Recommended Posts

  • Replies 704
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I would love to have a timer of how long we have spent in the map open.   Skacky posted on twitter a screenshot from one of his missions and I thought something similar would be cool to have in DR  

Has anyone considered implementing a 3d creation process like they did in this editor for Quake / Half-Life? Trenchbroom is able to create brushes directly on surfaces of other brushes on a 3d grid

Edit Menu > 'Paste to (0,0,0)' or similar. Several times I have created something in a mission and then decided to export it as a prefab, but it's a long way from the map origin. Typically I s

Posted Images

Wow, that was fast!

 

I have never tried checking out a "shapshot" of DR. The page says it has no DLLs, but then says to make sure to delete all existing DLLs because of the new ones???

shadowdark50.gif keep50.gif
Link to post
Share on other sites

Ah, I see the information is misleading. With "all the DLLs are missing" I was referring to the dependency DLLs (GTK, libxml, and such), not the native DarkRadiant DLLs.

 

The former are missing in the snapshot, but the latter are of course delivered.

 

Bottom line: Just extract the snapshot over your existing DarkRadiant installation, this should work fine (you can save the existing one by copying it somewhere - though you can always nuke the folder and re-install a proper release).

Link to post
Share on other sites

@Komag: I updated the Clipper code to take the most used shader for the newly created faces. Feel free to check it out (snapshot is being uploaded as I write, will be up in 6 minutes).

Link to post
Share on other sites

Works pretty good.

 

I tried with a block, works fine.

 

Tried with three faces painted brick (all 6 were wood), the clip came out wood, which is fine since even though the brush is 50% wood it USED be majority wood.

 

Tried with four faces panted brick, clip came out brick as expected

 

Tried with a nine sided brush, four sides brick, three wood, and two stone, came out brick as expected, even though the brush wasn't actually a majority brick, so that's good.

 

The only thing wrong is that it still uses the currently selected default scale instead of the brush's most used scale. Can you do this the same way?

shadowdark50.gif keep50.gif
Link to post
Share on other sites
The only thing wrong is that it still uses the currently selected default scale instead of the brush's most used scale. Can you do this the same way?

Hm, I don't know, maybe 15 minutes or so? Can't say.

 

I'm wondering, whether this is this actually useful? I mean, you are barely leaving the new faces with that default scale, are you? The usual procedure is to copy&paste the texture from somewhere else or to tune it manually anyway.

Link to post
Share on other sites

I'm not sure what is usual, but for me this would be very useful. I change the default scale all the time when texturing (much quicker than adjusting both horiz and vert scale on each brush) because some textures just work better at different scales.

 

So I might have a brush of wood grain at default scale 0.3, and if I later worked on an area with brick brushes at scale 0.5 or whatever, then come back and clip that wood grain brush, I get a 0.5 face which I have to either lower to 0.3 or copy/paste from another face of the brush, defeating the purpose of matching the clip texture to the brush.

 

This would be very useful for me and I believe it's proper clip behavior, to simply match texture and scale naturally. I feel like if I cut a wedge off a hunk of Swiss cheese, I don't want to find 3x smaller holes on the inside. Almost all of the time I want the new face to match like this, and I believe many future mappers will also want it.

 

(And I appreciate the time and effort it takes for you to do this stuff! So many requests, so little time :) It seems to me that you weren't around Dark Mod would be in a much worse condition!)

shadowdark50.gif keep50.gif
Link to post
Share on other sites
I'm not sure what is usual, but for me this would be very useful. I change the default scale all the time when texturing (much quicker than adjusting both horiz and vert scale on each brush) because some textures just work better at different scales.

 

So I might have a brush of wood grain at default scale 0.3, and if I later worked on an area with brick brushes at scale 0.5 or whatever, then come back and clip that wood grain brush, I get a 0.5 face which I have to either lower to 0.3 or copy/paste from another face of the brush, defeating the purpose of matching the clip texture to the brush.

 

This would be very useful for me and I believe it's proper clip behavior, to simply match texture and scale naturally. I feel like if I cut a wedge off a hunk of Swiss cheese, I don't want to find 3x smaller holes on the inside. Almost all of the time I want the new face to match like this, and I believe many future mappers will also want it.

Ok, I will try to retrieve a uniform scale from the brush faces. This might prove to be error-prone due to rounding errors, especially when the texture is rotated.

Link to post
Share on other sites

I have no idea how it works, and I guess it sounds more complex than matching the texture! Maybe to avoid errors you could make it round to the nearest .1, such as 0.3

shadowdark50.gif keep50.gif
Link to post
Share on other sites
Ok, I will try to retrieve a uniform scale from the brush faces. This might prove to be error-prone due to rounding errors, especially when the texture is rotated.

Hmmm... Maybe I'm wrong but as far as I understand, what Komag wants is:

- clip brushes

- figure out the most "popular" texture

- copy it to newly created faces.

The last one is the same as MMB and SHIFT+MMB, which works fine already. Why would it be error prone now?

Link to post
Share on other sites
Ok, the Decal patch creator is implemented now. Snapshot is on the way (in a few minutes), in case Sotha wants to test it out. ;)

 

http://darkradiant.sourceforge.net/snapshot.php

 

-Yay! Tested it. Nice, intuitive and fast decal adding system, very good. Thanks for bringing it available so quickly!

:D

 

I've got another suggestion, but it is probably of relatively low priority. Some kind of WYSIWYG -readable editor. When writing readable books, there is the difficulty of estimating how much text fits "page1_left_body" and you have to change to "page1_right_body" and so on.

It very slow to make this kind of readables and always check in-game if the amount of text is correct.

 

The editor would let you select the gui you want, and then write in it. You could add pages into the editor and easily see, when a page is filled. The system would allow saving the data straight into the wanted xdata-file.

Clipper

-The mapper's best friend.

Link to post
Share on other sites

A readable editor is definitely very advanced to code. The GUI system is entirely within the closed source and mimicking the GUI display in a WYSIWYG way is probably hard.

Link to post
Share on other sites

Yes, I think this is very much a future project. I was only thinking about it this afternoon. Been working with fonts etc so testing lots of guis.

 

If this info is of any use:

 

When changing readables guis the gui does not need reloading which is really helpful. Well, I guess Doom must load it every time you read it!! What I do is have it displayed in a test map, tweak the gui in a text editor and save. In DM press the inv use key twice and the readable re-shows with the new gui format!

 

If you change the text in an external .xd file then in the console you reloadDecls AND map the map again.

 

I also played with editguis this afternoon which was interesting but I didn't try for too long but I did make a small test and save it OK. It displays OK in the editor I used the parchment background but I made a standalone gui. I would need to experiment more to see if it could be used for our normal readables.

 

[EDIT] Yeah, editguis crashes out when it tries to open one of our readables.

Link to post
Share on other sites

It's working great, thanks a ton!

 

I am able to make it not work perfectly, but only if I have a brush with different textures and scales, in which case it's okay when sometimes is seems to do the too big scale even though a plurality of the proper texture's scales are smaller or whatever. But this case is weird and rare anyway.

 

So basically, it's good now and works great and all done! It really makes the clipper more perfect and natural, very nice.

shadowdark50.gif keep50.gif
Link to post
Share on other sites

Ok, glad it worked. :)

 

Feel free to close the issue report on the bugtracker once you can fully confirm it's resolved. Also, I added a note to the other issue you opened (T to close Texture View): Which DR layout are you using?

Link to post
Share on other sites

It seems to be already closed as far as I can tell. Which is fine, it's all set.

 

I replied to the T issue. (I use Split layout, and the problem also occurs with Floating)

 

 

 

Another slightly related small issue...

 

I think that Light Inspector should be (L) and then just stick Entity List with (J) (on other words, they could be switched).

 

I think all authors will use the Light Inspector a lot and it has the greater need for a shortcut that matches it's first letter than using up the L on Entity List just becase of "List"

shadowdark50.gif keep50.gif
Link to post
Share on other sites
It seems to be already closed as far as I can tell. Which is fine, it's all set.

The issues 448 and 449 have the status "resolved", but not "closed". Usually, resolving is done by developers and closing is done by the reporter. I don't know whether your permissions are sufficient to close issues. Do you see any options to close issues on that page?

 

I replied to the T issue. (I use Split layout, and the problem also occurs with Floating)

Yes, I'll check that out. I don't know if it's a real problem or if it is fixable, so no promises. :)

 

I think that Light Inspector should be (L) and then just stick Entity List with (J) (on other words, they could be switched).

 

I think all authors will use the Light Inspector a lot and it has the greater need for a shortcut that matches it's first letter than using up the L on Entity List just becase of "List"

I tend to agree here, but we might want to wait what other mappers say about this. Any opinions?

Link to post
Share on other sites

I am "Logged in as: Komag (Ben Ramsey - updater)"

 

At the bottom I see "Montior Issue" and "Reopen Issue". It was the word "Reopen" that had led me to believe it was currently "closed"

 

By the way, the Windows shortcut "Ctrl+W", used to close a window, also doesn't close the Texture window. So I guess all Windows shortcuts are basically turned off while DR is the active window.

shadowdark50.gif keep50.gif
Link to post
Share on other sites
Hmmm... Maybe I'm wrong but as far as I understand, what Komag wants is:

- clip brushes

- figure out the most "popular" texture

- copy it to newly created faces.

The last one is the same as MMB and SHIFT+MMB, which works fine already. Why would it be error prone now?

 

well he got it working just fine to maybe it wasn't error prone after all. Maybe it had to do with taking the average scale or something, not just one face.

shadowdark50.gif keep50.gif
Link to post
Share on other sites
Maybe it had to do with taking the average scale or something, not just one face.

Does it average the scale of textures? Well, if I had one texture with scale 0.2 and another with scale 0.4, I'd like the new faces to be textured with scale either 0.2 or 0.4, not 0.3 as no texture had that scale...

Link to post
Share on other sites
By the way, the Windows shortcut "Ctrl+W", used to close a window, also doesn't close the Texture window. So I guess all Windows shortcuts are basically turned off while DR is the active window.

FYI: Ctrl+W is not a built-in Windows shortcut. Like all other Ctrl+(letter) shortcuts, it's down to the app what it does with it. There may be a convention as to what should happen when you press it (like the convention that Ctrl+C means copy), but the convention is just that - a convention. It's not enforced or imposed at all.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
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...