Hacx 1.2

[andrewj]

Heh:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     This is the ALPHA version of HacX, do NOT distribute!! 
          Contact Banjo Software at : 1-504-737-7037 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Graf Zahl]

Quasar said:

EE doesn't support UDMF yet, and I'd say at this point it's a while away. I really want to integrate Aeon first so it'll be there to support the use of custom UDMF fields in scripting.

Honestly, I don't think you are doing anyone a favor by that.

I guess that UDMF is much, much more important to the users of your port than scripting which probably won't even be used by the majority of mods.

The biggest obstacle to UDMF in EE has nothing to do with UDMF itself, ironically. It's the huge mess that consists of our linedef special system. I just dread the thought of even trying to iron out all those diverse tangled up special types into one coherent system.

Well, you can't put it off forever. This reminds me a bit of ZDoom's menu code. That also was a hideous mess that had grown cancerously into an unmaintainable monster. But in the end, when I really started focussing on it it took me only a bit more than 2 weeks to get right - and that included rewriting 95% of the entire related code.

So I can only advise not to put this on hold for other less important features. The sooner this gets sorted out the better - and I think this should be sorted out before you start on scripting. Otherwise it may get in the way seriously if you are not careful.

I think Eternity will profit a lot, lot more from UDMF and proper Hexen line special support than from a scripting language.

[Vermil]

A bit presumptions claiming that Doomscript and/or UDMF will become the defacto language/format isn't it?

Though I can't blame one for trying to push the language and/or format they have chosen to support.

[Graf Zahl]

Vermil said:

A bit presumptions claiming that Doomscript and/or UDMF will become the defacto language/format isn't it?

Way to fail!

1. I was never talking about Doomscript. It's currently in development limbo anyway.
2. UDMF is not a language. It's a map format that, btw, wad initiated by Quasar, quite ironic considering that Eternity doesn't support it yet... And yes, it will become the mapping format of the future for advanced mods, that's inevitable.

I just question the priorities. What's important to mappers?
If you think about it, the better map formats are far more in demand than a working scripting system, especially if you factor in the time needed to develop these components.

Scripting is a major undertaking that may take many, many months to get to a usable state.

On the other hand, the messed up linedef system can certainly be cleaned up in a few weeks - and once that's done UDMF becomes a trivial addition.

So again, is it worth waiting for these features all those months that implementing a working scripting system would take?
I guess that any modder who isn't set out to do a full TC would agree that the map formats are far more important, especially as far as cross-port-compatible mods are concerned. And with the current feature sets of Eternity and ZDoom these become ever more feasible and this is precisely what Eternity needs to gain more popularity.

[Vermil]

You don't directly state it. But you do quite often "elude" to some feature that ZDoom happens to have that port X doesn't and that port X will be more popular if it both adds said feature and adds it in a way that is compatible with ZDoom's implementation.

But certainly, I would expect a port author to promote their port's features and implementation of said features.

[Graf Zahl]

Vermil said:

You don't directly state it. But you do quite often "elude" to some feature that ZDoom happens to have that port X doesn't and that port X will be more popular if it both adds said feature and adds it in a way that is compatible with ZDoom's implementation.

Adding a feature in a way that's deliberately incompatible with an existing implementation is never a good idea, unless there's some extremely important reasons for that incompatibility. This goes in particular for basic mapping features.

And if you got a feature in common with another port that'd be compatible except for the mapping interface it's also always a good idea to implement that other interface if it's doable.

With an implementation that's 'either or' you force mappers to choose between ports early on but if they use a common way to expose a feature there's a far higher chance that a feature actually gets used.

Why does it always have to be 'Port A vs. Port B' for people like you? Competition might occasionally yield good results but cooperation nearly always produces better ones.

UDMF, for example, happened, because Quasar, CodeImp and I were discussing this quite extensively until we arrived at the current spec. Which makes it all the more disappointing that Eternity still doesn't support it after more than 2 years since finalizing the spec.

[Quasar]

You're probably right. Maybe I can sneak it in before I start earnest work on Aeon :P I already know that'll take a while once I start on it, although thanks to the fact we're using a stable well-tested virtual machine platform, I hope that most of the work will be designing the interface to the engine, and not just trying to make the VM work.

[DaniJ]

The situation with Doomsday, scripting and UDMF is a little different. Skyjake has already completed work on the new scripting system (i.e., its in and being used for various things in another branch). We are currently in the process of merging several branches which will give us new; plugin loading, scripting, integrated presentation system (all intros, cutscenes, HUDs and menus).

UDMF is less important to us than the above features so it can wait imo.

[Gez]

Silly question: is it "Hacx" or "HacX"? Nostromo's website only uses Hacx or all-caps; but in other places (e.g. the Doom wiki) the graphy HacX is used.

[Quasar]

Gez said:

Silly question: is it "Hacx" or "HacX"? Nostromo's website only uses Hacx or all-caps; but in other places (e.g. the Doom wiki) the graphy HacX is used.

They said I should use HACX in EE :P

[Xaser]

I The "proper" form either is all-caps, like DOOM, or just regular "Hacx" -- I'm really not sure where "HacX" comes from or why I use it, but I never really make much sense anyway.

[myk]

I wouldn't use all-caps for anything other than DOOM around here unless it's made up of initials. Heh, I wonder who introduced the upper X crap... evidently derived from DooM (ew) but I can imagine it getting passed along more easily because it makes the X taller, as if it were a k.

[Xaser]

X for emphasis? *shrugs*

Anyhow, Hacx 1.2 is up on /idgames now. Update your links. ;)

Note: I might do one final revision (turns out there are some glitches with the EMAPINFO), but after that I promise I'll stop bastardizing the version number system.

[Graf Zahl]

I just found 2 small problems:

- The breaking glass counts as a kill
- The mine, when self-exploding does not give a kill credit. In the DECORATE code the Melee, Missile and Pain states should call A_Die instead of falling through to the Death state.

Oh, and BTW, MAP05 looks quite bad in GZDoom. Unfortunately that's not fixable without changing the map itself... :(

[Blzut3]

Graf Zahl said:

Oh, and BTW, MAP05 looks quite bad in GZDoom. Unfortunately that's not fixable without changing the map itself... :(

MAP05 looks bad on any version of Doom. :P That's on the list of maps to redo/improve (more specific details are available on Nostromo's forum).

[fraggle]

Hi,

A bit late to the game here, but for what it's worth I added some code to Chocolate Doom trunk to support using this as an IWAD. All this essentially does is load the DEHACKED lump on startup (Chocolate Doom doesn't normally support DEHACKED lumps).

It has been reported that the invulnerability COLORMAP is the Doom one, not the one from the older Hacx release. Any reason this was changed?

[Xaser]

Ah, this is good to hear! Thanks there. :)

fraggle said:

It has been reported that the invulnerability COLORMAP is the Doom one, not the one from the older Hacx release. Any reason this was changed?

Hmm, must've missed a spot when copying over the game palette from Freedoom. For some reason it didn't dawn on me that the original already had a modified COLORMAP.

[Devalaous]

Oh cool, now I have a LEGITIMATE excuse to play the original while waiting for the remake :D

[Xaser]

Sudden bump-from-the-deep!

Vermil PM'd me earlier regarding a bug in the DECORATE code that causes a port inconsistency with ZDoom, namely that Stealth Buzzers are meant to spawn from the ceiling (as referenced in the DEHACKED) but are missing the relevant flag in DECORATE.

Long story short: a 1.3 release isn't out of the question at this point. If it's going to happen, though, it'd be great to comb through it and see if there are any other inconsistencies and bugs that are worth a fix. Seems almost like a trivial thing to release a "post-final" wad for a 'small' fix like that, but given the version bump, it's also be a good time to do EDFs (and maybe DEDs, depending on how DaniJ wants to do it / has done it) and fix that colormap issue. Guess it's not for naught. ;)

[Vermil]

Another little thing; A DB 3d start is on Map06 at -811 1320.