Tracker: Issueshttps://tracker.dengine.net/https://tracker.dengine.net/favicon.ico?13985035312019-12-11T06:09:44ZTracker
Redmine Doomsday Engine - Bug #2367 (New): [Unix] If directory "/usr/share/doomsday/data" exists, core pa...https://tracker.dengine.net/issues/23672019-12-11T06:09:44Zskyjake
<p>The Unix builds normally use /usr/share/doomsday as the base directory. If one manually creates a data/ subdirectory in there, Doomsday cannot find the core packages that get installed in the base directory.</p>
<p>This is because the presence of a data subdirectory is specifically checked for in app.cpp directory mappings, and it overrides the default /data folder.</p>
<p>See discussion: <a class="external" href="https://talk.dengine.net/discussion/2761/net-dengine-stdlib-not-found-ubuntu">https://talk.dengine.net/discussion/2761/net-dengine-stdlib-not-found-ubuntu</a></p> Doomsday Engine - Bug #2334 (New): Client should load server's data files when connecting via com...https://tracker.dengine.net/issues/23342019-06-24T14:40:56Zbond
<p>Add the ability to autoload the absent wads when connecting to the server from the command line (like from Doomsday UI)</p> Doomsday Engine - Feature #2192 (New): Procedural images generated based on a text file (.deimage)https://tracker.dengine.net/issues/21922017-01-10T12:54:57Zskyjake
<p>Perform one-time, load-time operations on image data to procedurally generate pixel content.</p>
<p>A ScriptedInfo file with “.deimage” file extension would be interpreted as de::ImageFile. The .deimage would then describe various layering etc. actions — in a declarative way — to generate the output of the de::ImageFile (i.e, de::Image at runtime). ScriptedInfo would enable performing load-time scripts to determine the final output size/content.</p>
<p>Such a “.deimage” could be used wherever one would use a regular image file (assuming FS2 is used for loading the image data).</p>
<p>The “.deimage” could look something like:<br /><pre>
size <512, 512>
format: rgba32
layer {
filter = grayscale
layer "background" {
path = "someimage.png"
}
layer "decal" {
opacity = 0.25
offset <25, 50>
path = "decal.png"
}
}</pre></p> Doomsday Engine - Feature #2185 (In Progress): Package repositorieshttps://tracker.dengine.net/issues/21852016-11-20T19:04:59Zskyjake
<p><strong>Remote repositories.</strong> Similar to apt repositories, web servers can set up a specific directory structure that Doomsday can then access to read a compilation of the available package metadata and download individual packages. Interestingly, thanks to (upcoming) FS2 remote folders, clients can access the server's local package cache as if it was a remote repository where packages can be automatically downloaded if necessary.</p>
<p><strong>Virtual repositories.</strong> A remote repository that looks like a regular remote repository to Doomsday, but in fact is something different like the idgames archive, where all the WADs are made available as if they were Doomsday packages so that they are accessible via the same mechanism as any other package.</p> Doomsday Engine - Bug #1980 (New): Client should refuse to use the same userdir as another alread...https://tracker.dengine.net/issues/19802015-02-16T00:19:06Zvermil
<p>When one has more than Doomsday client running on their computer at once, one get's an illegal operation message on closing one of them.</p>
<p>I pulled this out the out file:<br />^ > Mus_Start > M_Mus2Midi: Failed opening output file "dd-buffered-song1.mid" <br />MasterWorker: Received 7 servers from mas^ : Starting music 'titl'<br />ed to replace renderer.dei: existing file could not be removed.<br />[RemoveError] (DirectoryFeed::removeFile) Cannot remove "renderer.dei" in directory "%<br />HOMEPATH%\Documents\Doomsday Frontend\runtime\configs" <br />^ : Terminated by signal</p> Doomsday Engine - Feature #1647 (Progressed): Replace FS1 with FS2-based resource managementhttps://tracker.dengine.net/issues/16472013-10-31T22:26:46Zskyjake
<p>FS1 acts as an extension layer over the native file system, allowing one to look up resources and locate other needed native files. FS1 is platform-dependent.</p>
<p>In contrast, FS2 in libdeng2 is a virtual file system that completely hides the native file system. It is completely platform-independent. File objects can represent any kind of data in addition to basic native files (ZIP archives, remote data over the network, dynamically generated information, etc.).</p>
<p>At the moment FS1 is deprecated and it should be removed in favor of FS2 based resource management. Note that unlike FS1, FS2's purpose extends beyond resource management.</p>
<p>In practice, resource management done on FS2 should be package-oriented and lookups should occur via fast in-memory indices.</p>
Open questions:
<ul>
<li>How to ensure old resource packs can be used as-is? Compatibility mode?</li>
</ul>