What small improvements from BOOM/MBF could be made in a new standard?

[traversd]

No worries. Hope this helps clarify.

 

1. I'm proposing to move the voodoo doll setup away from duplicated player starts so that mappers can (more easily) set game type settings - player starts ignore difficulty and game type flags. Additionally if any sort of "voodoo helper" linedef specials or other additions get proposed, it might be better to not have them affect the player thing type. Lastly, if the new thing walked in one direction at a constant speed (irrespective of skill setting) then that might go some way to alleviating the slight variances in conveyor speed/implementation described earlier.

 

2. I think the above covers this but will also note I'm not proposing to change what voodoo dolls currently do, in order for backward compatibility with boom/MBF they should stay as is. His proposal is a new thing type that could be used going forward in place of the existing option.

 

3. Player start voodoo dolls can trigger all walkover linedefs. If you use a non-player thing as a voodoo doll you can then set difficulty and game type settings - but at the expense of being restricted to walkover linedefs that only monsters (or rather non-player) things can trigger.

 

I think most of the proposed new linedef specials were implemented to allow non-player thing activation then a new thing may not be seen as a necessity (TBH I see it as a nice to have even now).

[Blastfrog]

Some kind of special "voodoo script" actor is a good idea. Have it move at a fixed speed like a monster, or like the player in Wolf 3D, so that differences in physics won't screw it up. Would also be useful in C/S ports where players may join and quit at will, not to mention that it's far less hacky in general than using an actual voodoo doll.

[Graf Zahl]

I repeat myself:

 

Before hacking the game physics system for such things it'd make more sense to port Doom64's macros.

 

I don't know. Implementing an actor hack to easier support the conveyor scripting hack sounds a bit too hackish to me. It somehow shows a profound lack of forward vision.

 

[PanterD2S]

maybe put "switching back to SR40 as default" on the agenda - so I can keep some infamous WR´s for another 20 years ;)

[traversd]

I guess I'm a bit backwards yeh. I've only made Boom or vanilla maps so in suggesting small improvements I'm staying close to home ;)

 

I figured adding a new thing that builds upon the existing way Boom maps implement scripts was less involved than implementing text scripts. Looking at the info on DoomWiki for D64 macros, it seems that many existing linedef specials would need to be recreated because they rely on the triggering linedef as a reference. Additionally it appears you cannot do loops or conditions? Appreciate that what might be done here would look to address those short comings, but it seems more involved than a new thing that pretends it is a player for the purpose of activating existing specials.

 

Another consideration is that existing map editors would only need to know the new things number as opposed to text editing/saving to a new lump - yes you could edit outside of the editor but that seems more involved than placing a "voodoo" thing on the map.

 

EDIT: A D64 type macro implementation would also need to allow difficulty/game type conditions as well.

Edited May 26, 2017 by traversd

[Blastfrog]

For the record, I loathe voodoo doll scripts. I only thought that having a simple actor for the purpose was a good idea in the context of not adding scripting.

 

I'm wondering though, if scripting is to become some kind of standard feature (and really, it ought to be), wouldn't it be better to go with a real scripting language like ACS, than an automated linedef trigger sequencer such as MACRO?

[kb1]

On 5/25/2017 at 7:47 AM, Graf Zahl said:

I repeat myself:

 

Before hacking the game physics system for such things it'd make more sense to port Doom64's macros.

 

I don't know. Implementing an actor hack to easier support the conveyor scripting hack sounds a bit too hackish to me. It somehow shows a profound lack of forward vision.

 

I'd like to see some info on Doom64's macros. Have a link? Got it: DoomWiki Macros - thanks traversd

 

You're absolutely right: voodoo doll scripting is VERY hackish, and real scripting is the most logical approach.

But, here's the rub: Voodoo dolls and conveyors exist, and we have to support them, and people use them for map logic. We have to support it. I have 3 thoughts on this:

1. If a small set of new linedefs allow a Doom (or whatever) mapper, to do some new triggery-type voodoo doll tricks that are easy to implement, why not? Since we have to support dolls and conveyors anyway, it's a simple way to provide some low-level abilities. Some ports will never add scripting, so it's an important thing to support, hack or not.
2. There is a specific case where things on conveyors get stuck (monsters and voodoo dolls mostly). Visually, this looks shitty, and, of course, causes problems, even if your not using voodoo dolls. I want to investigate this specific case, and see what can be done. Yes, messing with the game physics is a bad idea: comp levels, demo sync issues, game feel changes, etc. But, Boom fixed the "monsters get stuck in doorways" bug with a half-dozen lines of code, by randomly bouncing the monster in a different direction. Maybe the conveyor belt problem is similar. Maybe another option could be added: "monsters get stuck on conveyors", and maybe the bug could be fixed. I've seen this bug ruin maps that didn't have voodoo dolls, so it's worth investigating.
3. Maybe a handful of new dedicated script actors could be created, that work like voodoo dolls, without the tie-in to a player. Each actor type could do something besides killing Player 1 when they die. Maybe these actors are invisible. Maybe they call codepointers that let them do stuff.

It's not unreasonable to show a little love to the voodoo/conveyor scripters: If it's easy to do, and it allows some neat fun maps to be built with the technology the mapper knows, that's a good thing. Graf, you're absolutely right: Messing with the game physics is generally a very bad thing to do. But doing a bit a research on the "stuck on conveyors" issue is important, and a fix may be ridiculously easy to code. It's worth looking into.

 

Voodoo doll scripting (VDS) is a form of programming, almost like electronic engineering. The voodoo doll is the electron, the conveyor belt is the wire, and the trigger is like an electrical switch. It's a neat concept! I believe it is a stepping stone to actual scripting. VDS is very limited in what you can do with it, which will entice mappers that need more to move on to scripting. It is amazing that it works as well as it does, and I intend to honor its functionality, and even improve it a bit, if possible. None of that interferes with any real scripting, so, why not?