• Content count

  • Joined

  • Last visited

1 Follower

About arkore

  • Rank
  1. Authenticity of game/level design, following a standard set of guidelines of planning, testing, and polishing.  Like the Nintendo 8-bit era.  Is your design authentic?

    1. Phade102


      They are 'guidelines' not 'must do's'. Its a typical way to go, plan, test, polish. however, in doom mapping you're forgetting one thing.




      Building the map, testing it yourself, making sure the map works to be tested by others, then taking peoples critique and deciding what to do with it is what makes a map good, but even if people dont do that doesn't make the map any less authentic.

  2. I've created a fan video of Complex Doom + LCA + RM; footage from a 20-man mission, lead by pro player, Demigod. As marines acquire gear and powerups, they become more of a threat to Hell. Higher tiered monsters begin spawning in place, in real-time. Note: Sorry about the audio at the start. If someone would like to make an index of scenes with #:## timestamps, that'd be great. For example, it can start with item: - 1:30 - True Legendary Cyberdemon
  3. Okay, I found the problem. Someone added a line to SNDINFO that was meant to be $random, but forgot to $random at the start. The line was: Foo/Attack { FooAtk1 FooAtk2 } Should be: $random Foo/Attack { FooAtk1 FooAtk2 } --- This caused all sounds after that line to break. Either the problem was that, or something else happened on my machine (I rebooted?) that made Slade suddenly work and therefore this is one big coincidence. --- Thanks,
  4. Suddenly I have found myself unable to play audio files(.wav, .ogg, .mp3) in Slade v3.1.0.5. These were working fine days ago. I'm on Win10 x64. How do I troubleshoot this issue? FYI, I got MIDI working(which has never worked) now by selecting choriumreva.sf2 as my soundfont, thanks to the thread (mentioned below). There is a doomworld forum thread about this, and it's the only resource I found on the subject. "SLADE v3.1.1.1 - Audio Won't Play -"
  5. I don't see why an entirely new maps are needed to achieve "no keys/imps" Just edit previous maps, and make the necessary adjustments.
  6. Couldn't agree more. I prefer pixel art over high-res any day, because really, pixel art is an Art. Despite the conversions not being as crisp as hand-made, I would still prefer pixelated conversions of these sprites.
  7. Sorry it took so long, but I've updated this map now. I believe I've addressed everyone's feedback in this update. It's probably too late, but at least I know I addressed everyone's feedback and can now consider this map/project finished. Thanks,
  8. Thanks guys. Well, I guess so; that is, if GZDoom: Doom (Doom Format) includes all the features of Boom, then yes. I guess my problem with that, is I don't know which features are "Boom only" if I were to starting working in GZDoom: Doom (Doom format). For example, if I look at a sector's Generalized settings, the dropdowns/options available are quite different(when on GZDoom format) than what they are if I was in Boom format. My problem would be that I may start using a feature, and not realize it that that feature is not Boom. I suppose I can get around this problem by continously testing and testing, but I find it more comfortable to just stick with Boom format(config) and have only those features listed in the dropdowns and such. Would be cool if GZDB could label or highlight each feature as what engines it is compatible with, but I guess that would be difficult for the GZDB developer/programmer to do since it would require custom dropdown(select) menus and such. All in all, I guess I'll have to live with using Boom in GZDB and therefore not having GLDEFS(Dynamic lights) showing up in GZDB. Well, from what I can see, those support files already exist. If you look in Configurations/Includes/ folder, you see the Boom_*.cfg files there already. Strange that GZDB has those, but doesn't have Configuration/Boom.cfg to begin with(which is why I copied this from DB2). If I did that, then I would lose the GZDoom configs, based on this comparison report I see: -- I don't understand why GZDB comes with it's only set of Configuration *.cfg files, despite the fact that they look very similar in nature(which is expect, since GZDB is based off DB2 anyways). Why GZDB doesn't have all the config files that DB2 has, and has only 3 config files that are called GZDoom. Is this because of what plums said (above) where "GZDoom" is only a name that GZDB uses to identify configs for mapping in GZDB? I thought "GZDoom" was an engine port as well, but I guess not. Either way, I think this is strange for GZDB to do. Why you need "GZDoom" branded config files for GZDB? lol. But even if this were to swap the folders like that, I couldn't possibly believe this would work flawlessly. I have to assume that this would inadvertently cause other hidden problems. Yeah. I just think it would be nice for GZDB to display dynamic lighting anyways regardless of what format you're using. I don't see why it's a problem. Would be nice to know what dynamic lighting would look like (in your Boom project) because you know your project will get played on other engines as well(that other people use). Exactly.
  9. I see new projects starting, and they announce to mappers "must be Boom format" Well, I see "Boom" map format available in DB2 (from Boom.cfg), but I don't see it in GZDB. I copied Boom.cfg from DB2 to GZDB, but now GZDB shows error "Unable to load GLDEFS: Map type unknown" --- I understand that GLDEFS cannot be loaded for Boom format in GZDB, since Boom engine doesn't support opengl dynamic lighting. But, given the fact that the project can be played on other doom engines that are opengl and do display dynamic lights, it would be nice to see dynamic lights in GZDB as well, so I just know what it "would look like" for dynamic lights from Light Source Things such as torches. The only Map format that works (for showing dynamic lights in GZDB) is GZDoom map format. But GZDoom map format is not same as Boom map format, despite the fact that a map(saved as GZDoom map format) can still run in prboom-plus engine. Well, I've already started my project in Boom format. Should I continue using Boom format (from Boom.cfg) in GZDB? I won't have dynamic lights functionality in GZDB, but I guess I can live with that. But, should I continue on the route I've gone? Am I doing this right? I want my project to be, what's known as "Boom compatible"(which I don't entirely know what this means or entails), because that's what appears to be trending now and I believe it means that the project is vanilla-like in the sense that it will run on most engines. I'm essentially looking to have my project be vanilla(but still breaking vanilla limits) compatible in the sense that it will run on most engines today, and I'm not using UDMF or anything; my project will be a standard "Doom format" project with whatever linedefs that are available for that format.
  10. "Most feature suggestions I get are not worth the trouble and many are simply ridiculous, so they are getting annoying. If you think you have some great idea that you absolutely have to post here, then make sure you back it up with a very strong argument why it is useful to all map authors (not just you and your friend) and why it belongs in Doom Builder." Heh. Also, I posted my feature request just now, and the board says that a moderator must now approve it. LOL. They seem to be mad with the whole "feature request" thing. Wish me luck!
  11. I feel so dumb. You're right, Memfis. I just realized/found this the same time you posted your post here. Feature Requests Forum: I didn't click "Doombuilder Forums" before, when I visited the DB contact page. lol
  12. Anywhere I go to find an answer, I end up back at the website. So, when I click "Contact" there, it says to just go to the doom sites such as I found: but it doesn't seem like an area where I can submit an "Issue" like what bitbucket or github are. --- I'm looking to suggest a feature of where DB offers the option to save settings & configuration to same folder as DB, rather saving to Users/AppData/Local/Doom Builder. Some software installers offer this option, and even the Zandronum (port) installer offers it as well. I have a bunch of portable software installed on my Dropbox, and having the configuration be saved in the same folder as the software would be great, as it then means everything is all backed up for me.
  13. Wow, thank you for whatever time you spent on fixing my wad. I feel bad about my previous response; and I really appreciate you taking an interest in my project and looking into my issues. I wish I could make this work for you (support vanilla engines), but I just can't find the time/energy to do so right now. I hope you're willing to play a modern engine and give this a serious play-through though. Thanks again.
  14. Oh I see. Strange. I followed a basic tutorial for adding custom textures to a wad, and it all worked. It seemed to me I was doing everything right--in a vanilla sense. It seemed like a classic tutorial, from vanilla days. So... I don't quite understand what you're saying, or what the problem is; and to be honest, I really can't be bothered to figure it out. I'm kind of getting sick of this. I thought mapping for vanilla doom would be easy; but apparently it isn't. I guess I'll just remove the "this wad is a vanilla wad" statement from my posts, because I don't have time to figure out stupid issues like this; isn't worth my time. Sorry for the inconvenience. --- See next page (PAGE 2) -->