Defining a new enhanced source port standard (Boom+/MBF+)

[kb1]

21 hours ago, Linguica said:

Allow me to help then.

Ok, I patiently await your help :) Thanks.

 

Once I'm ready to post my spec, I'll need to create another thread. That thread will need to be restricted to devs and/or focused discussions about the spec. Can I (or someone) be set up to be able to moderate a single thread, and does that make sense to do?

 

EDIT: I didn't think about private threads. Does the forum software support the ability to make a private thread? That's the way to go, I think, when the time is right.

Edited June 21, 2017 by kb1

[fraggle]

3 hours ago, kb1 said:

Once I'm ready to post my spec, I'll need to create another thread. That thread will need to be restricted to devs and/or focused discussions about the spec.

I don't know if it's possible to do access control like that with this software. But Linguica will be able to answer better than I can.

 

I'm glad that you want to take this measure though, since it's clear that this thread is in disarray. I was worried that something like this would happen (see my earlier comments). I think what's needed is either private discussions with a limited group, or an open discussion where participation is restricted or heavily moderated. I'd also suggest any discussion threads need to be narrowly-focused (many small ones) rather than wide-scoping and grandiosely-titled like this one is.

 

I think you need to define some process and/or ground rules. It would help if you started out by forming some consensus on what you even want to achieve. Maybe write down (and get others to agree upon) something that describes:

• What your goal is - for example, defining a new set of minimal extensions to the Boom "standard". Be as specific as you can.
• Any essential requirements you can think of. For example, one might be that linedef types should not conflict with those already in use.
• The scope of the work. For example you might declare "we only want to define new linedef and sector types". Clarify what is not in scope - I'd suggest "we are not planning to change the level format" and "we are not planning to define a new scripting language" as examples.
• Agree upon the rules by which you will reach consensus and make decisions. For example it might be that "all source port representatives must agree", or it might be "if three source port representatives agree".
• Rules of discourse. For example, reach a consensus about general approach before proceeding to the detailed design - no dumping huge, complicated detailed design proposals into threads.

Maybe this all sounds too laughably bureaucratic but the truth is that reaching consensus on something like this is an exercise in political negotiation. Different Doom source ports represent different design philosophies, so there will inevitably be tension between people with radically different points of view (could GZDoom and Chocolate Doom be any more different for example?). I'm still optimistic though. Lay down some ground rules and a limited scope, and I don't see why people shouldn't be able to reach some consensus on things.

[kb1]

Thanks, fraggle. Your words are optimistic and inspiring, and, no, it's not too bureaucratic. Spot on, I'd say. But can we live up to it, and use the process properly, in each post?

 

I wasn't worried about how I would interpret the thread, because I did ask for pure unhinged brainstorming. But others were hoping for some more practical, immediately relevant discussion, and I can understand that. I was hoping to start out broad, and slowly narrow the focus. But, it's difficult to convey those intentions, especially when I'm winging it as I go!

 

I intend to take your advice, and to be fully prepared for the next thread, with an enumeration of the goals, requirements, rules, and the scope-narrowing. This is great advice, and I don't think I would have thought of it myself.

 

I know your current Doom work has no need for my spec, but you are most welcome to be involved in those discussions if you wish. It would be a pleasure to have you, for both your expertise in Doom, and your project management abilities!

[Jon]

Here's a suggestion, that may or may not sound like a good idea, based on my experiences of trying to bash out specifications in the Debian project, where mailing list conversations often get too large to keep a clear big picture of the state of the proposal. The idea is for a small pool of editors (perhaps one) to keep a summary page on a wiki somewhere. The discussion about the summary page could continue here, but it would always be about the current draft which would be a wiki page. The important thing is you don't have a lot of people all edit-warring on the wiki page, the editor(s) would basically need to be convinced of a change to make it. Which puts them in the position Fraggle outlines, of having to exercise careful judgement.

Said page should cover the points Fraggle describes (rationale etc) and it would be wise to document rejected proposals too, so people coming along later and saying "what about..." can be pointed at that.

 

If you have a doomwiki account already, you could set it up as a sub-page of your User space, e.g. https://doomwiki.org/wiki/User:Yournamehere/Boom+_proposal

[wesleyjohnson]

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?

 

[wesleyjohnson]

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.

[kb1]

13 hours ago, Jon said:

Here's a suggestion, that may or may not sound like a good idea, based on my experiences of trying to bash out specifications in the Debian project, where mailing list conversations often get too large to keep a clear big picture of the state of the proposal. The idea is for a small pool of editors (perhaps one) to keep a summary page on a wiki somewhere. The discussion about the summary page could continue here, but it would always be about the current draft which would be a wiki page. The important thing is you don't have a lot of people all edit-warring on the wiki page, the editor(s) would basically need to be convinced of a change to make it. Which puts them in the position Fraggle outlines, of having to exercise careful judgement.

Said page should cover the points Fraggle describes (rationale etc) and it would be wise to document rejected proposals too, so people coming along later and saying "what about..." can be pointed at that.

 

If you have a doomwiki account already, you could set it up as a sub-page of your User space, e.g. https://doomwiki.org/wiki/User:Yournamehere/Boom+_proposal

You think a Wiki would be the best place? Interesting. Can anyone else chime in about the validity of using a Wiki for the spec technical discussion? (I'm a dinosaur when it relates to internet and forum tools.

 

4 hours ago, wesleyjohnson said:

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.

...

Does this change in this thread going to allow for some more discussion and input on these issues?

 

That's not why I haven't commented about TRIG-TAG any more: Basically, I just haven't had dedicated time to study it the way I like to. Also, my mapping skills (or lack thereof) are helping me. I don't want to leave you hanging...in isolation. Personally, I just need more time. HYowever, I have been in talks with others that are discussing similar ideas, and I'm hoping they can organize their stuff and post it in reply. Please keep thinking about it, with the understanding that it's going to be quite a while before I can fully consider your proposals, as well as all the other proposals here and it other threads. There's a ton of info to dig through.

 

4 hours ago, wesleyjohnson said:

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.

I have no plans for my spec to be involved with scripting at this time. That is its own spec, and it has little chance to be adopted by all devs, I think. In fact, I want to use a custom language I've been working on, but I don't expect that other devs would want to use it. The closest I will get is that any additions I propose will be usable by scripting, if the dev sees fit, and will not harm scripting, regardless of language flavor.

 

If someone wants to work on a common scripting language, what I'd suggest is that they first define standard "objects", like "Actors", or "Menus". Any good scripting language would need access to these and other objects, which could maybe be defined globally. These objects would need to be usable by any script language you bolted on. It's this object definition that could be common among all languages, I think.

[Graf Zahl]

Sorry if I may offend someone here.

 

Please let's lay that TRIG-TAG stuff to rest. I can guarantee that this isn't something that will ever enter a joint standard. I have no interest in it and it's a serious complication that will certainly make other needed supporters quit as well.

 

The thing is, we do not need talk about complex things right now but instead a list of easy to implement and highly sought after features in order to get it off the ground. Once there is some actual movement - then it's time to discuss more complex things. But if they again start to bog down the discussion before there is one, we may just cancel the entire matter right now.

 

[traversd]

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.

[Da Werecat]

The thing about scripting in Boom is that it's already there. Sorta. It might be inconvenient and clunky, but it's already quite powerful for what people usually want to do in Boom.

 

Which means that it shouldn't be a priority.

[VGA]

I like the idea that experienced mappers like traversd can request some new linedefs to be added to extend the Boom ones. I mean, what monster would disagree with implementing new linedef specials?

[Graf Zahl]

The real irony is that most of these proposals sound a lot like "let's do Hexen format without having 5 args available.

[kb1]

8 hours ago, Graf Zahl said:

The real irony is that most of these proposals sound a lot like "let's do Hexen format without having 5 args available.

 

15 hours ago, Graf Zahl said:

Sorry if I may offend someone here.

 

Please let's lay that TRIG-TAG stuff to rest. I can guarantee that this isn't something that will ever enter a joint standard. I have no interest in it and it's a serious complication that will certainly make other needed supporters quit as well.

 

The thing is, we do not need talk about complex things right now but instead a list of easy to implement and highly sought after features in order to get it off the ground. Once there is some actual movement - then it's time to discuss more complex things. But if they again start to bog down the discussion before there is one, we may just cancel the entire matter right now.

 

Please try to keep an open mind, and not be too dismissive. Remember, this thread is for ideas. It's my fault for lumping 2 trains of thought into one thread, by proposing a new standard, but also asking for ideas. Unfortunately, this thread has become to go-to place for these ideas, and that's ok. These are just ideas, and this thread has become the place to put them. I'm ok with that.

 

Please note: Part of getting everyone to want to adopt the standard is that we may need to cater to each developer's pet project. That means that, if a developer has an unusual, but solid idea, and adopting that idea makes the difference between accepting or not accepting the spec, I need to consider the idea, even if I don't personally like it. Please respect that this is an awkward situation for me to be in, but I accept this reality. When we start fleshing out the specifics, we can each provide our arguments, and try to come to a consensus. If an idea does not drastically change nor interfere with existing stuff, and it's not too hard to implement, and it does serve a useful benefit, then why not?

 

That doesn't mean that I intend to cater to everyone's whims. I expect the other devs to be adult men who are serious about turning this compatibility issue around. This is not for babysitting spoiled brats that threaten to bail when something doesn't go their way. This work is harder than just adding some features, and I need responsible, serious people backing it. I'm not bailing if I don't get everything I want. When there's opposition, I respect it, assuming that I'm not the only smart person in the group. I expect others to do the same, right?

 

We will employ fraggle's process, and be as diplomatic and formal as possible, and we should be able to reach common ground. I believe we can do that.

 

I need your support, as well as Wesley's, and everyone else's, for that matter. Getting this thing to work is going to involve compromise, from all parties involved, and from the spec. Each portion of the spec is going to piss off somebody, including me, but that's par for the course. However, we will not implement anything that doesn't make sense, and we will not compromise usability or function, regardless of any single opinion.

Your opposition is duly noted, and holds high influence. There are things about TRIG-TAG that I dislike as well, yet some parts of it are interesting. Regardless, it will not be a part of Phase 1 - it's too big.

 

Many of these ideas will not make it into Phase 1, or even 2, or 3. But, there is knowledge in knowing what ideas people are thinking about. It helps me judge the "size" of containers. It helps me avoid making assumptions. It's like trying to decide how much money to take to the store. It's easier to judge, if you know what you might want to buy, even if you don't have a specific list. (I know, it's a poor analogy).

 

Your worries are transferring to me, and I'm starting to feel rushed and stressed, like if I don't get this spec out quickly enough, you're going to jump ship. That's not your fault, it's just how I operate, but it's not healthy for me. Let's stay focused, but relaxed. With an open mind, yet good planning, we can really score a direct hit with this thing. Let the ideas continue. Soon, we'll start a clean thread that focuses on the specifics.

 

Check it out

I would like everyone to take a look at traversd's image. To me, it seems to be a very slick way to tie a single trigger to multiple actions, in the spirit of TRIG-TAG, without partitioning the tag. Please take some time, and give it a real consideration.I can't find a flaw in it, and it seems to be a very powerful tool that should be available. It's easy to implement, and extremely powerful, and should be useful to all ports, script-ready or not.

 

9 hours ago, traversd said:

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.

I am very fond of this idea - it has a lot going for it:

• It doesn't require tag partitioning, tag-splitting stuff.
• Straight-forward approach
• Easy to understand
• All of the mechanics of the setup are in the "proper" spot. That is to say: Everything is where you'd expect to find it, if you were examining the map in a map editor.
• Only requires 1 new linedef! (May actually need a few: SR, W1, WR, G1, GR, etc).
• Does not exclude "Modifier" linedefs, or additive effects (like 2 separate scrolling effects applied to the same wall/sector)

Thanks, traversd. I would like to hear opinions from devs and mappers.

 

@wesleyjohnson: I would especially like to hear your opinion on traversd's idea. It was born out of your TRIG-TAG proposals, and it eliminates my biggest complaint about TRIG-TAG - the tag partitioning. My question to you is, can traversd's idea cover your TRIG-TAG needs, at least partially? I can see this system being adopted and implemented quickly, cause it's simple to understand, simple to map for, and simple to implement.

 

@everyone: Can we please test Graf's UMAPINFO engine and provide some feedback? Thanks.

 

 

[Misty]

I hope, new standard will let use double or more tags on the same sector. I don't know that much about codes and deeper programming things, but it would save some space and time while mapping. It's just two my cents.

 

 

[Graf Zahl]

That would actually be quite an invasive change and require UDMF. There's no way to shoehorn that into the binary map format.

It's also hard to tell how that will affect the tag searching utilities. In ZDoom with C++ and no concerns for demo compatibility I just changed the entire utility chain but with demo compatible ports it needs a lot more care.

 

Also don't forget that each port is a bit different so such an extensive change may just be rejected for the work involved. I can only repeat: A new standard needs AT LEAST the support from PrBoom+, Eternity and ZDoom, preferably 3DGE as well so this should always be kept in mind when discussing features. Anything that changes internal semantics is guaranteed to become a roadblock.

 

[Misty]

30 minutes ago, Graf Zahl said:

That would actually be quite an invasive change and require UDMF. There's no way to shoehorn that into the binary map format.

It's also hard to tell how that will affect the tag searching utilities. In ZDoom with C++ and no concerns for demo compatibility I just changed the entire utility chain but with demo compatible ports it needs a lot more care.

 

Also don't forget that each port is a bit different so such an extensive change may just be rejected for the work involved. I can only repeat: A new standard needs AT LEAST the support from PrBoom+, Eternity and ZDoom, preferably 3DGE as well so this should always be kept in mind when discussing features. Anything that changes internal semantics is guaranteed to become a roadblock.

 

This was just an idea, not real thing. I understand that we need keep demo compatibility for boom format. I just thought about sky transfer on tagged sectors as example and how difficult is setup everything right without sacrifing some outside sectors with transfered sky in boom format. Well, you know more than me and I won't argue. 

[kb1]

15 hours ago, Graf Zahl said:

That would actually be quite an invasive change and require UDMF. There's no way to shoehorn that into the binary map format.

It's also hard to tell how that will affect the tag searching utilities. In ZDoom with C++ and no concerns for demo compatibility I just changed the entire utility chain but with demo compatible ports it needs a lot more care.

 

Also don't forget that each port is a bit different so such an extensive change may just be rejected for the work involved. I can only repeat: A new standard needs AT LEAST the support from PrBoom+, Eternity and ZDoom, preferably 3DGE as well so this should always be kept in mind when discussing features. Anything that changes internal semantics is guaranteed to become a roadblock.

 

Really? To summarize: It's a switch that emulates the player hitting each switch in the tagged sector. That's an invasive change? I was thrilled at how simple it would be to implement, given the power it would provide. I didn't realize it would be an invasive addition - are you sure we're talking about the same thing? Anyway, to quote MysteriousHaruko, it's just an idea. Don't forget Legacy in that list.

 

I think I'll have some time to devote to the spec this weekend, for a change. I'm starting to knock out projects, slowly but surely. Wish me luck.

[BigDickBzzrak]

Another proposal: would it be possible to implement something that would make GR/G1 lines activate-able by projectiles? New linedef flag maybe? Some sort of special linedef action? (e.g. "make all same-tagged lines activate-able by projectiles")

[kb1]

23 minutes ago, bzzrak said:

Another proposal: would it be possible to implement something that would make GR/G1 lines activate-able by projectiles? New linedef flag maybe? Some sort of special linedef action? (e.g. "make all same-tagged lines activate-able by projectiles")

Technically possible, but tedious: The Boom generalized linedefs use 2 bits of the linedef type to designate trigger type, and another bit for repeatibility (I think). So the space for trigger types is "used up", so to speak. You'd have to add a new set of linedefs for each triggerable line. Naturally, you'd want to be symmetrical, like Boom was, and support everything. This amounts to a whole lot of new linedef types for a not-so-useful feature. There are ways around this, though: You could just add support for a handful of actions. Or, you could add some of Wesley's linedef modifiers. You could also have a game setting globally allowing fireballs to trigger linedefs. This was specifically prevented in Vanilla during Doom 1 creation, and when they made Doom II, they forgot to handle the new fireball types. This actually generated a heated debate recently on Doomworld, which I would not like to repeat.

 

Technically, it's not a G1/GR, but a W1/WR: The fireball "walks" over the linedef.

 

This may be something better added to UDMF. No way it makes it in Phase 1, though. It's actually quite a big, messy issue to try to tackle, for (arguably) only a small amount of benefit.

[VGA]

2 hours ago, kb1 said:

This was specifically prevented in Vanilla during Doom 1 creation, and when they made Doom II, they forgot to handle the new fireball types. This actually generated a heated debate recently on Doomworld, which I would not like to repeat.

Can someone link me to that? I love DW drama about Doom's inner workings :D

[cybermind]

After seeing this topic I remembered the thing that always looked weird to me in Doom modding - Dehacked.

 

When Boom team developed their port, they introduced a lot of new features to Doom mapping, but very little abilities to modify engine stuff. The same happened to MBF (even though it added some new codepointers). The Miscellaneous section of Dehacked is too small, there are only few values that could be modified, while Doom has a lot of constants and parameters you can't modify in Dehacked (for example, level numbers that use SKY2 and SKY3 skies, 666 and 667 tag customizing and much more)

 

I spent this weekend studying doom2.exe internals and I figured out that it's possible to nullify existing codepointers from frame table by zeroing some bytes in exe object section (Dehacked only replaces action functions entry points). I haven't checked it on real DOS machine, but it works in DOSBox.

 

So I've come to idea - introduce new extended Dehacked format that allows editing more stuff in doom(2).exe and write Windows version of dehacked.exe that implements this new features (while keeping compatibility with old dehacked format). The only question left unanswered for me - will port authors implement it in their ports (or will they approve patches that will implement this new dehacked format).

 

[fraggle]

On 6/21/2017 at 3:04 PM, wesleyjohnson said:

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.

To avoid any ambiguity: please don't promote the use of FraggleScript for anything. It's a badly designed language with a bad implementation. Maybe the Legacy version has been "hardened" but I doubt it addresses any of the fundamentally broken issues with the language or the codebase.

[VGA]

Since you brought it up, the main problem with Dehacked is the way that you have to cannibalise the original game or search for unused resources. The author of Doom Retro added some blank states, some blank spritesets and some blank things, I created a new Whacked preset to make thee available to me in the program, and then I painstakingly created a vast Dehacked mod using some of these, then the Crispy Doom developer implemented those in his port, too, to make the mod compatible. These simple changes should be implemented in other ports, too, before discussing new code pointers.

 

To reiterate, blank stuff to be used in Dehacked, please make it happen. All the main ports already put in the work for the MBF added stuff and code pointers, what I am talking about is trivial.

[kb1]

On 6/23/2017 at 9:02 PM, VGA said:

Can someone link me to that? I love DW drama about Doom's inner workings :D

DoomWiki - 'Projectiles triggering linedefs'

 

 

1 hour ago, fraggle said:

To avoid any ambiguity: please don't promote the use of FraggleScript for anything. It's a badly designed language with a bad implementation. Maybe the Legacy version has been "hardened" but I doubt it addresses any of the fundamentally broken issues with the language or the codebase.

Hey, don't cut yourself short - I was very impressed with its documented capabilities, and the level of detail and structure in the language (I'm not sure about the code, I just checked out the specs, which I found fascinating). If it didn't work right, I would predict that you just needed a little more time to iron out some bugs. Very cool concept. Was it all written from scratch? I'd love to see a thread/web page/interview describing how you built it.

 

But, point taken - you don't want to see it in new stuff - ok. Seriously, I don't know why we're still discussing scripting...I guessed I opened that door.

 

 

1 hour ago, VGA said:

Since you brought it up, the main problem with Dehacked is the way that you have to cannibalise the original game or search for unused resources. The author of Doom Retro added some blank states, some blank spritesets and some blank things, I created a new Whacked preset to make thee available to me in the program, and then I painstakingly created a vast Dehacked mod using some of these, then the Crispy Doom developer implemented those in his port, too, to make the mod compatible. These simple changes should be implemented in other ports, too, before discussing new code pointers.

 

To reiterate, blank stuff to be used in Dehacked, please make it happen. All the main ports already put in the work for the MBF added stuff and code pointers, what I am talking about is trivial.

It's under consideration. I started a thread about that very thing, about 2 years ago, with mixed opinions. The concept makes a lot of sense. The sound table should be expanded too. But, in that thread, Quasar described what sounded like a conflict with the idea. Something about the Dehacked number range and the DoomEd number range. I don't know if this is actually an unresolvable conflict, or if some tricky coding could resolve the issue. Suffice to say that, apparently, it is not as clean cut as I imagined.

 

 

9 hours ago, cybermind said:

After seeing this topic I remembered the thing that always looked weird to me in Doom modding - Dehacked.

 

When Boom team developed their port, they introduced a lot of new features to Doom mapping, but very little abilities to modify engine stuff. The same happened to MBF (even though it added some new codepointers). The Miscellaneous section of Dehacked is too small, there are only few values that could be modified, while Doom has a lot of constants and parameters you can't modify in Dehacked (for example, level numbers that use SKY2 and SKY3 skies, 666 and 667 tag customizing and much more)

 

I spent this weekend studying doom2.exe internals and I figured out that it's possible to nullify existing codepointers from frame table by zeroing some bytes in exe object section (Dehacked only replaces action functions entry points). I haven't checked it on real DOS machine, but it works in DOSBox.

 

So I've come to idea - introduce new extended Dehacked format that allows editing more stuff in doom(2).exe and write Windows version of dehacked.exe that implements this new features (while keeping compatibility with old dehacked format). The only question left unanswered for me - will port authors implement it in their ports (or will they approve patches that will implement this new dehacked format).

 

I've been making something very similar, strictly for Heretic+.exe. What you're considering is interesting - there are literally thousands of places that could be hacked with positive results.

 

But, for port authors, there's some problems. When you hack up an .exe, it's easy - you change the .exe and it permanently runs differently. But, with a source port, such a hack involves turning each potential hard-coded value into a variable, to allow internal DeHacked code to modify it. This is quite messy for ports. But even worse, this means different things to different ports. Some ports have already turned some of these into variables. These variables are filled in different ways: Global variables, console variables, filled in from a startup script, filled in dynamically in a runtime script. It's potentially a mess, and there could be thousands of messes.

 

There may be "room" for supporting a small handful of additions to the BEX format (Boom's extension to DeHacked). But it seems like a can of worms to me. I could be wrong, though.

[VGA]

52 minutes ago, kb1 said:

DoomWiki - 'Projectiles triggering linedefs'

I was promised drama, not a doomwiki page!

[fraggle]

17 hours ago, kb1 said:

Hey, don't cut yourself short - I was very impressed with its documented capabilities, and the level of detail and structure in the language (I'm not sure about the code, I just checked out the specs, which I found fascinating). If it didn't work right, I would predict that you just needed a little more time to iron out some bugs. Very cool concept. Was it all written from scratch? I'd love to see a thread/web page/interview describing how you built it.

Written from scratch when I was 17 and didn't know anything about writing compilers. I guess that's something of an achievement in itself, but it's a horrible codebase in retrospect (I had no idea what I was doing and now know a lot better) and the language itself is a mess and is missing many basic features, like functions for example. Bits of the syntax are braindamaged because I was too lazy to do them properly - for example the for loop syntax uses commas instead of semicolons because it was easier for me to code.

 

It's rather disappointing to me that there doesn't seem to have been any serious attempt to add scripting to Doom with a dynamically-typed language. FraggleScript is the closest thing that exists. I really want to see a Doom source port where I can just bring up something like a Python console and just reprogram the whole thing from inside itself in real time, but nobody else seems to share that vision.

 

My main idea when designing FraggleScript was that it ought to be as simple as possible because most of the people using it were probably going to be level authors and not programmers. You shouldn't have to learn something terrifyingly complex just to make a few doors open in sequence or whatever. I still think that's a good philosophy, though in retrospect even FraggleScript's syntax seems overly heavyweight. I've even pondered the idea of making something like a "DoomBASIC" because for all its flaws, BASIC was trivial for most people to pick up in the 80s and most people scripting levels probably don't need anything much more advanced.

 

Despite all the advanced source ports we see nowadays, it still seems like scripting is something of an inaccessible dark art. I'm a bit out of the loop with all the levels that are coming out nowadays but it seems slightly strange that people aren't using scripting more.

[kb1]

8 hours ago, fraggle said:

Written from scratch when I was 17 and didn't know anything about writing compilers. I guess that's something of an achievement in itself, but it's a horrible codebase in retrospect (I had no idea what I was doing and now know a lot better) and the language itself is a mess and is missing many basic features, like functions for example. Bits of the syntax are braindamaged because I was too lazy to do them properly - for example the for loop syntax uses commas instead of semicolons because it was easier for me to code.

 

It's rather disappointing to me that there doesn't seem to have been any serious attempt to add scripting to Doom with a dynamically-typed language. FraggleScript is the closest thing that exists. I really want to see a Doom source port where I can just bring up something like a Python console and just reprogram the whole thing from inside itself in real time, but nobody else seems to share that vision.

 

My main idea when designing FraggleScript was that it ought to be as simple as possible because most of the people using it were probably going to be level authors and not programmers. You shouldn't have to learn something terrifyingly complex just to make a few doors open in sequence or whatever. I still think that's a good philosophy, though in retrospect even FraggleScript's syntax seems overly heavyweight. I've even pondered the idea of making something like a "DoomBASIC" because for all its flaws, BASIC was trivial for most people to pick up in the 80s and most people scripting levels probably don't need anything much more advanced.

 

Despite all the advanced source ports we see nowadays, it still seems like scripting is something of an inaccessible dark art. I'm a bit out of the loop with all the levels that are coming out nowadays but it seems slightly strange that people aren't using scripting more.

No shame needed. Building languages, and especially compilers is hard. Very hard. It's the kind of thing you build one, scrap it, build again a little better, scrap it, etc. The fact that what you released got used, to good effect, is something to be proud of. It added a ton of power to Doom editing, which is pretty darn cool. Now that you know better, your next compiler will be that much better. And, I gotta say - I've released some apps with some pretty hairy source, and they loved it. No one cares about the plumbing (except the poor programmer that has to maintain your app later :)

 

"DoomBasic" is exactly what I'm working on at the moment. Honestly, I hear a lot about BASIC's flaws, but I don't feel it myself. Don't get me wrong - I understand the reasonings, I just think they are shit. The entire reason computers were invented was to simplify computation. Yet, some of today's languages appear to be written to make the computer happy, not the programmer. I cannot see why some people insist on writing their own memory management for each and every dynamic array. Yes, in some cases, like inner loops that iterate millions of times, you need to be able to optimize it - you need to be able to go low level. But, that's rare. Most often, you just want it to work, which is where BASIC sometimes shines. Modern BASICs can be just as strict with types as any other language. Namespaces, true classes, blocks (vs. line numbers), inline assembly, libraries, SLLs, DLLs, you name it. BASIC can be as powerful as anything, and can be used to write some apps quicker than could be written in, say C. Each project is different, and certain tools accomplish certain tasks better.

 

I think BASIC is a perfect fit for Doom scripting. I agree with you: Why should mappers have to learn complex syntax and programming theory to build a simplistic script? Or even a more complex script. C syntax is utterly frightening to the novice.

 

So, I have a prototype working. It runs interpretted at the moment, yet it's pretty fast for what it does. Variables are all variants at the moment. The interpretter decides the type based on assignment. Currently, the variant can be double, boolean, int, 8-byte date, or string, and can be set const. It handles about 100 intrinsic functions which support variable optional arguments. Syntax is BASIC, with some C-isms, like: A += 3, B << 1, and C && 3. I am struggling with adding " == " - I don't think it should be included. I've always found it ridiculous to have to use 2 equal signs, just to allow assignment within an expression.

 

The idea is that there will be an event model. Events fire on specific occurances, like MonsterPain, PlayerDeath, and well as GameStarted, LevelStarted, etc. Using the event name in a script activates the firing of that event. The ultimate goal would be allowing the mapper to change action functions. But, that's a long way away.

 

Currently I'm using the prototype to allow some conditional processing of the info.c/sounds.c data that getsa loaded at startup in KBDoom, so performance is fine with an interpretted solution.

 

It would be really nice for the community to share the same scripting solution, but I don't think that can happen. For example, I'd have a difficult time accepting anything other than my engine. Just being honest here. I've invested a ton of time building a language to be the best it can be for my source port...why would I want to use something different?

 

You should check out jval's DelphiDoom 2.0 with PascalScript scripting with event support. There's an image in that thread, showing the editing of a script. You can see a list of events, like ONPLAYERDIED, and ONTICK. Looks very cool and powerful.

 

So, anyway, be proud - you're work is appreciated! (Seriously. This is not an endorsement I give out lightly.)

[Jon]

19 hours ago, fraggle said:

It's rather disappointing to me that there doesn't seem to have been any serious attempt to add scripting to Doom with a dynamically-typed language. FraggleScript is the closest thing that exists. I really want to see a Doom source port where I can just bring up something like a Python console and just reprogram the whole thing from inside itself in real time, but nobody else seems to share that vision.

 

They do! I do. Honestly people do. I think it's just time and coordination that are missing. AlexMax has/had a great fork of crispy where he started on embedding Lua, and I think he has (since) developed some pretty interesting ideas about what access you should get from the scripting language (I think he started his journey thinking from the POV of what you can achieve already, and making incremental improvements, and has now moved his POV profoundly away from what is currently possible)

 

I keep meaning to try and poke at that more but I haven't had the time. I did embed Python in Doom once, but I think that might be a dead end. Lua, JavaScript or something else are the most promising candidates IMHO.

 

19 hours ago, fraggle said:

for all its flaws, BASIC was trivial for most people to pick up in the 80s and most people scripting levels probably don't need anything much more advanced.

 

Kind-of related, but last year I learned that LOGO - that I'd always bracketed like BASIC in my mind as a bit of a toy language - was actually a dialect of LISP. This blew my mind, because that elevates it right out of the toy language bracket, but it remains an accessible language. (this was stuff I learned in the context of thinking about a wadc successor)

[Quasar]

The way most mainstream dynamic language interpreters are written is simply hostile to multiplatform game development, and to game engine performance in general. EE was heading for a JavaScript implementation itself until Kaiser proved in his Kex 2 project that the VM would totally break down once too many objects were created, just because it started taking too long to search the GC chains for memory to free.

 

While newer versions of SpiderMonkey are still available, they have multiple issues, such as only being able to be compiled with the enormous and unruly Mozilla build system, and no longer offering a stable API for embedding. To build Chrome's JS engine instead you need Python of all things so, at that point you may as well use Python instead.

 

I think of the various dynamic languages Python is probably the best suited, though it takes a bit of work to make your own build of it that doesn't require an installation and doesn't just allow loading arbitrary native code from the user's system. Kate did this with a branch of Eternity that was also considered for merger into the trunk, though a couple of factors eventually led me away from it that have nothing to do with the language's quality so much as how it would interact with EE's other editing stuff (EDF in particular).

 

For a widely portable (ie not UNIX-centered) C++ port like EE, a less dynamic type-safe, wholly self-contained language is ideal and that is AngelScript. I'm looking at beginning integration of it sometime soon.

[Graf Zahl]

AngelScript seems to be the best indeed. For ZDoom the main problem was simply that it would have made native inheritance a major hassle.

That was the ultimate reason to roll out our own one in the end, I actually would have preferred to use something already functional but it would have made it exceedingly unwieldy to use it for what it was meant for: Inheriting from native classes and creating scripted subclasses that for the native parts of the engine just act like an internal one.