Altazimuth

Old stuff is all Doom format. EE's UDMF isn't too special, though we don't have a documented spec yet of exactly what is and isn't there. If there's anything that you dunno what ExtraData feature maps to what UDMF property, let me know and I'll be more than happy to help.

This bug has been reported by fraggle, https://bugzilla.libsdl.org/show_bug.cgi?id=3858 which apparently is an amalgam of issues https://bugzilla.libsdl.org/show_bug.cgi?id=3848 and https://bugzilla.libsdl.org/show_bug.cgi?id=3849. I also spotted this when I switched to SDL2.0.6 release for Eternity on the SDL2 branch. It's worth noting that I found this post, which seemingly managed to fix the bug when I applied the code therein (#if guarded so it only executes on Windows): https://discourse.libsdl.org/t/sdl-2-0-6-released/23109/21

There is a resource wad that includes all the Doom 1 textures that Doom 2 doesn't have. https://www.doomworld.com/idgames/graphics/d1gfxd2

If you're looking for free static web hosting, there's Github Pages https://pages.github.com/. It's pretty alright.

Some preliminary work had been done on Mordeth's want here: https://github.com/ioan-chera/UDMF-Converter-EE, though of course independent work on this issue is something I encourage, and would be more than happy if you were to get it working.

DARK MAGIC. BURN THE WITCH.

Well technically if you just want a bunch of perimeter sectors and nothing further, you could reduce it to a single square, then use the stair builder.

The newest DRDTeam build should fix the issue. Let us know if it does, and thanks for flagging this up with us.

EE_FEATURE_MIDIRPC enables the midiproc stuff that post-XP Windows requires to separate MIDI volume from game volume.

Secondary fire is a thing in Eternity's weapons-branch already, both with frame references (props attackstate2, flashstate2, holdstate2) and DECORATE frames (labels AltFire, AltFlash, AltHold). It needs more rigorous testing, but the first battery of tests went well enough that the extreme stress testing will occur later. No reload stuff yet, that'll probably either come later in the branch's life, or happen after the branch is merged in. Whilst I will happily listen to feature requests at this point, I can't promise anything about when I would be able to get to it (if I approve of the request). Feature requests are certainly welcome though, especially fun ones (as they help keep me motivated in between getting the less glamourous & more tedious stuff done).

2017/08/09, 11:40: Hello player->lookdir my old friend. I've come to fucking code around you again you awful awful awful piece of shit. 2017/08/09, 12:25: Kinda got mace fire working, but I can't figure out how to get Eternity's pitch translated to Heretic's lookdir. 2017/08/09, 19:45: Done with the poxy bloody wimpy mace. 2017/08/12, 14:25: Bloody big ballistic balls to barrage baddies are brought to the table (powered Firemace is working). 2017/08/12, 19:30: You can now give multiple ammos for a single weapon pickup (previously it was permitted, but didn't work). 2017/08/16, 00:20: The answer is in trees! Maybe a red-black tree for weapon counters, or an unbalanced binary search tree if I'm feeling lazy; perhaps a regular tree to start off then move it over to a self-balancing tree once I'm sure the system works. Also a skip list might work well for priorities, though I'm not sure if I'd what I'd decide what I want to promote to being higher in the list. 2017/08/16, 11:30: An AVL tree might also work for weapon priority, as it's well-suited to lots of searching but fewer mutations. 2017/08/16, 19:40: Implemented weapon priorities using an AVL tree. Moving and removing nodes after the fact isn't there yet, but at least Heretic doesn't cause the engine to crash when you run out of ammo for any weapon. 2017/08/17, 22:10: I fixed the saving and loading of readyweapon and pendingweapon. I also turned the AVL tree into a templated class, and might make counters use it too. 2017/08/18, 15:50: Weapon deltas now correctly impact selectionorder, as deletion from the AVL tree has been successfully implemented. 2017/08/19, 16:30: Weapon counters now partially work, but saving doesn't work for them. See the below gif below for Vapordemo's random frame jumping with counters in action. 2017/08/21, 13:00: Saving/loading weapon counters is now a thing. 2017/08/24, 14:00: The Heretic spinning tome and wings now correctly display. The speed of post-use artifact flash has been corrected. 2017/08/26, 02:35: You can now execute codepointers from artifacts (Heretic-style items). You define them as such: useaction <A_>SomeCodePointer (1, 2, three, "f o u r", ...) 2017/08/26, 13:35: I fixed a bug where useactions would cache actor and psprite references, and not end up being updated. Additionally, I semi-implemented the effect of the Chaos Device (the Heretic teleporter). 2017/08/26, 15:45: The Timebomb of the Ancients now has its useeffect working. 2017/08/31, 16:20: Added the ACS functions: GiveInventory, TakeInventory, and CheckInventory. 2017/08/31, 20:30: Oh fuck ZDoom has it so if the player is given a weapon given via GiveInventory, you get the ammo too. Fuck fuck fuck fuck fuck fuck fuck. 2017/09/05, 13:15: The pickup system has been overhauled. You can specify a reference to a new shiny pickupeffect from within a thingtype, as well as us sprites. pickupitems are still there but should be considered deprecated once I'm done.

Don't work on it. My shit's broken. Fixing. EDIT: I FIXED THAT SHIT. I feel like such a colossal fucking idiot.

Small quality-of-life change here, I decided to make some properties that let you scroll sectors without any line specials. Nothing is ratified yet, and I'd actually like to hear some input from one of the *ZDoom team, as this would be a nice feature that benefits end-users of both ports. Also, SCROLL_FLOOR AND SCROLL_CEILING VIA ACS WERE BROKEN BEFORE IN ETERNITY, THE SPEED IS NOW FIXED TO BE THE SAME AS ZDOOM'S. Properties so far: scroll_ceil_x: Double: A value of 1.0 is approximately one unit per second, using the same speed that ACS Scroll_Floor/Ceiling use (from ZDoom). scroll_ceil_y: Double: A value of 1.0 is approximately one unit per second, using the same speed that ACS Scroll_Floor/Ceiling use (from ZDoom). scroll_ceil_type: String: Either a value of "none" (default), "visual", "physical", or "both" (visual and physical) scroll_floor_x: Double: A value of 1.0 is approximately one unit per second, using the same speed that ACS Scroll_Floor/Ceiling use (from ZDoom). scroll_floor_y: Double: A value of 1.0 is approximately one unit per second, using the same speed that ACS Scroll_Floor/Ceiling use (from ZDoom). scroll_floor_type: String: Either a value of "none" (default), "visual", "physical", or "both" (visual and physical) The one thing I'm not hugely sure about is the type strings. Whilst I can't see us getting any more types of scrollers, it might be a tad short-sighted to have the "both" thing in there. A better name would be appreciated, if anybody can come up with one. Also, scroll_ceil_type doesn't really work for carrying, as it was a think killough wanted it but never implemented. It's DSTINK and warn you if you try to do so at the moment. Commit: https://github.com/team-eternity/eternity/commit/5b8638a6268a0df13c098da0692685e7d8dd7bda Expect more small QoL changes to come in like this, as whilst UDMF is great for big sweeping changes (like our portals or ZDoom's slopes), I feel that both parties have neglected certain little things that can be done with UDMF properties. EDIT: Fixed some stuff https://github.com/team-eternity/eternity/commit/b7dcdcdb64e1c483c7dbb0ee9d745a8680c34932 Might tweak Scroll_Floor and Scroll_Ceiling to be a bool at some point, which would choose whether or not to override or add on.

My main concern here hasn't been addressed. How far along is the actor definition, in relatively objective terms? What capabilities are planned for the initial phase, if any?

Duly noted. See the below post for my reply to this, as the content of that being here would derail the thread.

In the UMAPINFO thread (posting here as it's the correct place to do so): How preliminary are we talking here? Like are you starting to define language at all? This was one of those real sticking points, to the point that I'm surprised it's being acted upon so soon when there's smaller things to take stabs at. I thought the general agreement was to disagree for now and try and push any and all work on this to later on? I just see a scenario where somebody disagrees with the implementation due to lack of discussion, then are painted as unreasonable obstacles to progress due to this. This is fine if it's just like, starting to add stuff that will later on allow for use of a content definition language for this (like how weaponinfo_t works in non weapons-branch Eternity).

A prior comment asked Graf directly if he'd be willing to accept a pull request. I thought that from this, somebody familiar enough with git would understand that I am going to be doing this on a fork of Graf's PRBoom+ repository. I apologise if I didn't make that clear enough.

I'll be making a pull request for the new properties into SLADE. Also I'm pretty happy with this release. Stability kinks ironed out, and a few little things that improve stuff in small ways. Also the attached portals are fucking awesome.

How I'll probably tackle this: Step 1: Make it so that all pre-UMAPINFO demos work correctly, hopefully whilst still respecting visual-only settings (like how sky transfers work in -cl9 demos) Step 2: Try to implement the new demo header system Step 3: i: Test that shit to hell and back ii: Deliberate on what more might be needed iii. Implement whatever more is needed iv: Iterate the previous few steps until everybody is happy I'd say that step 3 doesn't need to happen until steps 1 and 2 happen. This effectively leaves me to my devices, and the conversation can be pointed back to whatever people are more keen on talking about. It wasn't my intention to bring all the discussion to this issue, merely to highlight it and make sure that it gets addressed (with me being the one doing most of the engine parts of the addressing). This all being said, I hope we can go back to prior discussion.

Oh shit I forgot to send my test map. I fidgeted about with the values in the actual map and ACS script, tested them against ZDoom values as well to make sure that they're the same speed and such. UDMF_Scroll.7z

Any update on the *ZDoom front regarding this? I'm pretty much ready to make this feature actively documented if you're OK with it as-is.

I mean that's not the only way. I did say the following:

Because in this case, the version of UMAPINFO used and the physics shouldn't be linked. You should have separate numbers in the header for them. I can have a mapset that is vanilla except it has 33 maps, or Boom and it decides to jump from MAP13 to MAP49, and I should be able to say "cl2 with UMAPINFO 1" or "cl9 with UMAPINFO 3" if I want to.

A feature that can't be trusted on to be stable for demo compat, and/or has behaviour that can't be replicated in future versions, doesn't belong in PRBoom+. Of course a demo shouldn't survive a wad changing, but in PRBoom+ the demo should survive the port changing. The most robust solution would be to have a secondary complevel for UMAPINFO so we can replicate any older demos that use UMAPINFO. The only other real way of doing it is to ensure that UMAPINFO never changes. Well neither implementation have made it into a release build of anything yet, so that's not an issue. Kinks can be ironed out and anybody who is relying on these features already shouldn't expect total stability.

Oh cool (comment stuff being standard). I totally understand being occupied with IRL stuff. I'm trying to fit in my healthy dose of coding between play sessions with the dog, whilst she's calming down.