Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited


About anotak

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. anotak

    Post Your Doom Picture (Part 2)

    lua scripts for the new lua scripting plugin. the spraypaint is 88 lines of lua including comments. if the spraypaint tool was part of a new plugin, the C# code required would be hundreds of lines. it's my hope that people can write their own scripts if they want. I wanted it to be accessible to people who are skilled enough to write ACS or ZScript. i don't know if i'm reaching that goal or not, but at least one of the mappers who i've sent it to for feedback has been sending me back some very interesting screenshots. there's many times where i'm mapping where i end up having to do a repetitive task that is too map-specific to deserve an entire plugin, yet, it's too tedious for it to make sense for a human to do it by hand. so i wanted scripting in the editor in order to help people's workflow. i'm not quite ready for a public release yet because i want to make sure the Lua->DBX API is in a stable state before people start releasing scripts. i don't want to have to break people's scripts once they're out there in the wild. regarding gzdb, i had to make changes to on the editor side to support several things. because of that, the plugin does not work at this time in gzdb-bf. if zzyzx wants to support it he can make some changes for which i'd be happy to point him in the right direction. the code in GZDB-BF/DBX at the relevant parts is similar enough that most of the things he could just copy and paste 1-to-1 probably? not all of the code is that similar though. but i definitely tried to make it so that it'd be relatively easy to support in GZDB-BF. to keep the spirit of the thread going, though: (level is valiant map01 by skillsaw)
  2. anotak

    Post Your Doom Picture (Part 2)

    workin on more tools for the next dbx version (level is an_mutt's port glacia, not one of mine)
  3. anotak

    Psychological aspects in designing areas

    this is pretty commonly known in architecture yes. i definitely do things like this on purpose with these considerations. there's all sorts of stuff like this, the often known thing is: a room seems bigger if you entered it from a small hallway. being too open feels unsafe just as being too closed in feels unsafe. i use/abuse both contrasted with "safer" areas, because mood in games only has meaning through contrast and interwoven cycles. humans emotionally crave shelter, whether it's from the rain/sun in real life, or from yet-unseen chaingunners in doom. walls and floors and ceilings give us an anchor to the world, to reality in a way. the opposite, an endless open void, is uncomfortable for this reason. open space gives us a sense that anything can come from anywhere, and that everyone can see us. that particular sense of discomfort, that "everyone can see me" is pretty deep rooted. you'll notice that in real life when people go to a central meeting place, they tend to gather around the edges of the space looking inward. someone in the middle of this room may feel subtly uncomfortable, a sense of, "they're all staring at me". by contrast, when the walls and ceilings get too close, you begin to worry about running out of air. there is a sensation that the place could just crush you at any moment. it also gives a sense of the unknown, that you cannot see what's around the next corner, or what's above or below you. you feel trapped. it is in a sense the opposite of the previous statement about open spaces where "everyone can see me", now "nobody can see me, and therefore nobody can come help". it can be easier to get lost in a space like this, because you can't keep track of landmarks as well, and this leads to confusion. however, it also can be easier to find your way if you have less choices of where to go. you may find this interesting:
  4. anotak

    lilith.pk3 - /idgames release!

    dunno if a resource wad will interest people but here you go. text file here. this includes a bunch of 'new' glitched textures that aren't in lilith.pk3
  5. if you get a message like that with dbx, it should produce a logfile if you open a new explorer window and type %LOCALAPPDATA%\Doom Builder up top, there should be a file called BuilderX-lastcrash.log please post it, so that i can try to fix whatever problems happen.
  6. anotak

    PNAMES/TEXTURE1/2 sucks.

    a little update on having >8 char texture names in dbx, me and bmsq on github may have arrived at an appropriate workaround to the issue. see here for technical information: https://github.com/anotak/doombuilderx/issues/6
  7. just as a rule: default hotkeys are not ever changing btw, barring some very bizarre circumstances. i may add an ability to bind a 2nd hotkey to stuff though, if i ever can get over some of the implementation annoyances
  8. oh, to be clear, i'd appreciate any feedback on the thing about changing the default missing-texture. of course, i'd only change it if i also add a way for the user to set it, and include the old one for people who want to still use the old one. random thought 2: i'm thinking of changing the names of join/merge sector because it's really not clear what the difference is a lot of the time to people. i always have to doublecheck which is which, myself (merge removes lines that were on the edges of both sectors). some suggestions i got on discord were "join/superjoin" and "join/union".
  9. it's definitely on the list, i will keep it in mind i have been also thinking of replacing the default with something similar as to not mess up people who are used to it but maybe with some blue/purple tint to the red to help differentiate from the default doom palette and help people who are red/green colorblind.
  10. anotak

    Need testers for Eureka DOOM Editor

    i'm on 1080p it seems to scale not with drawn pixels but with amount of geometry & things edit: for example this size screen is still very slow
  11. anotak

    Need testers for Eureka DOOM Editor

    just poking around some, never used this editor before middle-click drag scrolling seems choppy on my machine (windows 10, i5-3450, radeon hd 7800something). also possibly delayed, but that may have to do with it just being choppy. perception is tricky. ok something is definitely slow. loading choz.wad renders the editor nearly unusably slow on my machine while just moving the mouse around. other wads that i use to test my editor sometimes like rebelsky.wad and port_glacia.wad seem very slow too. nuts.wad seems quite bad in things mode too, and bad if i view the whole map in lines/vertices mode but not bad if i zoom in a lot. port_glacia seems to be irrespective of zoom level. i guess this is tied to renderering, after some testing, as choz.wad isnt so bad if i zoom into a part of the void. regarding the delay, here's a little video clip you might not be able to do much about this. no matter what any application's stuff always going to be at least a frame away from the Windows cursor? so some delay is expected. however, this seems like more? and again, that might just be tied to the how long it's taking to redraw everything. also i seemed to get what appears to be a weird triangulation bug?: also, what's with the blank space between these menu options? (i'm on 125% scaling on windows 10 if that matters): otherwise everything seems to work, nice. hope these reports help
  12. anotak

    Post Your Doom Picture (Part 2)

    ah shit i should've said, geometry is from sunlust MAP07
  13. anotak

    PNAMES/TEXTURE1/2 sucks.

    so it uses a hashing function (Murmur2 in particular) to get filenames to be represented by 64 bits i thought about doing this before. i originally just discarded the idea because there is no real way of handling a hash collision (within DB's existing architecture, i mean). i didn't think about the fact that maybe a collision is so unlikely that it's not worth worrying about too much? but i'm not sure i love that approach. after doing quite a bit of math myself and then finally remembering enough about probability to come up with the right search terms, i found the correct answers. so, like, if you have 6100 textures your probability of a collision is 10 to the -12th. and the consequences of a collision are unclear? i'm not sure i want to unleash a hard-to-track-down bug that has a chance to wreck someone's map with a 1 in some near-trillionish chance? and that's assuming the Murmur2 hash used produces entirely uniform values. which, this is quite a bit outside my area of expertise, but i suspect it does not (?). in which case the probability of a collision goes up? maybe? how much? i don't really know? a quick google gives this stackoverflow answer, but unfortunately it is about the 32bit version of Murmur2, which is unhelpful. there's stuff like this, which might affect things? apparently there's a Murmur3, which fixes that particular flaw. and if the probability is much higher, how easy would it be to debug the resulting problems? seems like a nasty can of worms there's also just the whole, calculating-a-hash-thing isn't free, and one of my goals with DBX has always been performance. i haven't measured how this affects things at all though, and my instinct says it's "almost free", but i know better than to trust my instincts on this kind of thing, it must be measured. idk, i'll have to think on this. i really don't love the idea of "bad things happen but only this tiny percent of the time, and that's fine and we accept it". edit: and yes, hash collisions are a solvable problem, but i have to fight other conflicting aspects here (the Plugin API, my own time/effort put in, etc). i'd have to rewrite a loooot of stuff it seems. as far as i can tell, MAX-ED just didn't worry about it in GZDB.
  14. anotak

    PNAMES/TEXTURE1/2 sucks.

    if this doesnt turn into a bikeshedding festival by tomorrow if theres some solution, i could probably do the work on dbx to support any option that isnt horrible (or would be cool w maintaining it if someone else implements it) however having texture names be longer than 8 characters would be a clusterfuck to support in the doom builder 2 family of editors (and probably other software). a lot of stuff relies on being able to treat the texture names like unique 64-bit numbers (because that's what 8 characters is, actually). that intersects with with the whole maintaining-compatibility-with-the-existing-plugin-api-thing. i know this sounds silly, but, it's by far the most infeasible thing in your post. edit: fuck it here's my anti-bikeshedding measure if u can get me to agree about a standard with one (1) person who will actually implement it into a non-zdoom port (so 2 total people, counting me) then i will implement it into dbx