What are the Unknown Things in DSZ3?
- Thread starter Fawfulfan
- Start date
- Status
kyllian1212
inactive
Its the laser,or something that make eggman move i think.
If working on the principle that a mobj number and the number 4096 units above it are the same, it's actually the Boss Waypoint with various multiples of 4096 added to it. Either it's just different for no reason, or those multiples of 4096 affect it in some way. (Which is entirely possible, I remember Inu mentioning something about creating a mobj variable with it or something.)
But what about Thing Type 32000 (3D Mode Start) and 32001 (Control Sector Position Hint)?
You could do your math and find out how they are actually Thing 3328 and Thing 3329. I dunno if DB or SRB2 recognize this (probably not), but technically, they should be the same.
EDIT: They don't, but DB doesn't know the modulo 4096 rule anyway and SRB2 is harcoded to ignore Thing Type 32000 and 32001 specifically, so the rule doesn't apply there either.
EDIT: They don't, but DB doesn't know the modulo 4096 rule anyway and SRB2 is harcoded to ignore Thing Type 32000 and 32001 specifically, so the rule doesn't apply there either.
Last edited:
I wish SRB2 DB was able to tell the difference between the upper 4 bits and what the actual thing is. It would be neat to have a separate box for that so that a person that doesn't know how to use bit shift math could use the features it provides. Too bad I haven't heard from oogaland for a while so I could bug him to do that.
SRB2DB needs a lot of updating overall. You can work with it as it is, but that's the same as saying you could work with WadAuthor's bitsets to control z-offsetting. I wish Oogaland had the time to spare to work on it some more, but I'll always be grateful for the effort he put into what we have now.
How exactly does this work? I can see the Fan Particle Generators in ERZ2 use this technique. Each of them has one extra set of 4096 added to it? Does that make them spawn at different offsets, and if so, how?
Last edited:
The way I've heard it, each addition of 4096 to the Thing type adds an extra z-offset equivalent to the maximum height value of that Thing. For example, if the maximum height of the Thing is 2048 fracunits, its z-offset is 512, and 4096 is added to the Thing type, that should set the height at 2560.
If you ask me, I think it's time to create an entirely new SRB2DB, built off the code for Doom Builder 2. This would be an arduous venture, but it would be well worth it, as DB2 has some awesome features unheard of in our editor, such as displaying sector floor flats in the standard editing modes. If we could only throw in support for SRB2DB-exclusive features and, yes, the ability to recognize bitset stacking, we would have the ultimate SRB2 level creator.
If you ask me, I think it's time to create an entirely new SRB2DB, built off the code for Doom Builder 2. This would be an arduous venture, but it would be well worth it, as DB2 has some awesome features unheard of in our editor, such as displaying sector floor flats in the standard editing modes. If we could only throw in support for SRB2DB-exclusive features and, yes, the ability to recognize bitset stacking, we would have the ultimate SRB2 level creator.
Cinefast
32 kilowords of core!
I already have made that, Cineblast Doom Builder. It's a stopgap before I write a combined lump/map editor.
When it's polished enough, I will release it. It currently lacks z-height setting for Things.
I'm referring exclusively to Things which stack with bitsets.
And this whole thread is referring to a totally different data field.
- Status