OrbWeaver
-
Posts
8649 -
Joined
-
Last visited
-
Days Won
67
Posts posted by OrbWeaver
-
-
I've set the export-ignore attribute on .gitattributes itself, so I guess we'll see if this makes any difference to what GitHub produces.
4 hours ago, coldtobi said:Another approach could be to make the release tarballs manually, (and possibly also GPG sign them afterwards to ensure that supply chain attacks can not happen -- Debian would appreciate a GPG signature, but I digress)
I'd like to avoid creating "upstream" tarballs, as it is recommendation within Debian to use the upstream tarball unmodified when ever possible; (even if there is no GPG signature to break…)
Another possible source for the tarball would be the one attached to the Ubuntu package, which is effectively a "pristine upstream" tarball since I am generating that package myself without any Ubuntu-specific patches. It would also be (indirectly) signed as part of the PPA publishing process.
However I don't know if you or Debian would have a problem with basing a Debian package off an Ubuntu package source, since it's usually the other way around.
-
Yeah, the anaglyph stereo effect is fun for looking at a few 3D objects in picture books, but I wouldn't want to play a whole game using it. The weird inconsistent eye colour really detracts from the image quality.
-
I don't think the preferred solution would be to remove .gitattributes from source control — even if its contents aren't strictly required now (which I haven't investigated), a permanent requirement to never have a .gitattributes would be somewhat restrictive since we might need its functionality at some point.
The problem is that the file is appearing in the tarball, which is unnecessary and undesirable. The first thing to do would be to set the export-ignore attribute on .gitattributes itself, which should cause it to be excluded from any git archive command. I have no idea whether this will affect the automatic tarball published by GitHub, but if it doesn't, presumably it would be feasible for either us (upstream) or coldtobi to create a tarball explicitly using the git archive command from the repository.
-
I think people are getting hung up on the question of whether the nation of France existed, which is actually irrelevant to this discussion because in the TDM world, none of the real-world nations actually exist with their real names and political histories. Nor does it matter whether "Britain" existed, because Bridgeport is never described as being in "Britain".
The question is whether the geography and climate of (what we now call) southern France match the areas which are presented in game. It seems to me that Bridgeport is modelled more on a port city of medieval England (which certainly did exist geographically, regardless of what the country was called or who ruled it at the time). But I guess you don't really perceive temperature in-game, and most missions take place at night in a small area of the city, so it could be pretty much anywhere in (what we now call) Europe.
-
1
-
-
I actually had no idea that the in-game world was supposed to map onto the shape of real-world continents. I always imagined it was a pure fantasy world like Westeros or Middle-Earth.
-
1
-
-
I agree. The Hammer interface looks like a much better way of presenting this functionality.
Blender also does a good job here — in fact they recently got rid of their "Layers" functionality altogether and merged it into the Outliner/Collections window.
-
1
-
-
On 7/31/2022 at 8:06 PM, Airship Ballet said:
Have to make sure you're carrying the loot bag too, that's all I can think of!
Yes, that was it. I never even realised there was something to pick up in the vault after the "fade to black" sequence.
-
1
-
-
Yeah, having a completely independent timer seems like a recipe for desychronisation problems.
Probably what I'd do is:
- If the display frame rate is less than or equal to the cap value, just enable vsync and don't do any manual synchronisation — it's not adding any value beyond what vsync does naturally.
-
If the display frame rate is greater than the cap:
- After a frame is actually displayed (i.e. vsync is completed and the buffer swap has happened), store the current time in a variable.
- When the next frame is ready to be shown, compare the current time with the value stored in the previous step. If not enough time has elapsed, pause for the required number of milliseconds (or slightly less) before displaying the next frame.
Of course this assumes that there are suitable platform-specific methods to obtain the actual display frame rate. I can imagine this might be problematic on Linux given there are two different display servers and several desktop compositors in use.
Perhaps the quick and dirty solution on Linux is just to enable vsync by default, then disable the frame rate cap by default (since vsync will take care of it)?
-
I seem to remember having this issue too. It's strange but the built-in FPS cap doesn't seem to work well on Linux. Perhaps there is some low-level problem determining the correct FPS from the X window system (or Wayland if you're using it).
-
I'm not sure I fully understand the problem, but yes, materials are written into the map file (that's how the engine knows what texture to put on the side of a brush, after all).
Regarding dmap not noticing material changes — that sounds odd, as far as I know dmap does not do any kind of "change tracking" and should just compile the map however it finds it, regardless of what has changed since the last time you dmapped. Note however that dmap is part of the game engine not DarkRadiant, so I can't really be much help with this side of things.
-
I enjoyed this mission, but fell at the last hurdle: I can't figure out how to "Leave with the loot"!
I tried going back to the starting point, but nothing happened. All of the windows have bars, and I can't find any doors out of the bank.
I also had to consult the forums to find out how to empty the teller safe. That key hiding place is very non-obvious (at least from a Thief perspective — I guess it makes perfect sense in real life).
-
1
-
-
Not a problem. This is still useful feedback. If you were confused where to drag, it's a safe bet other people are too, which means there is scope for UI improvement.
-
2
-
-
23 hours ago, duzenko said:
You mean you have this problem as well? Did it start last year after switch to GLFW?
It's been like that for as long as I can remember, and I never really considered it a problem as such. This is a 3D game with constant mouselook — I expect it to grab the mouse while it is in the foreground.
23 hours ago, nbohr1more said:This still happens when "in_grabMouse" is set to 1 ?
With in_grabMouse 1 I get a permanently grabbed mouse, as if I were playing the game exclusively. Bringing down the console releases the mouse, as does Alt+Tab or Super+Tab to another application.
With in_grabMouse 0 the normal cursor displays on top of the window, in addition to the TDM cursor (if on a menu screen). If the cursor is moved outside of the window, the game stops receiving mouse events, which means there is a limit to how far you can rotate the player camera. This is probably useful for testing GUIs and menus but doesn't seem that useful for actual player navigation.
-
Windowed mode + console is the only way I can get the mouse back on Linux. I think it's unavoidable: the game is capturing the mouse for freelook and does not give it back until you do something which interrupts the game, e.g. bringing down the console.
-
Linux builds don't product .obj files. The equivalent on Unix is .o
-
On 7/19/2022 at 5:18 PM, snatcher said:
I don't know if a repository containing the sounds in uncompressed format exists
It doesn't, which is a major oversight in my opinion and the reason I always encourage new sound contributors to provide uncompressed versions as well.
As a result of the initial failure to retain uncompressed versions of the original sounds, any editing or cleanup of those sounds (as another forum member did recently) has to rely on decompressing and recompressing Ogg Vorbis files, which is sub-optimal from a quality perspective.
-
2
-
-
Those guidelines sound a bit outdated to me — like they were conjured up the era of dial-up modems.
Ogg Vorbis files are not generally encoded with a specific bitrate, but with a quality factor which goes from -1 to 10. Quality of around 4 - 5 should be more or less transparent to most people, so I'd aim for this. The output bitrate will probably end up somewhere near the values given in those guidelines, but they won't match exactly, and that's fine. The important thing is the constant quality factor, which ensures that the music/SFX sounds good no matter how "complex" it is.
Ambient background music should definitely be stereo. Mono music sounds like it comes from the middle of your head whereas stereo can sound like it is all around you (i.e. "ambient"). Of course this depends on the content of the music and how it is mixed, but there is absolutely nothing to be gained by mixing down to mono in this day and age.
And if you do submit some sounds, please submit uncompressed (FLAC/WAV) versions as well as Oggs if possible. This allows the sounds to be remixed later (or used to create entirely new sounds) without introducing generation loss due to repeated compression.
-
I don't understand the seven years ago obsession either.
Maybe there is a good argument for allowing oil lamps to be blown out, and maybe there isn't. I'd be fine with it, but perhaps some mappers wouldn't. But the fact that it was discussed seven years ago is of no practical relevance that I can see.
-
1
-
-
A couple of tips that I found most helpful as a newcomer to music production:
- When trying to determine whether things sound balanced, try listening quietly. Everything always sounds better when loud, so by listening at a lower volume you make all the flaws a lot more obvious.
- Put a hard high-pass filter on absolutely every track, then push the cutoff frequency up as far as you can without ruining the sound. The only thing that should have any content in the sub-bass frequencies is the bass track, and even that should have as little as possible. Sub bass frequencies are present in everything (even your closed hihat), but just eat up space in your mix and make everything sound muddy and boomy.
-
2
-
1
-
You can't do it in DarkRadiant, but you could do it if you imported the LWO into a modelling package like Blender then exported it to a new LWO.
Whether this is a practical solution will depend upon your particular comfort level and familiarity with modelling tools.
-
1
-
-
Coincidentally I came across this "vault loop" myself only today. I liked it, but felt it was perhaps a little too heavy on the bass (which is very, very easy to do). It might benefit from either taking the bass track down a little (e.g. -3dB) or just rolling off the very low frequencies with a bit of EQ to make it fit more comfortably with the other sounds.
-
1
-
-
You could also use some of the functional textures like caulk if you only want placeholders that show in DR, however these will not show up in the game itself.
-
Oh, you mean you loaded each Ogg, edited it then saved it out directly as another Ogg? In that case it would not be reasonable to expect you to recreate each edit manually and save it out as a WAV, so Oggs will have to do. And yes, quality level 10 is perceptually lossless so it's probably OK in practice (I think the originals might have used this quality setting as well).
-
I doubt there are many (if any) such textures in the main mod distribution because they would be useless for released maps and therefore considered a waste of space. But introducing custom textures is very easy and you could probably whip up the placeholder textures you need in an image editor (or download them from elsewhere) without much difficulty.
Darkradiant install with Flatpak? (Linux)
in DarkRadiant Feedback and Development
Posted
Do you still get the render issues in the texture preview window (i.e. the view is entirely white until you resize or force a render in some way, after which it works correctly)? This was always a problem with the 3.0 wxWidgets packaged with Ubuntu.
I've been thinking about wxWidgets version recently because I upgraded to Ubuntu 22.04 last week and they are still packaging wxWidgets 3.0, even though 3.2 has been out for a long time. I'm wondering if we need a way to build using a local newer version of wxWidgets that we can include without needing to rely on the distro packages (e.g. with an optional Git submodule). Although if you're getting crashes with 3.2 it sounds like the upgrade might not be as simple as I would have hoped.