selliott4

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

1 Neutral

About selliott4

  • Rank
    Newbie
  1. Good stuff. Thanks for sharing that. With regard to diffing the IDs getting renumbered what if they IDs were stripped out before the diff? Of course you then have less information. If only each item had some ID that never got changed once set. Also, this probably means that my original goal of having maps be git mergeable won't work in most cases :-/
  2. Thanks for the feedback, but just to clarify - I was assuming that people would continue using the same WAD editors they are currently using, that part of the process would be the same. I wasn't assuming that anyone would want to update WADs by editing the text files. Only the build would handle the conversion either direction. As to people not familiar with GitHub - my post was geared toward that because I assumed that you want people to do use that process, but indeed all the current ways need to be accommodated: People doing the full GitHub pull request approach. They would just do "make submit" after their normal process when done with their edits to the levels, but before the pull request. People with commit access pushing directly to GitHub. They would just do "make submit" after their normal process when done with their edits to the levels, but before the git push. People who have the build setup, but don't use GitHub and who currently post their WADs somewhere on the internet. They would just do "make submit" after their normal process and then post the text files somewhere on the internet instead of the WAD files. People who don't have the build setup, but edit the levels anyway. This is a trickier. They'll have to get the build working, or work with wadlc and wadldc directly. That's my understanding of what people are doing. EDIT: Possibly for steps 3 and 4 the submitter would just submit the WAD files and the maintainer would put them in a build tree and do "make submit" before committing the changes. I'd totally understand if this seems too odd, but I thought I'd suggest it in case it's helpful. I agree that "Use Wadspy to output level stats" thread is a good idea regardless. By the way, do you have some way of comparing to versions of a level WAD graphically, like something that displays the changes made on a 2D image, so you can see what was done? I was assuming that was not common when I posted this. I guess that's another topic, but I have some ideas on that as well.
  3. The recent the "Wadspy output with Daily Builds" thread having to do with summarizing levels with a text file made me curious if it's possible to take the concept one step further where the level WADs could be entirely converted to and from text format. The "wadlc" and "wadldc" CLIs from xwadtools, the same GitHub Doom-Utils organization Freedoom gets its "deutex" from, are such tools. This would make it possible for the actual checked in Git resource in to be a text file, so something like "levels/map11.txt" instead of "levels/map11.wad". The build would then produce all of the "levels/*.wad" files based on the "levels/*.txt" files. There would be some other build target, maybe "submit", to go the other way to update "levels/*.txt" files based on modified "levels/*.wad" files. This would be done after editing "levels/*.wad" files. Why the additional abstraction? The levels would then be diffable and mergeable. When viewing pull requests for levels you'd be able to actually see a summary of the changes in GitHub, although cryptic. More importantly if ongoing work from multiple authors made changes to different parts of the level they could be merged by Git automatically. Diffs could be done locally as well to make sure no unintended changes were made before submitting a pull request. What do you guys think? Maybe I could look into modifying the build if there is any interest.
  4. Indeed you are right about Commander Keens and that 666 door. That addresses my first two images, and maybe the second to last one about Commander Keen. The way that stuck door works is a bit tricky - I think the map author wanted the user to think the blue skull key was needed to open the door, but actually crossing linedef 2941 is what unsticks the door at which point the ordinary blue key card works.
  5. Since I've been playing through freedoom2.wad I thought I'd share my feedback for MAP11. I couldn't find an existing "Phase 2" thread that included MAP11, so I created a new thread. If MAP11 is going to be discarded feel free to ignore my comments. I think MAP11 is a nice map other than a few inaccessible secret areas and pickups. A brief description follows each image. This stuck blue door at -1186, -2118 only opens to a height of 16 for reasons that were not obvious even after looking at it in Yadex. Doors open to the height of the lowest ceiling of the neighboring sectors minus four. Something hacked MAP11 so that the Doom engine thinks that distant sector 131, which has height 20, is a neighboring sector. Apparently this was done by adding line 857 to the lines of the sectors that makes up the door. Sadly there is no way to raise the ceiling of sector 131 due to another problem (more on that later). Also, I believe this could've been accomplished by not hacking the map - a small sector could have been added adjacent to the door with a ceiling height of 20. Do you guys know what tool did this? Also, is there a good tool that dumps all information, all IDs, etc, of a WAD so they can be examined? I had to debug the Doom engine to figure it this out, so it would be helpful in cases like this. I don't think this door, which leads to a secret area at 1315, 215 will ever open. It has tag 666, which, for some doom levels, opens when the last of a certain type of monster is killed. However, unless I'm misunderstanding p_enemy.c for Doom2 666 only does anything on MAP07. This is related to the previous problem because you need to get into this room to cross line 2941 to raise sector 131 to unstick the door shown in the previous photo. Maybe I'm overlooking something, but I think it's impossible to get this BFG at -534, -170. None of the neighboring sectors or linedefs have helpful tags or flags. I even tried rocket jumping in PrBoom+. I never left the ground. Does that work in some other Doom engine? This is a dead Commander Keen in a cage at 3547, -314 along with a dead chaingunner. The cage is lowered, but not opened, by a switch. I'm not sure what the point is. Also, Yadex lists Commander Keen as decoration, but they count as kills. Should the user have to shoot defenseless stationary decoration to get 100% kills? That seems odd to me. Likewise with the other Commander Keens on the map. This apparent door at 2256, -736 would lead outside of the map if it were a door and if the impassible flag was not set. Should there be fake doors?
  6. Litrivin, Have you figured out your Yadex build issue? What version are you trying to build? Maybe I can see if I can figure it out.
  7. Thanks for the feedback. I've updated my site to acknowledge the existing similar WADs that some of you mentioned. I'll consider uploading it to idgames, jute.
  8. I should probably start by introducing myself. I have not posted here before, but I've enjoyed exploring the forums and playing various WADs here. I'm a computer programmer in Austin, TX. Anyway, I've created a strange map that consists of a hallway with eight doors in it. The state of each door, whether it's open or closed, corresponds to one of the eight bits in a byte. The only way to get to the exit is to pass through the hall 256 times. Each pass through the hall toggles the state of the doors such that the binary value of the byte is incremented by one. Part of my motivation was my curiosity of it was possible to create a map where the total time it takes to complete it varies exponentially with the size of the map. It is possible. Since obviously it's no fun to play in the traditional sense now that I've create it I'm curious if: 1) Some of you are amused by it. Maybe some of you even think it's worthy of being in one of the mock*.wad WADs as an example of how a map shouldn't be. And that's fine. 2) It has some educational value as an fun way of introducing the binary number system to kids. Anyway, it has it's own web page: Binary In Doom