-
Content count
1586 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
News
Everything posted by GoneAway
-
DSDA page NoYe A boom-compatible wad put together by members of the speed discord. Enjoy! idgames Put your demos in this thread. Here are some gems to start with: Map 11 Ballerina in 0:17 by Elmle Map 11 Ballerina Reality in 0:19 by Kraflab Map 11 Ballerina in 0:34 by 4shockblast noye.zip ny11ball017.zip ny11ballr019.zip ny11ball034.zip
-
This thread is for demos to be uploaded to the new dsda prototype, but that are not hosted on the current dsda. Distinction no longer necessary :^) This thread is for miscellaneous heretic and hexen pwad demos. Put vanilla heretic runs fit for heretic-n into the heretic thread! Heretic Amplified E7M1 SM Speed in 1:39 ZDoom v2.8.1 h7a1-139.zip
-
DSDA page aka zone400 Here ye, here ye, pcorf has blessed us with another wad. Post your demos here. File code z4. This wad is vanilla: complevel 2, crispy, etc. Zone 400 Map 01 UV Speed in 0:32 z401-032.zip
-
THT: Threnody Map 01 Pacifist in 0:27 th01p027.zip
-
DSDA page aka estrangd // estrangd.wad Foodle’s phenomenal addition to the roster of classic megawads combines fast and furious gameplay reminiscent of Scythe and Memento Mori with simple yet evocative aesthetics! These maps feature excellent gameplay flow with consistent action, they are exciting to speedrun as the layouts complement speeding through subsequent rooms aggressively, springing several traps and blazing past hordes, definitely one of my favourites from 2015. (Introduction stolen from Krypto's post. Thanks for the eloquent description, Krypto!) -------------------------------- Estranged Pacifist ILs 05 in 0:35 (video) *11 in 0:36 (video) *15 in 2:08 (video) 16 in 1:41 (video) 21 in 0:13 (video) *26 in 1:52 (video) 31 in 0:07 32 in 1:08 (video) * = desync in final version kraflab-estranged.zip
-
DSDA page Sargasso Map 01 Pacifist in 0:33 sg01p033.zip
-
For those who aren't aware, we've been working on a replacement for DSDA off and on for the past two and a half years. The main reasons for this undertaking were: Andy shouldn't need to shoulder the burden of maintaining the archive forever The existing archive has some important omissions (notably, heretic and hexen) The existing archive has limited information in some respects (e.g., time in tics) The goal was to support the missing demos, create an archive that can be maintained by a team of people, and pull a ton of data from the existing demos. That is, to resolve the 3 points I just listed. This undertaking is a 4 step process: Develop the new backend / frontend Import all the demos, up to a point, including extracting the new details we wanted from each of them Reach a point where we are mirroring Andy's DSDA weekly, based on his updates Start pushing the demos ourselves (i.e., without Andy's support) I'm proud to say that we have finally completed step 3! The archive is now mirroring Andy's DSDA and considered usable for the general public. You can find the archive here: https://www.dsdarchive.com/ Some important notes: I am not the new Andy. One of the main points of this project is to distribute the work among a team of people (this will be more fleshed out as step 4 starts moving along). The archive is still missing a bunch of demos. We have a list of a lot that are missing, so please hold off on reporting absences for the time being. We'll update you when we no longer know what is missing. There are lots of small errors. Due to the volume, the work had to be automated to a large extent via various tools and scripts, and inevitably things may be wrong. This could include run timing, dates, categories, etc. So far, we are identifying issues and fixing things in bulk, but there may be small things that we don't notice. Please, if you see an error, let us know in this thread. There is a lot of manual work that is going on that will fix some of the omissions. For example, lots of comments are missing. We're aware of this, so don't worry about reporting that for now. What is changed? Demos are now sorted by tics (when possible). When there is a tie to the second, there is a symbol indicating who was the "first" to that time, and another for who is the fastest by tics. This is particularly useful for something like n1o1, but most of the time it's not relevant. For n1o1, Looper has the fastest time by tics, but Ocelot was the first to get an 8, so both are recognized achievements in the table. Some categories have cross-listing. If you look at doom e1m1 UV Speed for instance, shock's 8s pacifist run will appear in the table. This reduces confusion when it comes to the speed record on various maps. Runs with many entries have a "record timeline", which shows the evolution of the record over time. This plot seems to not work in some browsers, and the dates themselves are of course largely estimated, so sometimes the plot isn't particularly enlightening, but it's a work in progress. Example: https://www.dsdarchive.com/record_timeline?category=NoMo&id=doom&level=E1M1 Stats are expanded. Since we have the dates that demos are recorded, we can do some fun plots. You can look at the demo count per year by player, wad, or across the whole archive. Incompatible demos are in the Other category. This only applies to specific wads, like the IWADs. What this means is a UV Speed ZDoom demo for doom will now show up under Other, with the comment "Incompatible UV Speed". This procedure will probably be extended to things with the wrong complevel, but it hasn't been taken that far yet. Wads now have a "Table View" that shows only the best times for each map, for a category. This is useful if you want to check, e.g., which maps still need a max. Example: https://www.dsdarchive.com/wads/doom/table_view Heretic, hexen, zandronum, etc are all supported Instead of weekly updates, there is a feed that shows the latest demos in the order of upload There is a search feature for players / wads URLs are simplified: '/wads/doom' and '/players/kraflab' There is an intro page with lots of details helpful for new players (more of these kinds of pages and guides are planned) Videos are linked to demos when possible Stroller and Collector are now separate categories from Pacifist and NoMo. Collector is kind of an odd choice, but there were historically a lot of demos for it, so I decided to split it off for now. FDAs aren't hosted. Probably more that I am forgetting. What is planned? Leaderboard views to show a ranking for a given run separately from the main table. API Different views / styles Various improvements to all of the above, as many things are still in a WIP state A convenient way for anyone else to synchronize a local copy of the archive A lot of other things that are still being discussed, so I won't commit to anything ;) Please, give the archive a look through and let us know if you have any issues. For now though, Andy's archive should still be considered the source of truth! This could not be possible without the months of work @ZeroMaster010 put into parsing Andy's archive and extracting all the data from the demos (which included, e.g., automating playback through prboom+ in order to extract precise timing, and estimating the recording date of every demo). In addition, I'd like to thank the following people for helping in various capacities (I'm sure there are more, apologies if I missed you): @4shockblast @Andy Olivera @eLim @JCD @Keyboard_Doomer @Opulent @PVS @veovisRC @TheLoneliness Everyone in the discord, for various discussions
-
Hello everyone :^) Introducing the dsda-doom source port, which is a fork of prboom+um. The focus is on tooling that is important for our automation work on the archive, quality-of-life improvements for demo recording, and fun additions to the demo playback experience. The project is over here: https://github.com/kraflab/dsda-doom You can report bugs at the Github link above, or on the Discord: here
-
Hello everyone! Previously I opened a thread about adding a new complevel, here. After 2 months of work we are happy to announce the release. Modder's Best Friend aka MBF21 Check out the full specification on github. The spec is fully implemented in dsda-doom, with work well on the way in woof (probably pr+ after that). Eternity, odamex, and doom retro support is planned as well (and probably more ports I don't know about). There is a version of the spec on github aimed at developers with links to code and commits to help with adoption. As far as tools, the latest build of UDB includes MBF21 as an optional configuration you can enable that includes the line and sector additions. DECOHack support for the new codepointers and various dehacked additions is ongoing as well. More to come! This wouldn't have been possible without support and ideas from the community at large, but especially the core team of collaborators: @AlexMax, @Altazimuth, @dew, @Keyboard_Doomer, @MTrop, @skillsaw, and @Xaser! Take a look at the spec and let us know if you run into any issues. Please enjoy! v1.1 Update: - Scrolling speed of the new specials is divided by 8 for more fine-grained control. v1.2 Update: - Added FULLVOLSOUNDS thing flag
-
I've decided to stop frequenting doomworld. I've opened up issues in the repo for anyone that doesn't hang out in the discord, and I'll continue to post builds in both of those places. It's not the misinformation campaign or the disingenuous clout chasing that bothers me, nor even what I can only describe as antispeedrunner bigotry, but the fact that that behaviour is welcomed and celebrated in the wider forum that I find so disappointing. Ultimately I don't care enough to continue putting up with that and don't have much interest in sticking around for it. You win this round 🤷
-
[MBF21 CP] DIY - Getting imaginative with simple colors. [Now on IDGAMES]
GoneAway replied to ViolentBeetle's topic in Community Projects
I'm looking into the crash in dsda-doom right now. It's caused by the face replacements but I'm not sure exactly why yet. Deleting all of them (STFST* etc) prevents the crashing. Is there anything special about these replacements? Are they all the typical size? -
The "h" is "horizontal", as in left / right. So an offset of 10 should shift the starting location to the player's side by 10 units. The 90 degree rotation calculates that location.
-
I'll be expanding the available console commands in dsda-doom in the next release and am curious what kinds of things everyone currently uses their in-game consoles for. Which commands do you use most often? Commands from other ports or even from other games would be of interest.
-
If "scale crosshair" is on, then the crosshair increases in size with resolution to cover the same fraction of the screen as it does at low res. If it's off, then it looks "smaller" at high res because it isn't being scaled up to match. But at 200p, it is at the base size, so the scale factor is 1 (no difference if option is on or not). It looks like it's all working correctly on my end. For the super low resolution, it could be worth adding a 1 pixel dot variant. I think the existing one is 3x3.
-
Thanks for all the ideas :^) Some stuff that's already implemented for the upcoming release: - add / remove keys - add / remove powers - add weapons (need to look into how removing will work) - all the cheats - add / set ammo values - set health / armor (this was there already) - binding keys to console commands (tested this out with "noclip;fly;iddqd" for instance) - loading and running script files - demo playback navigation (jump to a time or move forward / backward by a time) - some basic feedback (command invalid etc) - pressing up restores the last command (full up / down history forthcoming) Most of the stuff in here looks doable and should be added eventually. Reconfiguring settings in the console is a monster I want to approach at some point but it may require a lot of refactoring, since the console will need to know which settings need to cause side effects when they are changed (e.g., reinitializing graphics). I might start with a limited implementation of the settings that are simple (mouse sensitivity for instance). I need to do a sweep over usability as well, since the console is basically implemented in the simplest and most limited way possible right now :^) @Doomkid FHSHH: is this just about disabling line-of-sight checks for monsters that are inactive or does it also disable the proximity wakeup when you bump into monsters?
-
The port can only explain an error if it's anticipated and caught by the software. A generic exception like a segmentation fault for instance doesn't have the context in a regular release build to explain itself in a helpful way. There are lots of ways dehacked files can crash due to how flexible the code pointers are and a lack of comprehensive validations (as an example). If you post your wad either here or in the editing section, someone may be able to see the issue right away. If you still have a problem let me know and I will figure it out on the code side.
-
You said that I only listen to speedrunners, and that I'm being dishonest about it. Where? I don't remember ignoring the whole community and listening to speedrunners only when organizing mbf21, or when planning out new features for this port, or when thinking about the future. I've spent a lot of energy thinking about how to lift up all ports and approach standards that everyone can enjoy, regardless of playstyle, regardless of port even, working with other source port authors and developers that aren't related to speedrunning. I just don't understand why are you demonizing me for something I haven't even done. Own what you say.
-
I don't understand why essel and associates are pushing this narrative that I don't like mappers and nonspeedrunners. Is the goal to get rid of the source port? What exactly is your purpose to make such disingenuous posts? I got completely demotivated after being called an enemy of mapping earlier this year and haven't been able to get interested in working on any new standard stuff.
-
Where did I complain about nonspeedrunners being in the thread? My problem is if nonspeedrunners want to tell us how speedrunning should work - a topic that isn't even the subject of this thread. Should I come in and tell you how btsx should be made or how mapping should work? I have no problem with anyone's opinion on endoom. Obviously for speedrunning topics the actual speedrunners are going to be considered more heavily because they have stake in it.
-
Now that someone has puked their ignorant, self-important, and irrelevant opinions on speedrunning into a completely unrelated thread I have finally completed my bingo card. "oh a thread about endoom, better go on a diatribe about modern speedrunning, a community I'm not even a part of"
-
You're misunderstanding the situation entirely. My removal of this feature has nothing to do with what anyone else thinks and is purely the result of the rationale I posted near the start of this thread. It isn't happening because any person or any group of people want or don't want the feature to be removed. The objections by any person or group are not being valued more or less than any other group. There are also speedrunners who like this feature - obviously, because as I said it has nothing specific to do with speedrunning and thus affects all players equally. Some people just love to have an us vs them narrative to play out their fantasies in an internet forum.
-
It's not a zero-sum game and the groups aren't separate. Most speedrunners also play the game casually, and many are also mappers (including me). Furthermore, the "speedrunning features" are often things that benefit everyone (e.g., rewind, extended hud). Endoom doesn't have any relationship to speedrunning. Removing it is not a "pro speedrunning" decision and I don't know how the conversation got there. The outcome of this has nothing to do with anything being brought up right now. Evidently, my focus on speedrunning features and quality of life has created a port that also appeals to casual players. The design philosophy hasn't changed, so I find it unlikely that the outcome will change.
-
I find it frankly disgusting to suggest that I only listen to speedrunners. I've implemented various features specifically for mappers and casual players that have no relevance for speedrunning, as well as dedicated substantial time debugging issues with dehacked or other lumps for mappers. Those requests have often come in through the forums. Since I don't have a lack of things to do, I don't really need more streams of communication. Kinsie is being dismissed for their absurdly disingenuous post, not because they aren't a speedrunner.
-
I don't remove features just because of personal preference - I listed it as a criteria because it would be a reason to keep something that otherwise wouldn't be worth keeping. Like the ghost feature is not exactly critical to the port, but it's something fun that I wanted to make. I obviously consider what players think and what they want when making these decisions. For instance, I would love to delete the full screen advanced hud, or to remove mouselook, but that would be particularly disruptive to how many players play the game. ENDOOM in contrast is something that many players don't even know about. It's inanity, not insanity, it wasn't a typo :^) The fact of the matter is that people do report issues, they do get fixed, and the port is going strong with this process for a year and a half at this point. There are also features that I wanted to remove but ultimately didn't because of the objections and following discussions. What works for you works for you, and this is what works for me. The vast majority of important discussion about dsda-doom doesn't happen on doomworld or on github anyway, it happens on the speedrunning discord. We often discuss and resolve issues there directly, and I track a backlog, so maybe you are just not seeing the whole picture. Of course there are also people reporting things on the forum, and I'm thankful for that as well.
-
You consider the main menu and interface to not be part of the game? You're genuinely left wondering and don't understand how that might be different than a screen that pops up after the user has exited the port? This descent into inanity is why I usually don't engage with these topics and don't track issues on the repo. It's good to have a reminder again.