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

[Jon]

I've read through the entire thread (please god shoot me now) and I've tried to flesh out an example only wiki page demonstrating how I would imagine a summary-style draft page of features to include would look like. It's rough, it's not intended to be me taking over editor ship of this, just an illustration, and I didn't bother to flesh out some of the proposals with technical details (implementation notes, type numbers, etc.) I also missed a lot of stuff out due to the meandering arguments that make up 90% of this thread. Feedback appreciated. https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B#Specification

[Xaser]

@Jon Super-thanks for doing this!

 

One thing I'd suggest adding to the DEHACKED section is a range of blank Things, in addition to States, so it's possible to add new decorative objects & monsters with DEH. Dunno if I remembered to mention that when I echoed the suggestion, but that was the other big piece of the puzzle.

 

[Weapons and items are absolutely out of scope, of course.]

[Graf Zahl]

I actually do not see much of a point in extending Dehacked if some actual content definition language becomes part of the standard. It would offer the same capabilities with significantly less convenient editing capabilities.

 

[Xaser]

If DECOLITE can sneak into the first "draft" of the standard, then sure, but that seems like an awful lot to chew at once. The DEH extensions would serve as an inoffensive stopgap that ought not gum up the works any more than DEH's presence already does. [Presumably, at least.]

[Jimmy]

>_>

 

<_<

 

TX_ marker support please? <:D

 

I hate the TEXTURE1/PNAMES lumps so damn much.

[BigDickBzzrak]

Stacked TEXTUREx and PNAMES (like ZDoom does) would be nice, too.

[fraggle]

3 hours ago, Quasar said:

The way most mainstream dynamic language interpreters are written is simply hostile to multiplatform game development, and to game engine performance in general.

These seem like bizarre reasons to be choosing a language though. It sounds a bit like you're saying "this can't work well with the nuts.wad use case where you have a million monsters, so we won't even consider it". Why focus on that as the most important thing?

 

I want something that beginners can pick up easily. Something that people can have fun with and that will work well enough on most maps. Can't we focus on the users and make something that's fun to play around with? Performance is important at all but sometimes it's nice to let your hair down and do something more experimental, interesting and imperfect.

[Graf Zahl]

1 hour ago, Xaser said:

If DECOLITE can sneak into the first "draft" of the standard, then sure, but that seems like an awful lot to chew at once. The DEH extensions would serve as an inoffensive stopgap that ought not gum up the works any more than DEH's presence already does. [Presumably, at least.]

 

A lot of work is already done in my PrBoom fork. I don't really see a big problem with this part.

 

16 minutes ago, fraggle said:

These seem like bizarre reasons to be choosing a language though. It sounds a bit like you're saying "this can't work well with the nuts.wad use case where you have a million monsters, so we won't even consider it". Why focus on that as the most important thing?

This is important because if performance goes down the drain the whole thing is useless.

 

17 minutes ago, fraggle said:

I want something that beginners can pick up easily. Something that people can have fun with and that will work well enough on most maps. Can't we focus on the users and make something that's fun to play around with? Performance is important at all but sometimes it's nice to let your hair down and do something more experimental, interesting and imperfect.

 

Nice on the surface but ultimately self-defeating. If the scripting becomes a performance hog, those more experimental things are what it will be used for, but for serious use cases may just not be usable.

 

[kb1]

11 hours ago, Jon said:

...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...

Not going to start a holy war here, but modern BASICs hang with the big boys, and, arguably can be superior at lots of tasks. I can envision it being a perfect fit for scripting. It all about the task being performed. That's what *should* dictate the toolsets being used.

[Lollie]

7 hours ago, Graf Zahl said:

Nice on the surface but ultimately self-defeating. If the scripting becomes a performance hog, those more experimental things are what it will be used for, but for serious use cases may just not be usable.

 

What would you consider to be a "serious" use case? What makes a simple language less suitable than a dynamic language?

 

I can only speak as an enthusiast here when it comes to Doom, but this really resonates with me:

On 6/28/2017 at 0:19 AM, fraggle said:

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.

You could be an absolute programming wizard and pick the tightest dynamic scripting language ever, and a level designer would still look at it as if it were nothing but hieroglyphics. Unless your project is doing something wildly different, most artists aren't going to need the serious tools — there's a reason why most work with visuals, and not code. We appreciate when something simple is available to us, it lowers the bar for entry and makes development tools more accessible.

[Quasar]

10 hours ago, fraggle said:

These seem like bizarre reasons to be choosing a language though. It sounds a bit like you're saying "this can't work well with the nuts.wad use case where you have a million monsters, so we won't even consider it". Why focus on that as the most important thing?

 

I want something that beginners can pick up easily. Something that people can have fun with and that will work well enough on most maps. Can't we focus on the users and make something that's fun to play around with? Performance is important at all but sometimes it's nice to let your hair down and do something more experimental, interesting and imperfect.

I certainly don't disagree, not from a perspective of an experimental or for-fun project anyways. But when it comes to EE development I have to think about things like how the scripting VM will behave if the game's been running for 3 hours during a super long play session, and a language like JavaScript has to garbage-collect doubles because they don't fit into its normal 32-bit word size (this is at least true for the version of SpiderMonkey we were evaluating back then). If virtually everything in the engine were to allow being overridden with scripts - scripted status bar, scripted intermissions, scripted finales, scripted menus, etc., then you're talking about a lot more code running in the system than just whatever may power custom actors.

[kb1]

7 hours ago, Jon said:

I've read through the entire thread (please god shoot me now) and I've tried to flesh out an example only wiki page demonstrating how I would imagine a summary-style draft page of features to include would look like. It's rough, it's not intended to be me taking over editor ship of this, just an illustration, and I didn't bother to flesh out some of the proposals with technical details (implementation notes, type numbers, etc.) I also missed a lot of stuff out due to the meandering arguments that make up 90% of this thread. Feedback appreciated. https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B#Specification

Whoa! I somehow missed a few posts. Thanks for doing this! I was considering a pure HTML page/folder thing, but, if the maintainers don't mind, the DoomWiki seems like an excellent place to host this, discussion and all. (You weren't very serious about the content, other than listing a couple of points, were you?)

Yeah, shoot me first!

5 hours ago, Xaser said:

@Jon Super-thanks for doing this!

 

One thing I'd suggest adding to the DEHACKED section is a range of blank Things, in addition to States, so it's possible to add new decorative objects & monsters with DEH. Dunno if I remembered to mention that when I echoed the suggestion, but that was the other big piece of the puzzle.

 

[Weapons and items are absolutely out of scope, of course.]

Yep, recently mentioned. Thanks.

 

5 hours ago, Graf Zahl said:

I actually do not see much of a point in extending Dehacked if some actual content definition language becomes part of the standard. It would offer the same capabilities with significantly less convenient editing capabilities.

 

Come on, man - I've been discussing this idea for pages and pages. Don't back out on me now. The rationale was to add value to support an immediate benefit for adopting the spec. Again, the possibility of a few new actions, like a handful of new linedefs, and a handful of new action codepointers. A cherry on top. Dehacked is a valid way to mod things, which fits in with the new action codepointers. And, I thought we were in agreement that Thing/frame defs were not part of a first spec - we were both very clear about that. Please stay relaxed and focused. Please let me be the one handling the stress at this stage. I know you've been busy contributing UMAPINFO, and even working on DECORATE-Lite, which is very very cool and helpful. But, there's no rush. Let's take our time to make sure everything falls into place. The work I was considering for DeHacked is easy to implement and support, and will be immediately helpful to those that like to mod that way. Obviously, ThingDefs are more powerful, but also more advanced, to build, and to learn (ironically), simply because some people have been DeHacking for many years (and they are not interested in learning a new way). I want to support those people, and that avenue of modding, to some degree.

 

3 hours ago, fraggle said:

These seem like bizarre reasons to be choosing a language though. It sounds a bit like you're saying "this can't work well with the nuts.wad use case where you have a million monsters, so we won't even consider it". Why focus on that as the most important thing?

 

I want something that beginners can pick up easily. Something that people can have fun with and that will work well enough on most maps. Can't we focus on the users and make something that's fun to play around with? Performance is important at all but sometimes it's nice to let your hair down and do something more experimental, interesting and imperfect.

I agree with your reasoning, 100%. But, I am hoping we can soon steer this thread away from scripting, which is out of scope. Maybe a new thread could be devoted to scripting engine compatibility. I must repeat: Scripting will be the most difficult thing to get us programmers to agree on.

3 hours ago, Graf Zahl said:

 

A lot of work is already done in my PrBoom fork. I don't really see a big problem with this part.

 

This is important because if performance goes down the drain the whole thing is useless.

 

Nice on the surface but ultimately self-defeating. If the scripting becomes a performance hog, those more experimental things are what it will be used for, but for serious use cases may just not be usable.

Performance-wise, a scripting language can generally be placed into one of these categories:

• Interpreted (at run-time)
• Byte-code VM
• Compiled

Any one of those would be fine for most scripts, in any language with a decent implementation. And if it's a byte-code VM, any decently written language will be fine. There is no correlation between performance and language, when describing the handling of integers, floats, or even strings in a byte-code VM of C-like, Java, Lua, or BASIC flavor of language semantics for a Doom scripting, unless it is written poorly.

 

My point is that you have to really mess something up to make an easy-to-edit script language run poorly on most systems. Programmers are free to use just about any modern-ish language they see fit. And, nowadays there's lots of free languages and compiler code out there.

[kb1]

10 minutes ago, Quasar said:

If virtually everything in the engine were to allow being overridden with scripts - scripted status bar, scripted intermissions, scripted finales, scripted menus, etc., then you're talking about a lot more code running in the system than just whatever may power custom actors.

My plan is to call the built-in C code, unless the programmer "checks out" an event. At that point the built in stuff is replaced by the equivalent function, "pre-decompiled" if you know what I mean. And, upon saving the modified code, if a clean up check proves that the code matches original, go back to the original function. This should preserve as much performance as possible, without sacrifice.

[Altazimuth]

18 hours ago, Jon said:

I've read through the entire thread (please god shoot me now) and I've tried to flesh out an example only wiki page demonstrating how I would imagine a summary-style draft page of features to include would look like. It's rough, it's not intended to be me taking over editor ship of this, just an illustration, and I didn't bother to flesh out some of the proposals with technical details (implementation notes, type numbers, etc.) I also missed a lot of stuff out due to the meandering arguments that make up 90% of this thread. Feedback appreciated. https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B#Specification

 

Last I checked, we don't support 16-rotation actors, and probably won't in the foreseeable future. We also have no way of doing hires replacements afaik (though this is something I'd like (but I have no idea how one would go about it)).

 

Linedefs seem feasible, though we've got no support for animated doors.

 

Sectors seem decent, though I'd like to see a clean implementation with the godmode one, as I can't think of anything too neat at the moment. The player touching floor teleporter seems like a gateway to the superpowerful ZDoom "on actor does [FOO]" actors, though they need Hexen or UDMF; I'm super for this if we can figure out an intuitive way for the mappers to do this. The last one ("grouped sector for special action") seems like it would benefit from Eternity's attached surface lines, unless that's what you're suggesting.

 

As for the additional state stuff, that could be doable but some stuff needs to be considered when thinking about Eternity interop, as is stated here:

 

Edited June 29, 2017 by Altazimuth : Found that post I was looking for. Added thoughts on sector.

[Jon]

4 hours ago, kb1 said:

Whoa! I somehow missed a few posts. Thanks for doing this! I was considering a pure HTML page/folder thing, but, if the maintainers don't mind, the DoomWiki seems like an excellent place to host this, discussion and all. (You weren't very serious about the content, other than listing a couple of points, were you?)

Great. So, I suggest you register a Doomwiki account, et me know what your name is and we can rename that page out of my namespace (User:Jdowland/boom++) to yours (User:whatever/whateveryouwant), and you can take it forward. Or just edit it where it is, whichever you prefer.

 

As for the content, it is just meant to be illustrative but reflects my understanding of what proposals reached any kind of consenssus in this thread. I haven't been following it as closely as you though which is why it probably seems odd. Let's fix it!

[Da Werecat]

9 minutes ago, Altazimuth said:

Last I checked, we don't support 16-rotation actors, and probably won't in the foreseeable future.

My wad with 16 rotations for some actors was actually preventing Eternity from loading until I took away the additional frames. Maybe something needs to be done about it. Not the actual support (although that'd be nice), but tolerance to the presence of such lumps, at the very least.

 

[Graf Zahl]

5 hours ago, Quasar said:

I certainly don't disagree, not from a perspective of an experimental or for-fun project anyways. But when it comes to EE development I have to think about things like how the scripting VM will behave if the game's been running for 3 hours during a super long play session, and a language like JavaScript has to garbage-collect doubles because they don't fit into its normal 32-bit word size (this is at least true for the version of SpiderMonkey we were evaluating back then). If virtually everything in the engine were to allow being overridden with scripts - scripted status bar, scripted intermissions, scripted finales, scripted menus, etc., then you're talking about a lot more code running in the system than just whatever may power custom actors.

 

Indeed. Script code can very quickly add up to a lot of processing time if the chosen language is not efficient.

However, compared to actor logic the UI stuff is actually all peanuts because there's only one menu, only one status bar, only one intermission etc. active at any time whereas there can be thousands of in-game actors.

4 hours ago, kb1 said:

Performance-wise, a scripting language can generally be placed into one of these categories:

• Interpreted (at run-time)
• Byte-code VM
• Compiled

Any one of those would be fine for most scripts, in any language with a decent implementation. And if it's a byte-code VM, any decently written language will be fine. There is no correlation between performance and language, when describing the handling of integers, floats, or even strings in a byte-code VM of C-like, Java, Lua, or BASIC flavor of language semantics for a Doom scripting, unless it is written poorly.

 

That distinction is a bit too rough. What's far more important is how the underlying paradigm affects performance.

 

For example, dynamically allocated variables are more costly than static variables, because they may be subjected to garbage collection. Implicitly dynamically allocated variables are the worst because the scripter never sees it happen.

Dynamically typed variables may require run-time lookup of their contents because it may not always be clear from the context what type they actually contain.

The worst is dynamic structs where any field name goes and it is only checked on access if a field exists or not and you can pass in everything. A hashtable lookup for each such access can easily double ot triple execution time, depending on how the code is written and even if you add a JIT compiler, that lookup cost will still be there most of the time.

 

And so on.

 

For performance, languages which never need to run any lookup code to get to their data are inevitably faster than ones that allow a lot of dynamism here which needs to be considered in the VM. And you can be sure that in the context of Doom this can be very relevant due to some of the more 'extreme' types of maps where there's not just a few tens of active monsters but a few hundred, if not thousand. Then, even a per-actor execution time of 0.01 ms would be too much.

 

Regarding the choice of language I see the same stupid argument here that made Lua happen, i.e. the assumption that unknowledgeable people have less difficulty learning a more verbose language because the words describe the action.

I never bought into this and ultimately always felt that such languages are hard to read and even harder to learn because there's a lot more vocabulary one needs to master before being able to use them.

 

The same can be said about dynamically typed languages. I've never seen what's so great about them. I have developed some Javascript code and since it defers many error checks to run time instead of compile time, it needs significantly more test setup to ensure it's free of programming errors, many of which a C++ compiler would already complain about.

Again, they only make things easier on the surface. In particular they make it easier to write broken code that may cause problems on the user's side, not the developer's, because in cases like in-game scripting you can be dead certain that those test setups aren't even considered. So ultimately, the more errors the compiler finds, the better. It still won't make it foolproof but it will surely stop people from calling a string function with some object pointer, hoping it will yield a useful result.

 

 

 

 

[printz]

On 27.06.2017 at 4:19 PM, fraggle said:

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.

Why is that fundamentally wrong? It merely looked to me like a subjective design choice to require commas instead of semicolons. It even fits with the function syntax. What basic operations were made difficult because of having commas instead of semicolons? I can only think of the comma operators requiring grouping in that case... and that's already a rare use.

 

EDIT: What about instead of text-based scripting language, you have a nice graphical flow diagram editor? So instead of typing "script 1 (void)" mumbo-jumbo, you open SLADE (or a plug-in of GZDBBF) and draw diagrams.

Edited June 29, 2017 by printz

[Linguica]

20 minutes ago, printz said:

Why is that fundamentally wrong? It merely looked to me like a subjective design choice to require commas instead of semicolons. It even fits with the function syntax. What basic operations were made difficult because of having commas instead of semicolons?

Fragglescript was a C-esque language, and I think it's generally considered bad practice to arbitrarily change syntax from what people would normally expect for no good reason.

[wesleyjohnson]

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.

[Arctangent]

I don't think there was any actual intention on adding scripting that affects the core engine to the standard, because that's just silly. I think the only reason that topic came up was because a guy mistook ZScript for something intended for map scripting, and explaining that it wasn't derailed the train of thought a bit.

[wesleyjohnson]

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.

 

 

[wesleyjohnson]

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.

 

[wesleyjohnson]

Quote

 

KB1: 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.

 

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.

[wesleyjohnson]

Quote

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")

Quote

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",

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).

 

[printz]

4 hours ago, Linguica said:

Fragglescript was a C-esque language, and I think it's generally considered bad practice to arbitrarily change syntax from what people would normally expect for no good reason.

Except that that syntax change was one of the first details mentioned for anyone wanting to learn about FraggleScript. Obvious enough not to confuse.

[Xaser]

The fact that it has to be explained makes it the literal opposite of "obvious."

[kb1]

@Altazimuth16-rotation setups should, at least, not trip up your sprite initialization (as Da Werecat describes). Can you describe the ZDoom "on actor does [FOO]" stuff? I'm not sure what you mean. As for the extra DeHacked states, of course Eternity would be free to move and/or renumber those states around as it sees fit. (I don't know what difficulties that imposes on Eternity, so I can't suggest an appropriate workaround/solution, or even if it's feasible. Seems naively do-able, though.)

 

@JonOk, sounds good. I'll get that ball rolling once I get closer to being ready. Thanks for the welcoming enthusiasm!

 

@Graf ZahlI did simplify my explanation. I know that scripts can ruin the game experience, and poorly written, or poor-fit languages can seriously contribute to that. I just meant that there's a lot of flexibility within those requirements, as to the look and feel of the language. I do believe that there is a level of appropriateness as to how easy vs. how powerful the chosen language is. You have to know that you could be a little biased here: You're a veteran programmer, who has certain informed ideas of what makes a language good. You want power, symmetry, and cleanliness, right? And, yes, future programmers would benefit from that type of design. But there is a learning curve, and many modders do not want to be programmers - they simply have a design in mind, so they need to do what it takes to execute that idea. To them, it's a necessary evil. For them, making it easy is important. And those with more skill can read ANY language. I think there's room for easy-to-learn AND powerful.

 

Let me be clear: Your ZScript stuff is fascinating. It looks very capable and well-thought out. The bigger point is that, I don't think it's possible for us all to agree on a script language.

 

And, I wish the script stuff was in a different thread...

 

@printzMy only experience with graphical code designing was with designing maintenance routines for MS SQL Server. It's a very interesting way to design. I struggled with trying to make the boxes big enough, and to clean up all the decision lines! I remember thinking "They worked their ass off to build this system".

What about building it in 3d, in the game renderer!

 

@wesleyjohnsonI've been combining all your posts on TRIG-TAG, and I have a bunch of varied stuff on the subject, yet I still don't have a clear spec. For there to be a chance for it to ever see the light of day, someone is going to have to boil down all of those posts into a specific spec, with explanations of terms, and lists of the various pieces. Many even a few diagrams to make the concept clear. I'm not saying that you have to do this. But, honestly, at this stage, I don't know where to begin. You ask if people understand what we're trying to do: I don't understand what you're describing that we do. I've stopped trying, cause there's so much "random" information - I don't know how many of the other posts I need to read first, or which new posts should replace the older posts, or simply which order I need to read them in.

 

I think I understand the basic concept - you are describing a new system. This actually puts TRIG-TAG kinda out of scope for what I was trying to accomplish, certainly in the first phase, anyway. I was most concerned with compatibility, with a few new tricks to make it worth implementing. The sheer size of my first spec pales against the size of this complete new system you describe, doesn't it? Without fully understanding, I was hoping that traversd's idea of firing all of a sector's actions, based on a controlling trigger would cover most of what you were describing, and be a simple-to-add type thing, but I guess it can't. His method can be described and implemented simply, as it is simply a new way to trigger what's already there.

 

I may be misinterpretting the scope of this thing - and that's part of the issue. I get this sinking "scope creep" feeling. I was leaning towards taking things already existing in ports, and exposing them in a compatible way. This new system you describe affects the save game system, it involves new previously-unused triggers, including a keyboard-mapped trigger,, so it could affect keybindings. It requires new line/sector searching algorithms. I didn't want to get involved in something of this magnitude, especially in the first stages of this thing.

 

Maybe it can fit into a down-the-road phase, after the major compatibility hurdles have been crossed, and some adoption has happened. But, then, it would need to be pre-implemented, tested and verified, and completely documented.

 

The last thing I want to do is discourage you. It sounds promising, interesting, and powerful. It makes me feel like shit to post this. I just can't go down this path at this time - it's too big, and there's too much at stake, in the spec's infancy. Please try to understand this from my perspective. I can't drop a 10-pound box into the spec, and expect it to fly, you know?

 

Please don't stop building it, but for the future, ok?

 

 

[Graf Zahl]

21 hours ago, Altazimuth said:

 

Last I checked, we don't support 16-rotation actors, and probably won't in the foreseeable future. We also have no way of doing hires replacements afaik (though this is something I'd like (but I have no idea how one would go about it)).

 

16 rotations is really not that hard to do. A few added checks when initializing and a few more when calculating the added rotation. This really should not be a show stopper.

 

 

21 hours ago, Altazimuth said:

 

Linedefs seem feasible, though we've got no support for animated doors.

 

Again, they are relatively simple to implement so not having them in your engine should not be a factor.

 

 

 

21 hours ago, Altazimuth said:

The last one ("grouped sector for special action") seems like it would benefit from Eternity's attached surface lines, unless that's what you're suggesting.

 

Sounds like the same thing so should be implemented in a compatible fashion as ZDoom implements the same feature as well.

 

 

 

21 hours ago, Altazimuth said:

 

As for the additional state stuff, that could be doable but some stuff needs to be considered when thinking about Eternity interop, as is stated here:

 

 

I cannot see any limitations for real Dehacked stuff in there.

However, if someone really thinks that Eternity's feature set needs to be protected: What for? Where's the released maps depending on that?

 

 

Regarding TRIG-TAG:

 

I'm sorry, but I still have difficulities comprehending this stuff. I really don't think this should be in here.

 

6 hours ago, kb1 said:

Can you describe the ZDoom "on actor does [FOO]" stuff? I'm not sure what you mean.

 

I think he means ZDoom's sector action things. These can be placed in any sector and trigger their special if the player performs a specific action in that sector.

 

6 hours ago, kb1 said:

Let me be clear: Your ZScript stuff is fascinating. It looks very capable and well-thought out. The bigger point is that, I don't think it's possible for us all to agree on a script language.

 

The far bigger problem is that any scripting language outside superficial map scripting will have to expose some inner workings to the surface.

This plain and simply will never be doable in any compatible fashion between ports.

Stuff like ACS or FraggleScript works on an entirely different level.

 

[Jon]

11 hours ago, kb1 said:

And, I wish the script stuff was in a different thread...

 

 

Me too, so here it is!