Did you know you can make a voodoo conveyor belt in vanilla Doom

[Linguica]

In one sentence, it effectively implements a new W1/S1 trigger in vanilla that activates an arbitrarily timed sequence of vanilla line W* actions.

[-TDRR-]

le stupid idea that might not even be useful

 

What if someone made a Doom Builder 2 (and it's derivatives) plugin that would allow you to write an ACS-like script that would then spit one of these beauties into the map?

[Jon]

33 minutes ago, -TDRR- said:

le stupid idea that might not even be useful

 

What if someone made a Doom Builder 2 (and it's derivatives) plugin that would allow you to write an ACS-like script that would then spit one of these beauties into the map?

 

I'm not sure what ACS would bring to the table but a Lua plugin would make sense. One can use wadc to spit out just the vanilla conveyor sectors and copy and paste them too

[-TDRR-]

23 minutes ago, Jon said:

I'm not sure what ACS would bring to the table but a Lua plugin would make sense. One can use wadc to spit out just the vanilla conveyor sectors and copy and paste them too

ACS-like in the sense of, say, stuff like typing in delay(amountoftime) and getting the expected delay until the next action, which can be typed in like: Door_Open(tag) or something to that effect. Could also be useful for easily translating your work into ACS so it works in ZDoom-family ports too.

 

WadC is cool and all but honestly it's quite unconvenient to have to make a new textfile, then type in your code, compile it, open the map in Doom Builder, copy it and then paste into your map. All of this just for something you could do with the editor itself and using WadC in this case is almost pointless because it isn't any simpler than to just do it manually.

[Jon]

Just now, -TDRR- said:

ACS-like in the sense of, say, stuff like typing in delay(amountoftime) and getting the expected delay until the next action, which can be typed in like: Door_Open(tag) or something to that effect. Could also be useful for easily translating your work into ACS so it works in ZDoom-family ports too.

 

I see what you mean 

 

Just now, -TDRR- said:

 

WadC is cool and all but honestly it's quite unconvenient to have to make a new textfile, then type in your code, compile it, open the map in Doom Builder, copy it and then paste into your map. All of this just for something you could do with the editor itself and using WadC in this case is almost pointless because it isn't any simpler than to just do it manually.

 

Its definitely less convenient than an integrated Lua script would be and I hope someone writes one... But it's far more convenient than doing it by hand. Especially if there's any chance you want to experiment with adding or interleaving triggers or tweaking timings as the map develops. 

[kb1]

4 hours ago, therektafire said:

@kb1basically how a vanilla voodoo conveyor works is you crush a barrel to push the voodoo doll like you normally would in vanilla BUT you set up the conveyor such that the conveyor itself is at the vertical height limit of -32768 and the doll starts slightly above that, so what happens is the barrel pushes the doll onto the conveyor and the doll tries to fall but its height overflows to a really high number so the game places it at the height of the conveyor sectors ceiling, this will repeat forever because its impossible for the doll to actually touch the ground if it is falling onto it and the ground is at the height limit. Since it never hits the ground it never loses its horizontal speed so it "scrolls" down the conveyor as if you used a scrolling floor. Of course linedef triggers arent effected by this in any way since you can trigger them in the air. So it's sort of like having a one time use boom conveyor (its one time use because afaik there's no way to get the doll back to the beginning again without losing its momentum)

 

So basically what it affords a mapper is that it allows you to easily do multiple scripted actions with a singe conveyor which wasn't possible before

 

3 hours ago, Linguica said:

In one sentence, it effectively implements a new W1/S1 trigger in vanilla that activates an arbitrarily timed sequence of vanilla line W* actions.

Beautiful! And good explanations!

 

Ok, now let me *really* show my mapping ignorance:

 

Don't take this the wrong way, but: Why is this special? What is this affording vanilla that wasn't possible before? Is it the fact that you've found a way to trigger multiple sequential triggers? (I assume that's what Linguica's nuke flood GIF is portraying, right?)

[-TDRR-]

40 minutes ago, kb1 said:

Is it the fact that you've found a way to trigger multiple sequential triggers? (I assume that's what Linguica's nuke flood GIF is portraying, right?)

Yes, take it as some sort of scripting, except for Vanilla Doom, That's a massively useful discovery.

[kb1]

4 minutes ago, Jon said:

 

I see what you mean 

 

 

Its definitely less convenient than an integrated Lua script would be and I hope someone writes one... But it's far more convenient than doing it by hand. Especially if there's any chance you want to experiment with adding or interleaving triggers or tweaking timings as the map develops. 

<slight_derail>

That's what I was trying to get at a couple of years ago: Editor support for WadC - Something like a plugin, built into, say, DoomEditor, that let's WadC directly modify the currently-displayed map.

 

Imagine drawing a door at the edge of your map, clicking the WadC button, and generating a new room off of that door - a room with all manners of symmetrical borders, indentations, shapes, etc.

 

In fact, highlighting some wall in the editor could be used as input to WadC scripts. For example, maybe you highlight the borders of a new room, then click a WadC script that calculates the room's dimensions, and uses the results to control parameters within the WadC script.

 

Not trying to derail this thread. I just wanted to say that I believe that WadC could exist in a symbiotic relationship with a general purpose map editor, with a much more robust interface than just sticking 2 tools together. Some WadC script directives could be added to glean info from the map editor's highlighted set. So many functionalities could become possible. And by carefully tasking advantage of the graphic coupling, WadC could become much more approachable to a larger audience. And, finally, instead of having to join multiple WadC effects via WadC script, you can rely on the strengths of having a full-blown editor, and you can 'script as you go'.

</slight_derail>

 

[kb1]

5 minutes ago, -TDRR- said:

Yes, take it as some sort of scripting, except for Vanilla Doom, That's a massively useful discovery.

Cool - now I get it. Yes, that's an awesome discovery. And, I do like the flooding effect. There was a old version of Legacy that had this really neat global translucent water effect. There was a single water_height level for the whole map, and you could "flood" the map by increasing this value.

 

The effect was kinda slow, which is probably why it didn't catch on. But, it was very cool looking, and it ran via the software renderer. Linguica's level reminded me of that effect (Does anyone remember the effect, or have a video showing it?)

 

By the way, why doesn't Doom's spell-checker understand "renderer"? Is it Doomworld's spell-checker, or is it local to my box?

[-TDRR-]

24 minutes ago, kb1 said:

By the way, why doesn't Doom's spell-checker understand "renderer"? Is it Doomworld's spell-checker, or is it local to my box?

There's no spell-checker on my side, so i'm guessing it's just your browser.

[Jon]

1 hour ago, kb1 said:

Cool - now I get it. Yes, that's an awesome discovery. And, I do like the flooding effect. There was a old version of Legacy that had this really neat global translucent water effect. There was a single water_height level for the whole map, and you could "flood" the map by increasing this value.

 

Yeah it (ab)used sector tag values, I think; you signalled a sector should have water with a negative tag value, and the magnitude of the value sets the absolute water height above 0, IIRC.

 

It looked pretty but had no physical effect in the map: nothing floated, no physics changes, etc.

 

1 hour ago, kb1 said:

 

The effect was kinda slow, which is probably why it didn't catch on. But, it was very cool looking, and it ran via the software renderer. Linguica's level reminded me of that effect (Does anyone remember the effect, or have a video showing it?)

 

I remember it. BTW, it's @Linguica's awesome video, but I built the level, and you can play a RC1 of it if you want:

 

 

 

[Maes]

1 hour ago, kb1 said:

<slight_derail>I just wanted to say that I believe that WadC could exist in a symbiotic relationship with a general purpose map editor, with a much more robust interface than just sticking 2 tools together.</slight_derail>

 

Well, if you think about it, that's pretty much how actual level generators work. They may be good at filling in the gaps, but thetrouble is getting a good "seed" of originality in them.

 

[Nine Inch Heels]

22 hours ago, Maes said:

A possible solution would be having the doll simply teleporting back to where it started, and have a weak monster attack it, e.g. placing it exactly in the melee range of a trapped lost soul, nudging it just enough so that it starts moving again. With all the problems/unpredictability that would bring about, of course. 

Short answer: No

 

Long answer: the current prefab Ling and I put together is specced to deal precisely 1 worh of damage on either ytytd or higher. And it's that amount of damage that determines the speed at which the doll moves along the mikoveyor. Not only would a trap-door-hackjob require you to have a monster in place that always deals 1 point worth of damage, no more no less (meaning anything melee is out of the equation anyway), but it would also require that monsters actively attack voodoo dolls, which they don't.

 

It would be much easier, and more reliable, to just push barrels over an action 97 linedef by a "faraway" explosion to replace a previous one, warp the doll back, and make the entire setup repeatable like that... Which is something I believe mappers who like to employ tricks like this will already be well aware of as an option. Slight issue here is, as with anything else that creates momentum by inflicting damage, that it's going to get progressively more complicated of a setup the more repeats you want to be able to support with it, because you need to compensate for the health loss of each repeat... Basically the more repeats the more unwieldy the setup becomes, but I'd still take that over some unreliable (and actually impossible) hackjob any day.

[Nine Inch Heels]

ehhh double post, sorry

[Maes]

Yep, figured out so (about the voodoo dolls). I wonder if by using DEHACKED it'd be possible to mitigate some of those problems (e.g. changing the amount of melee damage inflicted), or make constantly firing objects pointing in one direction (e.g. by adding a zombie firing codepointer to a static decoration).

[Linguica]

2 hours ago, Nine Inch Heels said:

it's going to get progressively more complicated of a setup the more repeats you want to be able to support with it, because you need to compensate for the health loss of each repeat...

 

You could stack stimpacks and use those instead of potions, each time the voodoo doll would grab one (although I forget the specifics of how a voodoo doll's health relates to the actual player health, and what if the player is already hurt...)

[SaladBadger]

I decided to look it up quickly since I didn't remember myself, if I'm reading that right having the voodoo doll pick up health heals your controlled body, but it does not heal the voodoo doll's body. This puts a limit on how many times you can get the doll going, but assuming you're only ever doing 1 damage to it at a time it seems unlikely you'll be setting it in motion 100 different times.

 

It's interesting to note that it's synced directly rather than applying the same operation to your body's health, so I don't see any potential problems where your body's health is different than what's shown on the status bar.

 

ed: oops, P_GiveBody isn't called on bonuses, but the operations are practically the same

[Nine Inch Heels]

15 minutes ago, Linguica said:

 

You could stack stimpacks and use those instead of potions, each time the voodoo doll would grab one (although I forget the specifics of how a voodoo doll's health relates to the actual player health, and what if the player is already hurt...)

Yeah, that's where I definitely see the problem of giving players more health than they would have lost. I'd imagine it would be "cleaner" to have potions spaced like 1 map unit apart on individual sectors, and lowering those in increments when a sequence gets completed, to feed the conveyor one potion at a time... It's gonna be a slightly tedious setup to build, but if done properly it should work reliably.

[kb1]

19 hours ago, Jon said:

 

Yeah it (ab)used sector tag values, I think; you signalled a sector should have water with a negative tag value, and the magnitude of the value sets the absolute water height above 0, IIRC.

 

It looked pretty but had no physical effect in the map: nothing floated, no physics changes, etc.

 

 

I remember it. BTW, it's @Linguica's awesome video, but I built the level, and you can play a RC1 of it if you want:

 

Oooh, I didn't realize I could play it - nice!

 

 

18 hours ago, Maes said:

Well, if you think about it, that's pretty much how actual level generators work. They may be good at filling in the gaps, but thetrouble is getting a good "seed" of originality in them.

I'm with you. But, that's not really what I meant, though. What I meant was that, with WadC integrated into the editor, WadC scripts could be written to query info from the map editor, to fill in some of the script variables you'd otherwise have to fill in manually when using WadC stand-alone.

 

I need to discuss this with Jon in a dedicated thread, but briefly:

Imagine you have a WadC script that "flood-fills" a rectangular room with small hexagon sectors of smoothly varying heights, for a slope-like effect (think of a long skateboard ramp). If you ran this script in stand-along WadC, you'd have to supply the floor and ceiling height, and X/Y dimensions of the room to fill, as well as which textures to use, and which tag numbers might be needed, etc. But, if WadC was integrated into the map editor, you could draw a rectangular room, highlight it, then click on a WadC button, and choose "skateboard ramp", and WadC could get all of it's info from the highlighted room, without the map developer having to enter any variables.

 

That's too simple of an example, but you get my drift. I think this would let people get past their initial fears of learning WadC, by making it just a bit more accessible. I think it could really open up a lot of possibilities. Another good example is the voodoo conveyor belt. In this way, WadC becomes a massively-powerful pre-fab tool, and much much more. It effectively marries WadC to the GUI and data framework provided by the map editor. It requires some imagination to realize how this puts the power of WadC in the hands of mere mortals :) Anyway, Jon, we can talk about this further

 

13 hours ago, Linguica said:

 

You could stack stimpacks and use those instead of potions, each time the voodoo doll would grab one (although I forget the specifics of how a voodoo doll's health relates to the actual player health, and what if the player is already hurt...)

@Linguica: Do you remember, in your movement research, how you had a situation where the player was pushing up against an obstacle, and somehow a momentum was built up, but not realized until the obstruction was removed, at which time the player jolted towards the now-removed obstruction? While this potential momentum was built up, the player would bob and run in place?

 

I'm just wondering if something like that could be done for the voodoo doll, whereas, in the first tic, you do the barrel + stimpack in rapid succession, so the damage is not noticed, and, sometime later, you remove the voodoo doll obstruction, and that kinetic momentum then thrusts the voodoo doll into the pit.

 

If this could work, you could hide the damage, avoid worrying about flaky damage effects later, and start the conveyor effects at your leisure. Does any of that ring a bell? Don't know if it would work for a voodoo doll, or if the display player's movement would negate the effect. But, if it could work, would that improve your setup?

[Linguica]

10 hours ago, kb1 said:

with WadC integrated into the editor

 

What you are describing already basically exists in Doom Builder X which has Lua scripting.

 

10 hours ago, kb1 said:

I'm just wondering if something like that could be done for the voodoo doll, whereas, in the first tic, you do the barrel + stimpack in rapid succession, so the damage is not noticed, and, sometime later, you remove the voodoo doll obstruction, and that kinetic momentum then thrusts the voodoo doll into the pit.

 

If a voodoo doll bumps into a thing in its path, it will retain its momentum and continue on once the thing disappears (according to my test now). So yes, you could place, say, a lost soul overlapping with the voodoo doll's path, and then crush the lost soul separately later, and the voodoo doll would continue on its path.

 

You could theoretically use this to "arm" several voodoo conveyors at once and then allow them to run later when the player crosses a second trigger, or to have a multi-stage "script" where it continues once the player reaches a certain point. Good thinking!

[kb1]

9 hours ago, Linguica said:

 

What you are describing already basically exists in Doom Builder X which has Lua scripting.

There I go reinventing the wheel again. Still, WadC is the big boss applesauce, as far as Doom scripting goes. I've been trying to devise a way to bring WadC mainstream for a few years now. I've always felt like it's just a bit too "cerebral" for many people. Tying it into a GUI that everyone knows and loves might be the catalyst I've been looking for. Two refined tools that specialize in map creation...seems like an inevitable conclusion to me. Such a tool would help someone like me, who's NOT artistically inclined, build a map mathematically, yet retain all the graphical tools to bring it together. Just a thought.

 

9 hours ago, Linguica said:

If a voodoo doll bumps into a thing in its path, it will retain its momentum and continue on once the thing disappears (according to my test now). So yes, you could place, say, a lost soul overlapping with the voodoo doll's path, and then crush the lost soul separately later, and the voodoo doll would continue on its path.

 

You could theoretically use this to "arm" several voodoo conveyors at once and then allow them to run later when the player crosses a second trigger, or to have a multi-stage "script" where it continues once the player reaches a certain point. Good thinking!

My goal was to solve the "inexplicable" health adjustments you might see as a result of getting the voodoo doll to move via explosion. My thoughts are that, you can get away with giving the voodoo doll a stimpak right at the beginning of a level. The player expects to pistol-start at 100% health, and 100% is the only number you can guarantee that you'll land on successfully, after a stimpak adjustment. If you can pull it off, you can immediately do the explosion and the stimpak adjustment, fully concealing that either one occurred, with the added benefit of being able to delay the conveyor indefinitely.

 

What a convoluted setup! But, it looks like it can actually be made reliable, which is pretty amazing! Nice trick! (Still teaching the old dog new tricks, eh?) Source ports should really do their best to emulate this - it's too powerful to write off as a "cheap vanilla trick". This trick is ready to become mainstream!

 

[xttl]

How did I miss this until now. :D

 

It's really too bad there is no way to do the launch without dealing damage. The most hiddenest way to do it would probably combine the PLAYPAL modification mentioned earlier, with sacrificing one of the health pickups and some DHE to change the pickup message. Actually: an unrelated pickup the doll will get right after the health item would also work because vanilla can only show one message at the same time. Or how about a savegame you're supposed to load when starting the map with the doll mobj already moving? (saw that thread too only now for the first time) ^{actually wouldn't work because it will lose momentum if you block it with a sector which later goes out of the way...}

 

 

On 4/3/2019 at 2:29 AM, Linguica said:

Really? No one else thinks this is interesting? Isn't this, like, the vanilla-compat holy grail, being able to do Boom-esque scripted events?

 

Personally, I think the ultimate vanilla mapping/modding trick would actually be finding a way to get arbitrary code execution from any loaded WAD. Preferably early in the game startup, but at map load time, at time of running the first tic, or while rendering the first frame wouldn't be bad either.

 

I've tried a bit to look into getting this working, but unfortunately I am no hacker extraordinaire after all. ;__; The only thing I've found so far is that the code which handles DMXGUS lumps (inside libDMX) allows you to overwrite stack contents with data from this lump, but obviously this only works if the user has GUS selected as the music card and the game must be able to detect it too. In addition, the first zero byte in the data will always terminate the copying of data from the lump since this is a string function (strcat) copying data to a fixed size buffer, and this zero byte will be replaced by a '.' (0x2E) from ".pat" which is further strcat'ed to the string to form a path to a GUS patch file on disk, which makes it difficult to write any good pointer values (they tend to have zeroes as the most significant byte) to the stack.

 

Exploitation of any possibly usable overflows or other bugs is also made difficult by the "ASLR" which is in effect. As probably everyone who's interested in Watcom binary hacking/reversing knows by now: you can't really trust DOS4GW to load the sections to same addresses every time... (though this wasn't really meant as a security feature like ASLR nowadays so depending on hardware and software config the addresses aren't guaranteed to always change either)

 

Perhaps Hexen could be a better candidate for this due to the multiple text-based game definition lumps it loads from WADs and parses, plus the ACS bytecode interpreter?

 

...now that I think of it, can the CPU execute code from VGA memory in DOS era PCs and DOSBox? Doesn't matter if it's slow as long as it works. That would always be guaranteed to be at the same address (0xA0000) no matter where DOS4GW relocates the LE sections. You could write code there by crafting special graphic patches and textures for the game to draw, then try to trigger a jump to 0xA0000 somehow!

Edited June 26, 2019 by xttl

[Nine Inch Heels]

On 5/22/2019 at 9:48 PM, kb1 said:

My goal was to solve the "inexplicable" health adjustments you might see as a result of getting the voodoo doll to move via explosion. My thoughts are that, you can get away with giving the voodoo doll a stimpak right at the beginning of a level. The player expects to pistol-start at 100% health, and 100% is the only number you can guarantee that you'll land on successfully, after a stimpak adjustment.

This part we already had solved. the prefab is made such that the doll receives only 1% of damage, which we can always compensate for with a health bonus. Added benefit being that this method supports continuous play much better since we never "overfeed" the doll, and can account for any health total, not just 100% but whichever value the player finished the previous map with(except 200 health).

Edited June 26, 2019 by Nine Inch Heels

[kb1]

I'm a bit late replying (vacation), but that's great. So, the deferred momentum trick can be useful for controlled multiple triggers. Complex scripting in vanilla! Sweet!

[Jon]

Mild bump to announce I released my demo map

 

[-TDRR-]

On 6/26/2019 at 11:36 AM, xttl said:

Personally, I think the ultimate vanilla mapping/modding trick would actually be finding a way to get arbitrary code execution from any loaded WAD. Preferably early in the game startup, but at map load time, at time of running the first tic, or while rendering the first frame wouldn't be bad either.

 

I've tried a bit to look into getting this working, but unfortunately I am no hacker extraordinaire after all. ;__; The only thing I've found so far is that the code which handles DMXGUS lumps (inside libDMX) allows you to overwrite stack contents with data from this lump, but obviously this only works if the user has GUS selected as the music card and the game must be able to detect it too. In addition, the first zero byte in the data will always terminate the copying of data from the lump since this is a string function (strcat) copying data to a fixed size buffer, and this zero byte will be replaced by a '.' (0x2E) from ".pat" which is further strcat'ed to the string to form a path to a GUS patch file on disk, which makes it difficult to write any good pointer values (they tend to have zeroes as the most significant byte) to the stack.

 

Exploitation of any possibly usable overflows or other bugs is also made difficult by the "ASLR" which is in effect. As probably everyone who's interested in Watcom binary hacking/reversing knows by now: you can't really trust DOS4GW to load the sections to same addresses every time... (though this wasn't really meant as a security feature like ASLR nowadays so depending on hardware and software config the addresses aren't guaranteed to always change either)

 

Perhaps Hexen could be a better candidate for this due to the multiple text-based game definition lumps it loads from WADs and parses, plus the ACS bytecode interpreter?

 

...now that I think of it, can the CPU execute code from VGA memory in DOS era PCs and DOSBox? Doesn't matter if it's slow as long as it works. That would always be guaranteed to be at the same address (0xA0000) no matter where DOS4GW relocates the LE sections. You could write code there by crafting special graphic patches and textures for the game to draw, then try to trigger a jump to 0xA0000 somehow!

**warning: unexpert talk follows**

 

I think restricting ourselves to the original .exe is just way too hard and restrictive like to do anything at all with arbitrary code execution.

I'm no programmer, but i think it would be much easier to set up some way to make the .exe just blindly accept whatever the DMXGUS lump says, and if possible force it to load every time.

I think this allows for code execution directly when the game starts since music playback is needed since the title screen appears, and most likely DMXGUS is parsed some time before that. Maybe you could also change the name of the DMXGUS lump to EXCODE or something, so normal DMXGUS lumps don't cause crashes.

Then distribute the .exe modifications as patches, using whatever file patching program is available for DOS.

 

But Hexen could be interesting, and probably possible without modifying anything. What if you just put complete garbage into a compiled ACS file? I'm pretty sure there's no safeguards since at first it was only intended to be used with the in-house ACC and only by the team.

Though, less than 1KB is given to ACS in Vanilla Hexen so not sure how feasible that is either.

 

But, we have to remember: This would only work in DOS or DOSBox, both of which are rarely used for Doom-ing nowadays. Shame it's impossible to do something like this in Chocolate Doom.

 

Also, correct me if i'm wrong but, do the textures ever go through the VGA card? I thought it was all stored in RAM and stuff is rendered by the CPU and then the whole screen is sent to the card.

[Graf Zahl]

1 hour ago, -TDRR- said:

But, we have to remember: This would only work in DOS or DOSBox, both of which are rarely used for Doom-ing nowadays. Shame it's impossible to do something like this in Chocolate Doom.

 

 

This is something some of the vanilla enthusiasts often tend to forget. While it may be cool to find new ways to hack the original EXEs to do unexpected things, one should never forget that it's a very, very small niche group still using these for anything.

 

 

1 hour ago, -TDRR- said:

 

Also, correct me if i'm wrong but, do the textures ever go through the VGA card? I thought it was all stored in RAM and stuff is rendered by the CPU and then the whole screen is sent to the card.

 

It depends on how you look at it. Doom.exe renders directly to video memory, but the texture in its raw form will remain in the regular RAM.

 

[Jon]

2 hours ago, -TDRR- said:

**warning: unexpert talk follows**

…

I'm no programmer

 

I saw these and thought "uh oh" but your message was actually interesting.

 

2 hours ago, -TDRR- said:

, but i think it would be much easier to set up some way to make the .exe just blindly accept whatever the DMXGUS lump says, and if possible force it to load every time.

 

The 0-byte limitation @xttl mentioned is pretty significant, if we can't figure out a way around that then it's a show-stopper.

 

2 hours ago, -TDRR- said:

But Hexen could be interesting, and probably possible without modifying anything. What if you just put complete garbage into a compiled ACS file? I'm pretty sure there's no safeguards since at first it was only intended to be used with the in-house ACC and only by the team.

 

You can definitely crash hexen with bad ACS, it's easy to do evne if you aren't trying to. Whether that can be turned into something useful is perhaps worthy of investigation, yep.

 

2 hours ago, -TDRR- said:

Though, less than 1KB is given to ACS in Vanilla Hexen so not sure how feasible that is either.

 

That's almost certainly enough. One just needs to bootstrap enough code so you can load in another lump and read more code from there. 1KB is a lot of machine code for that.

 

2 hours ago, -TDRR- said:

 

But, we have to remember: This would only work in DOS or DOSBox, both of which are rarely used for Doom-ing nowadays. Shame it's impossible to do something like this in Chocolate Doom.

But we have the source code for the ports. We can do *anything* in the ports, by  changing the source code. We don't need to artificially restrict ourselves to hacks and exploits. The only circumstance where that's interesting, IMHO, is where it's necessary, and that's  pushing the boundaries of the original binaries.

 

 

42 minutes ago, Graf Zahl said:

 

 

This is something some of the vanilla enthusiasts often tend to forget. While it may be cool to find new ways to hack the original EXEs to do unexpected things, one should never forget that it's a very, very small niche group still using these for anything.

 

Why do you think they forget it? I think you're mistaking people's enthusiasm for classic engine hacks as over-projecting how popular it is. Sure it's niche. Who cares? Through a thick enough lens, *all* classic doom stuff is niche, including gzdoom. There's nothing to be gained by looking down at a sub-niche.

[-TDRR-]

8 hours ago, Graf Zahl said:

It depends on how you look at it. Doom.exe renders directly to video memory, but the texture in its raw form will remain in the regular RAM.

I know that, but that's pretty much useless in the way xttl said it could be used.

 

7 hours ago, Jon said:

The 0-byte limitation @xttl mentioned is pretty significant, if we can't figure out a way around that then it's a show-stopper.

Yeah, i wonder how could it be worked around editing the .exe itself?
 

8 hours ago, Jon said:

You can definitely crash hexen with bad ACS, it's easy to do evne if you aren't trying to. Whether that can be turned into something useful is perhaps worthy of investigation, yep.

If this ever happens, we could maybe get ZDoom ACS power in Vanilla Hexen, which would be extremely cool.

 

8 hours ago, Jon said:

That's almost certainly enough. One just needs to bootstrap enough code so you can load in another lump and read more code from there. 1KB is a lot of machine code for that.

This means that we can basically run entirely different programs using Vanilla Hexen as a startup method? Would be funny to run Doom on it, if nothing else.

 

8 hours ago, Jon said:

But we have the source code for the ports. We can do *anything* in the ports, by  changing the source code. We don't need to artificially restrict ourselves to hacks and exploits. The only circumstance where that's interesting, IMHO, is where it's necessary, and that's  pushing the boundaries of the original binaries.

I guess. But my issue is that implementing this in a playable manner for both Vanilla and Chocolate is going to be pretty tough, since you would have to recompile Chocolate and put that along your .wad distribution, all of this while making sure it's at least somewhat close behavior between the two. So it's rather impractical.
 

8 hours ago, Jon said:

I saw these and thought "uh oh" but your message was actually interesting.

Yeah, i'm unexpert on all this stuff but i like reading up on hacking console games via exploits, just find it pretty cool. Maybe that's why not everything i said was completely nonsensical stuff.

[Wraith777]

Don't know how late it is, but.. oh well...

So... basically, it's relatively easy to make a Voodoo Doll Conveyor loop (so that it could be used multiple times). But,this involves some DEH modifications.

 

Instead of barrel and crusher there is.. INFINITE EXPLOSION

It's a thing that has looped spawn states with explosion.

When you open the barrier the INFEX hits voodoo doll, which teleports back after the door is closed.

 

Also,you need a Health Potion generator (triggered by Voodoo doll and another INFEX). And it's the modified Monster Spawner and Spawn Cube.

 

Monster spawner is idle, non clipping and is damaged only by explosion (-1 width). It has pain state that shoots cube every time.

The Cube is modified to behave like a normal projectile. When it hits the wall it's turned into a Health Potion, because it has a sprite change in it's death state.

 

So, after  it lands on start spot it can be picked up as Health Potion by voodoo doll because PICKUPS ARE RELATED TO SPRITE NAMES ONLY*.

 

In the end you get a completely functional Reusable Voodoo Conveyor.

 

Needs timing tweaks, of course, but the concept works in Vanilla (dosbox used for testing) with no crushes/glitches so far.

 

///

*this means you can actually create random pickups by looping frames with sprites of different pickup items (already made it for Terra Nova, but haven't released yet.. no maps done...)

 

Voodoo loop.zip