• Content count

  • Joined

  • Last visited


About wesleyjohnson

  • Rank
    Senior Member
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. While I could go off in isolation and design a TRIG-TAG system, I am trying to tailor some factors of it to the needs. So many people see TRIG-TAG as being complicated, and I wonder just why. The basic principal is that there is a trigger linedef separate from the action linedef, and the trigger linedef finds the action linedef by matching the TAG number. This is the same system as sector-TAG used by most Boom linedefs, but it is applied to find linedefs instead. But, since there is a new communication path into a linedef firing, it is an opportunity to enhance that with some more parameters. We have a constant problem of enhancements not being able to find places to put enough parameters. Some more input and ideas here would be useful. Otherwise, I will have to just guess at what is most useful. So far I have introduced the TRIG-TAG actions, that can modify the action linedef based upon what kind of trigger linedef fired, and optionally how it fired (such as UP/DOWN for keyboard UP/DOWN control, or ON/OFF for such triggers as a PUSH/PUSH switch). We can allow this to be a byte and thus can have up to 255 values. But for defining the behavior of existing action linedefs, we should have a basic set, and some expected interpretations. Otherwise mixing triggers with selected action linedefs won't work at all, due to having few action linedef that respond to a particular trigger linedef action. 1. I work so much in DoomLegacy linedefs that it seems that using side1 is the natural way to get parameters, but I suspect that the sector-TAG method of identifying the target sector is used by many Boom linedefs and needs to be preserved for TRIG-TAG too. 2. I am leery of sector based modifiers, because separating actions and modifying each action (UP/DOWN) independently seems to give an ability that we cannot achieve in other ways. 3. Action exclusion will have to be solved. We cannot have a trigger linedef firing off both UP and DOWN actions at the same time. Does this change in this thread going to allow for some more discussion and input on these issues?
  14. Please remember that there is one notable effect. The reply editing boxes load intermittantly. They sometimes work, they sometimes don't work. That should not happen if this browser simply cannot handle some new construct. It should then fail consistently. One problem is that the servers do detect what browser is running and are capable of changing the javascript, and the HTML, to adapt. I have seen many instances of this in the HTML from many sites, especially for Internet Explorer. One of the tricks of non-standard browsers is that they have a control that lets them report themselves as another browser, so as to get pages that are less buggy, or to avoid browser discrimination (a problem during the Firefox, IE wars).
  15. I think the Firefox console is not adequate, you need a real Error logging console or an HTML editing tool. K-Melon is the only browser I have tried yet that seems to have a real error logging console. I think that Firefox only reports errors if it is serious to Firefox, a subset of the real errors. I do not trust Firefox alone as being authoritative, without knowing for certain what their error logging intentions actually are. I am mostly interested in the two syntax errors. No matter how they enhanced the HTML, there should not be syntax errors for anyone. There are two possibilities 1. The Doomworld scripts do have the syntax errors, and the writers never tested beyond a few popular browser and OS, and those syntax errors do not cause those particular browsers to fail. This is a common situation in any released code. 2. That the is some new construct that embeds mismatched syntax elements (a stupid thing to do) and it is fooling the error console into logging it as an error. If there are such bugs in the DoomWorld scripts then I consider them to be a problem, no matter what browser you are running. I was never one to leave latent bugs around. There always was a few of the marketing people who thought it was no skin off their noses, or it saved development money, to just require the users to use the one particular interface that did not break. I am amused and disappointed at some people's reactions when they see someone working on old hardware or old software. If this bothers them they should go to some other sites, where they are not trying to keep a 20 year game alive and working.