• Content count

  • Joined

  • Last visited

About traversd

  • Rank
    Forum Regular

Recent Profile Visitors

584 profile views
  1. BYTESIZE MAP06 ... & MAP07
  2. BYTESIZE MAP02 - Currently untitled and skill settings not yet implemented. Debating on whether or not the plasma gun is "too soon" for the map set /shrug Complevel 9 (tested in GZD, PRB+, E and DR)
  3. Hi Brad, Something I noticed while making a new map is that Boom special 242 appears to have some issues when the sector (and the dummy sector) change heights. I've attached a demo map that uses 242 and 53 (W1-Start moving floors). It seems that the target sector will only mirror the dummy sector dynamically if the dummy sector is also visible on screen. In the demo map you should see that if you view both platforms it is fine. Turn left to only view the yellow skull plat and it stops moving, but then jumps to whichever state the dummy sector is if you then view both plats again. This was checked with 2.5.5 Thanks, Travers
  4. WTH. How have I not realised this awful pattern sooner? #rehash











    1. rodster


      I didn't understand, but I like the pictures, because it looks like the spidermind is going to fall/roll into the square holes :)

    2. esselfortium


      I think I would be pretty freaked out in real life if I saw this many giant spiders angrily crawling out of holes, but these pictures make me chuckle :)


      It's funny to only notice something like this 20 years on. I like the mega-effort moving trapdoor one from 1994tu.

    3. Captain Ventris

      Captain Ventris

      A monster...basement?

  5. The 100 linedef limited map pack (I've slowly been tinkering away at) now has the working title "BYTE-SIZE". This is the latest addition - MAP01 ENTRYPOINT EDIT: This map is Boom compatible; complevel 9 (hopefully the d/l works better than the super unoriginal map name) NB: There is a visual glitch in the "elevator" when using GZDoom that I haven't been able to address.
  6. Sorry if I missed it in earlier posts. Is this a vanilla only trick or includes boom/mbf.. other ports?
  7. Another option: At the start of the map implement the (gross hack) of merging sector type 11 below a -20 damaging floor and tag both sectors to crush the player as well. That should allow the player to get to <11% health without dying pretty quickly. You may need to give them an invul before exiting that setup so they don't get crushed on exit or something. Then keep using damaging floor types throughout the map and use the invuls as described above. EDIT: test the crusher a bit first though as it may push the player into the floor of the sector with type 11 and exit the map :)
  8. CL666 and if it gets updated CL667 (and then never more can it be updated)
  9. Hit the 100 linedef limit. Move a vertex and find a 0 length linedef. /cartwheels

    1. Breezeep


      100 linedef limit? Are you making something for some kind of limitation project?

    2. traversd


      Eventually should have a small pack (~9?) of somewhat randomly themed maps that are limited to 100 linedefs. Working on a map07 arena at the moment. I've got 2 others that are ready for a play test linked in the post below.



    3. rdwpa


      I did a casual max for the 9c map a week ago but forgot about it until now. 


    4. traversd


      Nice! Thanks! Still too many cell packs it seems

  10. Not sure if these are ready for a separate thread. A couple of almost complete maps made with the 100 linedefs restriction. "bd2" was made during the original 100 lines project. "9c" is more recent. They require complevel 9 and have been (hastily) tested in prboom+, GZDoom, Eternity and DoomRetro so far. Feedback is welcomed :o) Thanks, Travers
  11. Perhaps some of the seemingly too grandiose/unwieldly/however they may be viewed proposals can be distilled/evolved into something of purpose though? WRT Wesley's proposal: Instead of implementing it as a whole new routine that would traverse a tree of linedefs with various condition checking along the way (a system/framework) - perhaps it could be simplified to a handful of new linedefs specials that can operate in relative isolation whereby they simply trigger any linedefs with a special type found within a tagged sector? @kb1 asked for an example picture of this earlier so I've put this below. In the image we use a single switch(tag1) which would use a proposed new type of linedef special that activates any linedef types found in the tagged sector(also tag1). In the example below this causes a door to open (tag3), a floor texture to change (tag2), a sector to go to 255 brightness (also tag2) and a sector to go to 0 brightness (tag4). It is important to note that with the exception of the initial switch, all the other linedef specials already exist. The end result is inset in the picture showing the texture and light level changes. Some additional points to this modified-version of Wesley's proposal: Wesley's concept of a "delay" modifier could be implemented by using the light value of the tagged sector (because in most cases this is going to be a dummy sector away from general gameplay access). The value could be either taken as seconds or tics I suppose as 32767 = ~15mins I think in tics? I don't think a "speed" modifier is as easily achievable as the speed of an action sits within the actions itself If the new linedef type is implemented such that it can trigger other linedefs with the same new special type you could then chain them together which would be beneficial for triggering multiple "change tex+type" actions together.
  12. That is kind of the Boom "standard" already though isn't it? Is your preference to add scripting Graf? I recall you mentioned D64 macros earlier. Sorry, I think you've indicated this in the comments above but I'm not following which way it means.
  13. Map author view: Using a sector based modifier/property is not as flexible as applying the same modifier as a linedef action occurs. That way you can have multiple actions on the same sector, but some are silent, others not.
  14. I'll see what I can mock up in PAINT.NET over the weekend.
  15. I can see it being of benefit if it is (vocabulary fail) changed to affect linedefs indirectly. So instead of affecting linedefs with the same tag, it affect linedefs found in tagged sector. This will allow a map author to construct the custom actions and even use them with conveyor scripts for sequences by putting the new trigger linedefs in a conveyor script which then calls the custom action built in a sector to the side. Hope that makes sense. It needs to avoid affecting linedefs directly as that is where you get clashes and would only be able to set 1 kind of delay, 1 kind of speed modifier. By targeting a "parent" sector in which our child linedefs exist we can then do any number of custom actions for the same sector.