• Content count

  • Joined

  • Last visited


About wesleyjohnson

  • Rank
    Senior Member
  1. Cosmetic stuff ... Not very good reasons for such a bad opinion. DoomLegacy only stretches the title pics to fit, not the play screens. Midi missing one instrument on Windows is due to the bad default midi player instruments shipped with Windows. Been over that before. No problems with midi on Linux. DoomLegacy is being supported on Linux, and some other operating systems. I am developing on Linux 4.4.38. DoomLegacy 1.47 is being readied for release, probably in the next month. Will play Heretic and MBF wads too. Exactly what OS. Crashing on Linux could be due to running an old binary with newer incompatible libraries. Get source and compile it yourself. Then it will match your libraries.
  2. Jumping discussion: If a mapper specifies a jump height then it does not matter at all what all the ports have as their defaults. It does not matter if it matches any of them. If the mapper does not specify a jump height then the port can use its default. Jump height should be an integer, related somehow to a height range. This then can be used to index a table of fixed point impuses to apply as momentum. Using a table this way makes it easy to tune the jump heights. Then just share that table with all the port authors. The mapper does not care about momentum impluses. They have a ledge at 14 units and want to specify that the jump can get the player up there. If the specified number is the actual jump height needed, then that saves the mapper from having to translate their needed jump height to some arbitrary index. What I would do in DoomLegacy is to have additional tables for difficulty. So at EASY, I give them a little more jump height.
  3. If you want low-gravity jumping, you should really change the gravity instead. Otherwise the player does not fall off ledges or fall back down at the related speed. It would not be low-gravity. There could be port compatibility settings. But, for mappers who have to have a certain height jump, it would be simpler to have them specify the jump height needed and let the port take it from there. There is less looking up port specifics. I am still 2 pages behind reading this.
  4. I wondering how many other users are affected by this bug. I have observed that DoomLegacy with OpenGL, using splitscreen, will draw the lower screen over the upper screen. My test is: > doomlegacy -opengl -game doom2 Select two player game, and start server. If you have the OpenGL bug, at the game start the lower screen will be drawn over the upper screen. Turning the player2 sideways or moving him back and forth will expose the upper screen. This works perfectly on my other machines and Linux 2.6, but is failing on my latest Linux 4.4. I have traced this to a failing call to glViewport. In a test I set the viewport to a smaller window, but the call is completely ignored by OpenGL. It appears that the draw window is only set to fullscreen size. I have a new install of Linux 4.4, Slackware 14.2, using Nouveau for a nVidia card. My older Linux 2.6 uses an obsolete nVidia proprietary driver that has major problems even with Linux 2.6. They use different OpenGL packages. Does anyone else experience this bug, because otherwise I would have to suspect it just my machine. An internet search shows that others have experienced a failure of the glViewport function. Thank You.
  5. I cannot register or post on https://invisioncommunity.com/forums/ as they require reCaptcha, which only works on the latest two versions of Firefox or Chrome, neither which will work on this machine. For those who offer me their tidbits of wisdom, I do not own this machine, and I have already brought up the subject of swapping it or getting a new one, and the owner is NOT INTERESTED.
  6. Some results from my testing. Please do not reply if you are not interested. The syntax errors are not in the javascript source files. They are being reported at places that are beyond 4096 bytes into a line. Some of the javascript lines are over a 100K long and have been obfuscated. It seems that some browsers have problems with such long lines in the javascript and for some reason or another truncate or otherwise do not see the rest of the line. Some of my tools have a 4096 char limit to line length, but I found one editor that can handle the source files (JED). I have not found a way to test this, such as putting in some line breaks, as it will not load from a saved copy. Firefox 48 has stabilized and is somewhat reliable, at the moment, for reasons unknown.
  7. This thread should be dead. Naming Doom Legacy 2 as something else would be even more confusing, and Doom Legacy 2 is not going to be released without a whole lot of rework and catching up. I have not tested HACX yet. I still don't know it we have it covered or not. UDMF depends on there being some content or capability there that is worth the trouble. My enhancement work is going another direction, so it does not have any priority. Which version of SDL is best for your windows should be determined by the end user.
  8. I have been considering the sector-based-firing idea presented: 1. It is viable, but is not as capable as TRIG-TAG, as it leaves off the action coding. 2. It is not that different than TRIG-TAG, and that difference seems to be using a sector (so as to keep the TAG as a sector-TAG). I keep feeling that this is a slight improvement in that there is only one TAG space, but it also the biggest hinderence. 3. TRIG-TAG does not require sectors, can share linedefs with existing walls. Consider a sequenced action. A remote trigger starts everything. The light around the door blinks red three times as the door slowly opens. I picked an example with a sequence because that causes the most problems for the sector-based-firing. This example does not show-off any action code usage of TRIG-TAG, the SECTOR-BASED-FIRING not having that capability. TRIG-TAG: A pushbutton trigger linedef (TAG=3, ACTION=ON) starts everything. A sequencer linedef (TAG=3) accepts the TRIG-TAG action and starts a sequencer. There are two linedef at vertex2, so the sequencer forks. One path consists of a chain of linedefs: red-light-on, delay, red-light-off, delay, red-light-on, delay, red-light-off, delay, red-light-on, delay, red-light-off. The other patch consists of a slow ceiling-raise operation (TAG=16, which is the door sector tag). There is a modifier linedef that causes the ceiling to raise at 4x-slower than normal (to be more dramatic). The modifier acts upon the ceiling-raise linedef, but is ignored by the sequencer. (How and why it is ignored is one of those details that must be decided as there are several ways to get it to be ignored). SECTOR-BASED-FIRING: Sector-based-firing (only has sector tags), that uses delay linedef to fire another sector (to get a sequence). A pushbutton trigger linedef (TAG=3, ACTION=ON) starts everything. There is a sector with TAG=3, and it has the 4 linedef. - red-light-on - a ceiling raise linedef - a modifier linedef that makes the ceiling raise x4-slow - a delay linedef (TAG=4) There is a sector with TAG=4, - red-light-off - a delay linedef (TAG=5) There is a sector with TAG=5, - red-light-on - a delay linedef (TAG=6) There is a sector with TAG=6. - red-light-off - a delay linedef (TAG=7) There is a sector with TAG=7, - red-light-on - a delay linedef (TAG=8) There is a sector with TAG=8. - red-light-off The TRIG-TAG bases solution has far less overhead (in sectors and extra linedefs). The sequence of red lights on and off would be visible as a chain of action linedefs. In the SECTOR-BASED-FIRING, the sequence of red-lights on and off is difficult to see, especially if it was on a level map.
  9. I rewrote the TRIG-TAG description. The original description was done in a hurry and it included many wild ideas. I expected that people would pick and choose which of the wild ideas they supported. Comprehension has suffered. TRIG-TAG V3 is a total rewrite, with the basic system presented more clearly, with any wild ideas pushed to the end. Much of the concept has been reworked to simplify the logic. How the action codes are used has been changed. I changed some things to assuming that the modifier linedef system based on shared vertexes would be accepted. Assuming that simplifies things, which shows why it is so important to deal with this now and stop trying to push it off. Most every linedef design decision is dependent upon the modifier linedef and trigger linedef systems adopted. There are only a few basic concepts that need to be accepted to implement TRIG-TAG. Most of the description consists of examples of linedefs that would use the system. There will also be some picking and choosing of the linedefs to implement (such as PUSH-PUSH switch) and the keyboard connected switch. TRIG_TAG V3: https://www.sendspace.com/file/17oii6 Right now, a new trigger linedef would have to use the Boom system with all the fields. This eats up the linedef space. TRIG-TAG provides a way to connect new triggers to action linedefs. The sector-based-firing is like TRIG-TAG except that it lacks the additional parameters, and it requires a sector for each firing connection. No other alternatives have been proposed. This is a boom extension that is adding linedefs. The most interesting things being discussed are the additions to linedefs. Most such linedefs would require a system like TRIG-TAG due to code-space-exhaustion in the Boom system. I cannot see how to put this decision off and accomplish anything with linedefs.
  10. This is exactly the problem that TRIG-TAG is designed to solve. Creating new trigger linedefs outside of the existing Boom trigger fields (which are used up). A new TRIG-TAG linedef would be created that is like a GR/G1 linedef except that it is triggered by projectiles (hey, this sounds like the MISSILE_SWITCH from a few pages back).
  11. It seems you are also describing the TRIG-TAG FIRE_VERTEX2 linedef. It fires all the linedefs that share vertex2 without stepping on any existing sector-TAG assignments. This is a simplified sequential firing linedef that only fires one step, and does not do the delay or sequencing part. Yes, it would be powerful in that it really allows the user to separate triggering, from firing actions, and allows trigger fanout (which is really missed in Doom). The FIRE_VERTEX2 differs from the sector-based triggering in that it does not require an intermediate sector, but uses linedef-TAG search instead. It does not require any TAG splitting, as there is no need for both a TRIG-TAG and a sector-TAG on the same linedef. I suspect there will now be some complaint that this is a discussion is about providing scripting without a scripting language. For someone who uses their favorite scripting language to solve such little problems is a little strange to me. For someone who has made a level map without any scripting, to expect them to adding scripting to fix such a problem, makes me wonder if some people understand what we are trying to do here. It also makes their level map specific to their favorite port. The point of this whole extension is to provide some port independent way to solve these kind of mapping problems. Any pointing some favorite scripting language is not going to solve anything.
  12. Two or multiple TAGs on the same sector. I recognize the problem. Effects appear on all sectors with that TAG, and making subsets and overlapping sets of sectors with different effects really is difficult. That is one of things I was trying to address was making a linedef action work on a sector without having to use a common sector-TAG. There would be several ways to achieve the same result: 1. Have a linedef that repeats sector changes to its side1 to all the sectors with sector-TAG. This would require all sector-TAG effects to also search for any linedef around it with such a type and then include the sectors with that sector-TAG too. 2. Use a TRIG-TAG that specifically converts an action linedef to affect its side1 instead of using sector-TAG. This would use the TRIG-TAG system action to intercept the sector-TAG search and substitute a different target sector determination method. It would allow TRIG-TAG triggered actions to be independent of other existing uses of the sector-TAG, but it would limited to TRIG-TAG triggered actions. 3. A new modifier linedef that when attached to a trigger linedef (by shared vertex) would repeat the action on the sectors that matched its sector-TAG. This effectively just adds an additional sector-TAG selection to any action. This may be the easiest to implement, but it requires vertex-shared-modifiers and some implementation record keeping.
  13. TRIG-TAG: Boom has a transparency linedef that modifies other linedefs based on matching the TAG number. This requires that linedef to search the other linedefs, basically exactly what TRIG-TAG proposes. That cat is already out of the bag. There is NO requirement for splitting the TAG field in the TRIG-TAG system. I did fly a proposal that a split TAG field would allow having multiple TAG values, that might prove useful in complicated situations. There are other ways to handle those situations, and they were very few to even consider. If Sequential linedefs is adopted, then that solves the problem too, even better. I have been giving the TRIG-TAG system some thought, to find situations where the mapper can get stuck. The issue of sharing TAG fields with sector-TAGS and the difficulty of firing a linedef that uses a sector-TAG. If a linedef is using the TAG field for a sector-TAG, then the problem is identifying it as a target to be fired, without also catching other linedefs that also modify the same sectors using the sector-TAG. The proposed Sector-based-firing (traversd) is viable, and solves that problem, but it lost some of the other advantages of TRIG-TAG in the process. I would have to give it some more examination to identify completely and correctly the differences, PROs and CONs. LINEDEF: TRIG-TAG FIRE_VERTEX2. I had come up with an alternative that involved a linedef that received a TRIG-TAG triggering, based on TAG value, and then fired any action linedef that shared its Vertex2. This would use the same method of connecting linedefs as the modifier linedefs, and would only cost one linedef. The adjacent linedef to the action linedef would often be available, and it would only require setting the type field and TAG field. Most common wall segments are not using those fields, so most of the time another linedef will not be required. First impressions: 1. Sector-based-firing finds the linedefs to fire by traversing the list of linedefs that surround a sector. This may be a shorter list than searching the linedefs, but it is also slightly more difficult to use. Also a search of the sectors for matching sector-TAG is still required, and it may fire multiple sectors each of while have multiple linedefs. 2. Sector-based-firing solves the problem of firing linedefs by allowing the linedefs around a sector to have a different sector-TAG than the sector that is firing them. This achieves isolation. 3. Sector-based-firing requires a sector and at least three linedefs. The TRIG-TAG system tried to minimize extra linedefs, and may require one extra linedef (the TRIG-TAG FIRE_VERTEX2) in some situations. Because TRIG-TAG allows direct firing of target linedefs when there is no TAG conflict, there will many cases where that extra linedef is not needed. 4. The proposal left out the TRIG-TAG action that is emitted by a TRIG-TAG firing. Without that PUSH-PUSH switches, and UP/DOWN keyboard controls will not work because they must emit different action codes at different times. This was the TRIG-TAG solution to provide a triggering linedef supplied parameter to the action functions. Without it, many of the new and innovative triggers are truly stuck. This seems to be the only choice that made sector-based-firing seem simpler. But if it is left out to make things simpler now, it cannot be tacked on later. Every use of this new facility will be handicapped. 5. The sector-based firing seems to allow any trigger linedef with a sector-TAG to fire a sector. That would be terribly complicated. It should be clear that only a TRIG-TAG (or in this case a Sector-based-firing) specific linedef can initiate the indirect firing of other linedefs. This would not allow the use of any existing Boom triggers.
  14. Interesting discussion ... Scripting: I only mentioned Fragglescript to prove once again that there will be no agreement on choosing a scripting language. That this is an extension to Boom format (and not Hexen) is the driving principal. How do the non-Hexen ports and the level mappers that use them improve their mapping ability without being subject to patient explanations of why they should abandon their favorite port and its Boom format and switch to ZDoom and Hexen format instead. Scripting port code: It seemed that there was a mention of using user scripts to modify the port code, such as menus and other things. In DoomLegacy, just about every function has DoomLegacy specific additions. Sticking any user scripted code or even changes will be highly difficult, and will likely break more than a few things. The menu system is unique. Trying to find modifiable parameters that are in common with other ports is an order or magnitude more difficult than trying to find common modifiable parameters in something like monster behavior (like BEX and DEH do). I you look at how X-windows does this, you find out that every theme has a requirement that it can only run using a particular theme-engine. If your port of x-windows does not use that theme-engine, then you cannot execute that theme description. Theme-engines cannot just be dropped into the code of a particular X-window implementation.
  15. For any consideration of Fragglescript. Fraggle's original version indeed was buggy and prone to misbehave if the user made an error. I interpret that is why Fraggle made the statement he did. The DoomLegacy Fragglescript version is hardened, and will gracefully recover from user errors. The implementation has been significantly improved. I think that almost every function of it has been mostly rewritten.