Doomworld Forums - Attempting to make a new projectile with BrainSpit

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom Editing > Attempting to make a new projectile with BrainSpit

Author

All times are GMT. The time now is 17:27.

Mechadon
Senior Member

Posts: 1787
Registered: 12-06

I was wondering if it would be possible to make a new monster projectile by using the BrainSpit codepointer (the project in question won't be making use of any of the Icon of Sin things). I knew the demon cube was a projectile. But the need for a spawn spot thing in order for the projectile to work complicates matters just a bit.

So far I've tried swapping out the player's states/flag/etc with the Demon Spawn Spot thing to see if that would attract the projectiles towards the player. This didn't work, however, as many of the essential player properties (hardcoded ones I think) were lost. So then I attempted to create duplicate "player" objects by giving the Demon Spawn Spot the same flags, states, and properties as the player. This didn't work either as the projectile would never actually fire (I'm surprised the game didn't crash to be honest).

I wasn't sure if there were any other methods or hacks to get this to work. So if there's anyone out there who's really handy with dehacked, I could really use your help :)

I'm doing this in the bex format by the way. Here's my test map:

http://mekworx.phenomer.net/mekastu...ossspittest.wad

Currently the map and dehacked is setup where the Baron will attack with a modified baron projectile using the BrainSpit codepointer. The projectile will only fire towards the candle which is where the demon spawn spot thing is located. The projectile can hit the player and do damage but it will never fire in any other direction other than towards the demon spawn spot.

I would be very grateful with any help anyone can provide!

01-26-12 06:41 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1379
Registered: 04-02

The Demon Spawn spot things, type 87 and nothing else, are remembered when the boss brain awakes (by the A_BrainAwake code pointer) and they are the only places where the cube will go towards.

Maybe you could get those things to move around (A_Chase), but I'm fairly sure there is no way to do what you're trying to do with them.

01-26-12 08:40 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7036
Registered: 07-07

Ah, if only there were some source ports around where you could create new actors instead of having to coerce dehacked into doing the impossible...

01-26-12 11:09 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6840
Registered: 06-06

WHAT BrainSpit does:

code:
void A_BrainSpit (mobj_t*	mo)
{
    mobj_t*	targ;
    mobj_t*	newmobj;
    
    static int	easy = 0;
	
    easy ^= 1;
    if (gameskill <= sk_easy && (!easy))
	return;
		
    // shoot a cube at current target
    targ = braintargets[braintargeton];
    braintargeton = (braintargeton+1)%numbraintargets;

    // spawn brain missile
    newmobj = P_SpawnMissile (mo, targ, MT_SPAWNSHOT);
    newmobj->target = targ;
    newmobj->reactiontime =
	((targ->y - mo->y)/newmobj->momy) / newmobj->state->tics;

    S_StartSound(NULL, sfx_bospit);
}

1. It happens half as often in skills 1&2 (easy) than higher. At each second attempt, it will not execute.

2. It looks for boss spawn targets, MT_BOSSTARGET. They must exist in the map and be checked in first by BrainAwake (probably called from its spawn frame -- I'm not sure what happens if called several times, just experiment with a monster that wakes up, sleeps, wakes up and see if it's safe), otherwise it looks like it will crash!

3. It spawns a proper missile of type MT_SPAWNSHOT, headed towards a random boss spawn target.

4. Its "target" will be designated as that spawn spot. Note that conventional projectiles have their shooter as a target! This means that in this case blame will NOT be set on the shooter when damage is inflicted, because projectile's "target" isn't the shooter! On the other hand, you'll be able to make the projectile fire secondary missiles toward its destination! UNFORTUNATELY, I believe it will also make the projectile explode from inside shootable monster's body unless that monster is short enough...

5. How are you going to set the spawn-spot to be the player? Maybe you can turn the MT_SPAWNSHOT Dehacked slot into a no-clipping unshootable monster that clings on the player. Give it undamaging melee states to make sure it stays stuck to the player!

Last edited by printz on 01-26-12 at 12:14

01-26-12 11:57 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1379
Registered: 04-02

printz said:
Maybe you can turn the MT_SPAWNSHOT Dehacked slot into a no-clipping unshootable monster that clings on the player. Give it undamaging melee states to make sure it stays stuck to the player!

Woah, that could actually work.

Speed will need to be high enough to catch up with a fast moving player, but too high will make the spawn spot bounce big distances around the player and hence seem like the projectiles are really inaccurate.

You'd want to avoid teleporters in the map, as there'd be a period after teleporting where the spawn spot would catch up to the player.

Co-op ain't going to work.

01-26-12 12:49 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4613
Registered: 08-00

Mechadon said:
I was wondering if it would be possible to make a new monster projectile by using the BrainSpit codepointer (the project in question won't be making use of any of the Icon of Sin things). I knew the demon cube was a projectile. But the need for a spawn spot thing in order for the projectile to work complicates matters just a bit.

So far I've tried swapping out the player's states/flag/etc with the Demon Spawn Spot thing to see if that would attract the projectiles towards the player. This didn't work, however, as many of the essential player properties (hardcoded ones I think) were lost. So then I attempted to create duplicate "player" objects by giving the Demon Spawn Spot the same flags, states, and properties as the player. This didn't work either as the projectile would never actually fire (I'm surprised the game didn't crash to be honest).

I wasn't sure if there were any other methods or hacks to get this to work. So if there's anyone out there who's really handy with dehacked, I could really use your help :)

I'm doing this in the bex format by the way. Here's my test map:

http://mekworx.phenomer.net/mekastu...ossspittest.wad

Currently the map and dehacked is setup where the Baron will attack with a modified baron projectile using the BrainSpit codepointer. The projectile will only fire towards the candle which is where the demon spawn spot thing is located. The projectile can hit the player and do damage but it will never fire in any other direction other than towards the demon spawn spot.

I would be very grateful with any help anyone can provide!

Players are players because they are attached to another structure in memory called player_t. Normal mobj_t's do not have a player_t and no amount of wishing or DeHackEry will make that happen. Only objects that spawn with doomednums 1 - 4 are capable of thinking they are players, and of those, only ones that are also pointed back to by a player->mo pointer (which will always be the LAST such thing spawned at one of those points for a given player) will actually be chased by monsters. This is why voodoo dolls are not attacked on sight - they are not referenced *from* the player_t structure for player 1.

Please also be aware that monster and projectile logic are incompatible. If you try to create a missile without the MF_NOBLOCKMAP flag, that missile will corrupt every blockmap cell's thing list that it is attached to, and if that thing is later freed, the game may crash if anything else moves into or out of that blockmap cell, or that blockmap cell is part of a moving sector, or is subject to an explosion.

01-26-12 13:17 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Xaser
Senior Member

Posts: 1628
Registered: 07-03

andrewj said:
Speed will need to be high enough to catch up with a fast moving player, but too high will make the spawn spot bounce big distances around the player and hence seem like the projectiles are really inaccurate.

If A_Chase is called every tic, I do believe it'd be possible to make the spots keep up with a running player without awkward bouncing.

andrewj said:
Co-op ain't going to work.

Sure it would -- the cube shooters would all just focus on one player. :P

Wonder if you could get away with placing four of these moving spots on the map so that each of them could potentially chase after a different player. Either way, I'm gonna whip up an example wad later (tonight or tomorrow, depending on time) because this idea is bloody fascinating. If someone could make walking frames for Fredrik/Vegeta's Baphomet sprites, we may just have ourselves a worthy final boss for Doom 2. ;)

01-26-12 18:58 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Vermil
Senior Member

Posts: 1223
Registered: 03-04

I tried to turn the boss cubes into shootable missiles once and ran into issues with removing the NOCLIP flag; it caused Doomsday to crash, suggesting some obscure bit of code may be hardwired to expect said flag :(

Might be worth testing that doesn't also occur in Vanilla before going too far, as the NOCLIP flag prevents the mobj from hitting anything...

Last edited by Vermil on 01-26-12 at 19:59

01-26-12 19:49 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Mechadon
Senior Member

Posts: 1787
Registered: 12-06

Thanks for all the input so far guys!

printz said:
5. How are you going to set the spawn-spot to be the player? Maybe you can turn the MT_SPAWNSHOT Dehacked slot into a no-clipping unshootable monster that clings on the player. Give it undamaging melee states to make sure it stays stuck to the player!

Whoa, that is an interesting idea! If we can get this working then hey, you certainly get the credit for it. I would never have thought to try that.

I don't mean to jump the gun on Xaser here, but I went ahead and did a quick experiment using printz's method.

http://mekworx.phenomer.net/mekastu...sspittest_2.wad

The red column is basically the unshootable, no-clipping monster which takes the slot of the spawn spot thing. Currently it's visible and untouchable just so I could see how it moves around. It calls a NULL melee state every 1 tic so it will stick to the player.

So...it sorta works. The spawn spot "column" does move around and "stick" to the player and the new projectile (using the BossSpit codepointer) will fire towards the moving spot. But as andrewj predicted, there's a whole fuckton of bouncing around going on as the spawn spot tries to track the player. When it does manage to stick to the player, it won't always align itself well enough. So the projectile doesn't have the greatest accuracy. And that's if you stand still :P.

If there's a way to make the spawn spot stick to the player in a much tighter fashion then this might actually work in a half decent manner. What I setup is really just a quick experiment. I didn't play around with the numbers too much so there's definitely room for improvement. Perhaps you can get it to work better Xaser? This sort of logic and behavior creation is far from my forte, heh.

For my uses though, the new projectile I have in mind is something that's going to be used for a boss. So it will probably be fairly large and fast moving. If the tracking objects can be tightened up, it might work pretty well. This is also good as it won't be used very often (maybe one or two maps max) so I can control other factors that might break the behavior. Concerning COOP, if there is any way to get that to work then that would be a plus. The project in question is going to be first and foremost singleplayer though.

printz said:
UNFORTUNATELY, I believe it will also make the projectile explode from inside shootable monster's body unless that monster is short enough...

I decided to give the test wad a run in ZDoom and this is exactly what happens. The projectile kept exploding inside of the Baron before it would fire towards the spawn spot. In PrBoom+ and Eternity though, this doesn't happen.

Quasar said:
Please also be aware that monster and projectile logic are incompatible. If you try to create a missile without the MF_NOBLOCKMAP flag, that missile will corrupt every blockmap cell's thing list that it is attached to, and if that thing is later freed, the game may crash if anything else moves into or out of that blockmap cell, or that blockmap cell is part of a moving sector, or is subject to an explosion.

Yipes, that doesn't sound good at all :(. Is there any way I can control or get around this limitation? (doesn't sound like it though)

Gez said:
Ah, if only there were some source ports around where you could create new actors instead of having to coerce dehacked into doing the impossible...

But Gez, that would be too easy! :P

Actually I choose Boom compatibility for the nice balance of features, simplicity, and portability. There were many times were I thought about using a more advanced sourceport. But I can't even make a map without getting stupidly more complex than needed, so feature creep by using a more advanced port would probably kill me.

Last edited by Mechadon on 01-26-12 at 21:15

01-26-12 21:05 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6840
Registered: 06-06

I tried it in Eternity, and the projectile does explode from within the monster, but not always. I also lowered the target speed to something sensible like 20, which made it less erratic while still keeping up with the player. I think 25 is a bit safer, to outrun strafe-running.

If basic MBF compatibility is allowed: how about making the monster Spawn another monster with a well-defined reaction time? THAT monster will fire the custom projectile a set time after seeing the player and probably disappear, and may do so from a position displaced from its spawner. Only problem is that the secondary monster is spawned facing East, and will only automatically activate if spawned within an alerted room (you can make sure the rooms are alerted by placing bait zombies or imps and general monsters before this particular boss is revealed). This wasn't tested.

mechadon wrote:

Yipes, that doesn't sound good at all :(. Is there any way I can control or get around this limitation? (doesn't sound like it though)

Yeah but I doubt you'll need to ever have projectiles without NOBLOCKMAP. I think that in Boom or MBF compatible (hopefully just Boom) you can fire NON-projectiles that also lack NOBLOCKMAP but Quasar might now better. As long as they're non-solid against you, they won't blow up inside you.

Last edited by printz on 01-26-12 at 21:25

01-26-12 21:16 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7036
Registered: 07-07

Mechadon said:
But Gez, that would be too easy! :P

Actually I choose Boom compatibility for the nice balance of features, simplicity, and portability. There were many times were I thought about using a more advanced sourceport. But I can't even make a map without getting stupidly more complex than needed, so feature creep by using a more advanced port would probably kill me.

Well, apparently Boom isn't sufficiently restrictive to keep your feature creeping instincts reined in since you want to add a new projectile. :p

01-26-12 21:26 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6840
Registered: 06-06

Mechadon said:

Actually I choose Boom compatibility for the nice balance of features, simplicity, and portability. There were many times were I thought about using a more advanced sourceport. But I can't even make a map without getting stupidly more complex than needed, so feature creep by using a more advanced port would probably kill me.

I tend to get around that by starting a vanilla map and switching to a heavier port when I'm actually affected by the limitations and, more importantly, have much of the map core done.

01-26-12 21:32 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Mechadon
Senior Member

Posts: 1787
Registered: 12-06

printz said:
.If basic MBF compatibility is allowed: how about making the monster Spawn another monster with a well-defined reaction time? THAT monster will fire the custom projectile a set time after seeing the player and probably disappear, and may do so from a position displaced from its spawner. Only problem is that the secondary monster is spawned facing East, and will only automatically activate if spawned within an alerted room (you can make sure the rooms are alerted by placing bait zombies or imps and general monsters before this particular boss is revealed). This wasn't tested.

That sounds like it could possibly work. The base compatibility for the project is MBF too. I assume this would mean that you'd have to replace the Lost Soul and then use the PE's monster spawn codepointer though, right? Unfortunately for me, if that's the case, I won't be able to do that since I have something else planned that will make use of that codepointer :(

This whole idea is pretty neat but I'm not sure it's going to work out for me in the end. I have another idea for the BossSpit codepointer though that will definitely work. Maybe someone else can use the information and ideas in here for their own project :D

Gez said:
Well, apparently Boom isn't sufficiently restrictive to keep your feature creeping instincts reined in since you want to add a new projectile. :p

Well mostly I just recalled that the Demon Cube was a projectile so I was wondering what I could do with it (since it would ultimately be unused otherwise). By this point I've already got a working boss monster using stock projectiles. So really, a new projectile wasn't even needed :P

Thanks for the help everyone!

01-27-12 21:18 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7036
Registered: 07-07

If you go for MBF compatibility, you get new projectiles to play with: red and green plasma. Also a new monster in the form of the dog. Can do plenty of dehacked stuff with all that.

01-27-12 21:51 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6840
Registered: 06-06

Mechadon said:

That sounds like it could possibly work. The base compatibility for the project is MBF too. I assume this would mean that you'd have to replace the Lost Soul and then use the PE's monster spawn codepointer though, right? Unfortunately for me, if that's the case, I won't be able to do that since I have something else planned that will make use of that codepointer :(

Nope, it is a separate Spawn codepointer, which lets you define two arguments (named as Unknown 1 and Unknown 2 in Dehacked) for the thing type to spawn and Z relative coordinates. Here's the Whacked2 MBF config file: http://www.mediafire.com/?l1eaqqp07h921bg. Place it in the same Whacked2 installation subfolder ("config") with boom.cfg and udoom.cfg.

Complete MBF documentation comes with the port, for convenience's sake I'm sending the documentation directly: http://www.mediafire.com/?0mjhrlyaybbx6vw

The extra frames -- over vanilla Doom's -- among which Gez is talking about are:

Added by Boom:
- 967: TNT1 frame -- used by point wind control things. I doubt it's safe to replace.

All frames below are safe to replace. They aren't documented and warning: many of them are not supported by PrBoom+ and I'm not sure if ZDoom recognizes them either! Eternity supports them because it's directly based on SMMU and implicitly MBF. Since they weren't ever mentioned in the MBF docs in the first place, I'd say it's better not to use them unless constrained.

- 968-971: optional grenade frames -- if you want to replace the rockets with timed or touchy grenades, you can give these frames directly to the rocket-missile object.
- 972-998: DOGS frames -- used by MBF dogs. Replace these if you don't need to have dogs. They're almost identical to the Demon frames.
- 999-1041: old BFG gun frames -- Replace these if you don't need to use the old BFG. Beware that it's a user selectable setting and if the user chooses an old BFG the game may crash in this case, fortunately it can be forced off by the WAD author [same applies to dogs btw].
- 1042-1053: beta BFG plasma shots. Same consideration as above
- 1054-1074: FREE TO USE
- 1075: optional mushroom-explosion frame, again for the rocket launcher.

Also, as an addition to that warning, ZDoom doesn't fully support MBF... Simple tricks like using PlaySound, RandomJump and Spawn are okay & fully supported, but it may get hairy if you use FRIEND, friend inheritance and BOUNCES objects all over the place. They act in a rather unique and somewhat hacky way in MBF which is hard to reproduce. MBF's friends are different from ZDoom's, MBF has lots of bounce types in ONE flag, ZDoom has lots of bounce types of many flags and settings, and there are some unresolved bugs too.

I believe PrBoom+ works better at being compatible, though it lacks the spare frames and doesn't support the OPTIONS lump (you won't be able to force gameplay settings). Also some tricks, such as inheriting friendliness (FRIENDly objects always spawning or resurrecting other objects as FRIENDly) will only happen if -complevel is MBF.

01-27-12 22:51 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7036
Registered: 07-07

printz said:
All frames below are safe to replace. They aren't documented and warning: many of them are not supported by PrBoom+ and I'm not sure if ZDoom recognizes them either!

ZDoom supports the full range of MBF states for DeHackEd.

printz said:
Also, as an addition to that warning, ZDoom doesn't fully support MBF... Simple tricks like using PlaySound, RandomJump and Spawn are okay & fully supported, but it may get hairy if you use FRIEND, friend inheritance and BOUNCES objects all over the place.

The main difference as far as friends go is that in ZDoom monsters won't attack friends without provocation. So that baron vs. hell knight hockey rink map in MBF's testing/demonstration package doesn't work. But situations like that are a bit convoluted anyway.

Friendliness inheritance (i.e., friendly lost souls from friendly pain elemental; friendly monsters resurrected by friendly arch-vile) should work perfectly.

Bouncing behavior is emulated as closely as I could manage. There are some differences in corner cases that I haven't been able to solve but it's rather contrived situations (such as point-blank shotting a wall with a bouncy grenade launcher).

01-27-12 23:30 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6840
Registered: 06-06

Gez said:

Friendliness inheritance (i.e., friendly lost souls from friendly pain elemental; friendly monsters resurrected by friendly arch-vile) should work perfectly.

There IS a miss though: if you make a player projectile (such as the BFG shot) a FRIEND, and if you make that projectile spawn a monster, it will spawn a friendly monster in MBF, but a hostile one in ZDoom. In MBF the friendliness is not inherited by missiles (it has to be defined in BEX), could it be that in ZDoom it is? and the player avatar not being tagged as "friendly" causes the modified projectile NOT to be friendly?

01-28-12 09:02 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 17:27.

Doomworld Forums > Classic Doom > Doom Editing > Attempting to make a new projectile with BrainSpit

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >