EDGE 2.1.0 Discussion [RC-1 Released on 10.3.2018]

[VGA]

In Doom the way id did, e3m4, it seems I can activate those pillars directly (at least the left one), without using the yellow key on the yellow door etc. In gzdoom it works fine, the pillar don't get activated, you have to get the yellow key, open the yellow door and activate that switch. In 3DGE I activated them, played mroe of the map, got the yellow key, opened the yellow door and the switch was already activated by itself!

Screenshot, although in that one I have opened the yellow door, too:

---

[Coraline]

That's really strange, I really have no explanation for it. In the level editor, it's tagged appropriately, and in LINES.ddf it is also functioning normally. It's probably something deeper but it looks like it existed in very early versions of EDGE.

Maybe if someone can mock-up another "level" with the same properties to test I can get a better idea of what's going on.

[VGA]

The back side of those obstacles have linedefs with the lower floor action. If that gets removed then the problem goes away.
So I think the problem is that activating the obstacle from the front activates the special of the back linedefs of that sector.

I made a little e1m1 replacement map. In GzDoom and Chocolate Doom it works as it should.

Also, why doesn't the lowering sound line up 100% correctly like it does in GzDoom and Choco?

EDIT: It only happens if the distance is small. If I make the sector longer then there is no problem.

[chronoteeth]

as a modder for edge, im excited to finally see this badboy at 60fps. It'll make for some nice new modding techniques too

[Coraline]

@VGA: I'm still not sure why this is happening. I haven't had much time to bug-hunt the source lately (mostly adding more stuff to it) so maybe, Graf or ilk can help me understand what's going on there.

@Chronoteeth: it's been awhile! Glad to see you are still interested in EDGE. 60FPS should definitely change the entire game as far as this source port is concerned.

Once the tier happens (finishing up MD5+tag+LOD right now, -> the Dreamcast port) then uncapping it is a close next. We've already unbuckled the engine down exactly to what we need to increase so once we get there it won't take much longer. Since it's also involving rewriting the entire model system (save for the existing MD2 support for low-poly) and most of the render system, we'll probably skip the version number directly to 1.4, not sure how we're going to handle it yet. Since these changes are so massive in comparison to the 1.36 branch, they might warrant their own version numbers, or even like I had mentioned, completely removing it from the EDGE 1.3x numbering arch. I think I will still put out a 1.37 just for the sake of having a completely bug-free 1.36.

1.31+ had a great run, I think. Skipping up is cosmetic, sure, but it will represent the biggest leap this engine has had since 1.31 (read: YEARS), and I kind of want to disassociate it with the old stuff. Which means anything designed to run on 1.31-1.37 and earlier will absolutely NOT work. Getting a new scripting language, render uncap, high-poly support, shader support, decal support, and inventory support is giant and worrying about older mods that haven't seen the light-of-day in over a decade isn't our top priority.

[chronoteeth]

Any new DDF features in general to add to the future versions? Like priorities first, but what about stuff like (in the case of me as a weapon modder), stuff like lets say charging states or proper empty states and better zoom states, or other things like actual homing weaponry that doesnt rely on the in-game autoaiming to be turned on? miniscule stuff thats optional for modders to add more fluidity to our weaponry

[VGA]

@corynne
It just seems like such a major bug

In the meantime I found something else when I finished episode 2 of 2002:A Doom Odyssey 10th year anniversary edition. There is a problem in the ending intermission after finishing e2m8.
http://www.doomworld.com/idgames/?file= ... 02ad10.zip

Here it is in ZDoom:

---

Here it is in Eternity, ignore the opened console, heh:

---

And here it is in 3DGE 1.36E:

---

Not only is the background different, which I think is wrong, but the intermission text stops at that point as in the screenshot (UNKNO), the rest of the intermission text is not shown!

[Coraline]

This is very strange. It appears it might be a result of the Dehacked->DDF converter that the engine employs, behind the scenes. Says that it's based on PrBoom's DEH/BEX code, which is very interesting.

Basically, for text strings in DEH format, they get converted to LDF (language file EDGE uses, which is DDF-based) in WriteTextString. Something is happening during that conversion that cuts off the text or doesn't dump it properly. I'll try to figure it out.

I'm disappointed, slightly, that these bugs weren't noticed when the original authors were developing EDGE.

EDIT
I grabbed this from the DEBUG file (remember to PLEASE post your Debug or EDGE2.log file when making bug reports):

......
FindCacheFilename: local_name = 'J:\hyperedge\136WORKING\2002ad10.gwa'
FindCacheFilename: cache_name = '.\cache\2002ad10-28D631-AE473E.gwa'
FindCacheFilename: has_local=NO has_cache=YES
Actual_GWA_filename: .\cache\2002ad10-28D631-AE473E.gwa
Adding .\cache\2002ad10-28D631-AE473E.gwa
md5hash = 1df23405...ca18e6e9
Actual_HWA_filename: .\cache\DEH_0003.hwa
Converting [DEHACKED] lump in: J:\hyperedge\136WORKING\2002ad10.wad
../deh_edge: *** DeHackEd -> EDGE Conversion Tool V1.3 ***
../deh_edge: Loading patch file: DEHACKED.LMP
../deh_edge: Detected text-based patch file from DEHACKED v3.0
../deh_edge: Patch format 6, for DOOM EXE 2.1
../deh_edge: - Warning: Truncating very long line (#55).
../deh_edge: - Warning: Truncating very long line (#56).
../deh_edge: - Warning: Truncating very long line (#57).
../deh_edge: - Warning: Line 60: unknown BEX string name: BGFLATE2
../deh_edge: - Warning: Line 61: unknown BEX string name: BGFLATE3
../deh_edge: - Warning: Line 62: unknown BEX string name: BGFLATE4
../deh_edge:
../deh_edge: Converting data into EDGE 1.36 DDF...
../deh_edge:
../deh_edge: Writing WAD file: .\cache\DEH_0003.hwa
../deh_edge:......

It appears that EDGE is cutting off lines that are deemed "too long", which I'm assuming is what's happening at the intermission text. So, I'll see what I can do about that. That is part of the engine I haven't touched (the converter) so bare with me. ^_^ Also appears to not support other string names in BEX format, which is known (EDGE has never been 100% on that).

EDIT 2
Found it directly from the source.

---

char line_buf[MAX_LINE+4];
int line_num;

char *equal_pos;

int active_section = -1;
int active_obj = -1;

const char *cur_txt_ptr;
bool syncing;

void GetNextLine(void)
{
int len = 0;
equal_pos = NULL;

for (;;)
{
int ch = pat_buf->getch();

if (ch == EOF)
{
if (pat_buf->error())
PrintWarn("Read error on input file.\n");

break;
}

if (ch == '\n')
break;

if (ch == '\r')
{
ch = pat_buf->getch();

if (ch != EOF && ch != '\n')
pat_buf->ungetch(ch);

break;
}

if (len >= MAX_LINE) // truncation mode
continue;

if (! equal_pos && (char)ch == '=')
equal_pos = line_buf + len;

line_buf[len++] = (char)ch;

if (len == MAX_LINE)
PrintWarn("Truncating very long line (#%d).\n", line_num);
}

line_buf[len] = 0;
line_num++;
}

[VGA]

I hope you can fix that. Also, another problem

The map markers aren't being saved in the savegame. Just now I was playing a big map, after dying and loading a save I lost my markers and couldn't find a switch that needed the final key.

[Coraline]

Could be an issue with savegame compression. I know it was recently, before I took over, developed and maybe map markers were an oversight. I'll look into it, but I won't count that one as a game-breaking bug - I honestly didn't know anyone EVER used automap markers anyway

[Coraline]

Okay, double post. The Dehacked bug is now fixed, so now it will never run out of room to display lines. I'm working on fixing the Automap marker bug too by creating a new struct in the savegame system. Once those are done I will release another 1.36 version (I think we're at F now).

The bug with DTWID is too complex to fix, how often do level authors use that?

[zZaRDoZz]

so, am i to understand that 3dge 1.37 will still be compatible with dons challenge and qdoom? 1.4 will break compatibility yes? I'd love to play qdoom without slime errors.

[Coraline]

Yes, 1.37 will be the last version of 3DGE able to withstand backwards compatibility. After that everything breaks, unless the code is updated by hand to be compatible with 1.4.

[VGA]

Okay, double post. The Dehacked bug is now fixed, so now it will never run out of room to display lines. I'm working on fixing the Automap marker bug too by creating a new struct in the savegame system. Once those are done I will release another 1.36 version (I think we're at F now).

The bug with DTWID is too complex to fix, how often do level authors use that?

Did you check out my test map? It's just a (small enough) sector with activatable front and back sides and it is susceptible to this bug.

But I'm looking forward to 1.36F regardless. Why do you change the executable name with each revision, though? It messes with shortcuts, zdl etc. Maybe too late to change now, but please don't start with 1.37A

[zZaRDoZz]

I can't talk you into more than 4 action keys? Some new spells/magic items for heretic would be awesome.