Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Quasar

Eternity Engine 3.40.46 Bifrost

Recommended Posts

Catoptromancy said:

I can confirm that this release is indeed awesome.

It certainly is. Congratulations on the release Quasar! Just spent 15 odd minutes playing D2TWiD on it. I also notice that the looping issue is completely gone now.

Share this post


Link to post

Because it wasn't emphasized in the OP and weirdo folks like me find this a super-huge edition:



That is all. Carry on.

Share this post


Link to post

Loving the uncapped framerate! Of course all of the other changes are great as well, but I've been waiting on uncapped framerate the most :)

Nice stuff!

Share this post


Link to post

I was most excited by the x input force feedback. Sadly, I seem to have an issue. I have a Logitech F710 wireless controller set to x input. The game recognises it but I can't seem to set up the analogue sticks to movement properly. For example; I select up on the left analogue stick for move forward but when I select down for move backward the game picks the same axis and therefore cancels the move forward. The same happens with both sticks and analogue triggers... I've tried using the controller as x input and SDL input as both are selectable.

I'm running Win7 PRo 64 bit.

Share this post


Link to post
Average said:

I was most excited by the x input force feedback. Sadly, I seem to have an issue. I have a Logitech F710 wireless controller set to x input. The game recognises it but I can't seem to set up the analogue sticks to movement properly. For example; I select up on the left analogue stick for move forward but when I select down for move backward the game picks the same axis and therefore cancels the move forward. The same happens with both sticks and analogue triggers... I've tried using the controller as x input and SDL input as both are selectable.

I'm running Win7 PRo 64 bit.

This is very poorly explained because I never have finished a UI for editing the settings yet, but what you need to do is not bind axis activations to key binding settings - you need to set what are called the "axis actions". There are variables for g_axisaction1 through g_axisaction8 IIRC. Their possible values are "move", "turn", "strafe", "look", and "fly".

If you open eternity.pke and look at /gamepads/xbox360.txt, you should see a very good example of what it would look like.

This is a part of EE that's unfinished and needs more polishing.

You can find the correspondence of your gamepads' axes to the axis # variables by using the gamepad test menu, BTW.

Share this post


Link to post
Xaser said:

Because it wasn't emphasized in the OP and weirdo folks like me find this a super-huge edition:

*snip*

That is all. Carry on.


Ditto!

Share this post


Link to post
Average said:

Cheers. I'll give it a look-see.

If you get a working config, you could submit your keys.csc to me to make a profile for that device and then future users could simply load your profile from the gamepad profiles list and get one-shot configuration.

Let me know if you get it going.

Share this post


Link to post
Quasar said:

If you get a working config, you could submit your keys.csc to me to make a profile for that device and then future users could simply load your profile from the gamepad profiles list and get one-shot configuration.

Let me know if you get it going.


I will do. I haven't had time to yet but I'll get around to it. :)

Share this post


Link to post

This release... I like it! ANOTHER!

One question: what determines the damage reduction of a player's current armor? The wiki makes it look as if the last picked-up armor bonus determines this, instead of it being a hardcoded boundary between 100 and 100+ for 33% versus 50% damage reduction.

Share this post


Link to post
Mordeth said:

One question: what determines the damage reduction of a player's current armor? The wiki makes it look as if the last picked-up armor bonus determines this, instead of it being a hardcoded boundary between 100 and 100+ for 33% versus 50% damage reduction.


Then the wiki would be right. A blue armor damaged to 100% or below still gives 50% damage reduction, a green armor boosted up to 200% with armor bonuses still gives 33% damage reduction.

Speaking of armor bonuses, if you do not have an armor already, they give you the equivalent of green armor for damage reduction purposes (33%).

This is vanilla behavior, and Eternity has had no reason to change it.

Share this post


Link to post

Heh, I never realized that.

So you could basically have eg. a 1-200 armor system based off 'green armor' boosts with a standard 33% damage reduction, and a new kind of (temporary) powerup that boosts your damage reduction. Or monsters that try to hit you with stuff that actually lowers your armor damage reduction.

Too bad there's no HUD item that could tell the player what kind of damage reduction he currently has...

Edit: no, this does some weird stuff. If savefactor >> savedivisor (negative dmg reduction) then at the first hit the saveamount will be added to the player's health while armor resets to zero.

Share this post


Link to post

Problem on windows 10, msvcr110.dll is missing by default. I do have Microsoft Visual C++ 2010 Redistributable Package (x86) installed (apparently). Attempting to install it afresh fails as a newer version is already installed. Installing Visual C++ Redistributable Packages for Visual Studio 2013 didn't cure the problem.

The latest nightly works though. I get the error when midiproc (not in the nightly) is executed by eternity.exe.

Share this post


Link to post
Jon said:

Problem on windows 10, msvcr110.dll is missing by default. I do have Microsoft Visual C++ 2010 Redistributable Package (x86) installed (apparently). Attempting to install it afresh fails as a newer version is already installed. Installing Visual C++ Redistributable Packages for Visual Studio 2013 didn't cure the problem.

The latest nightly works though. I get the error when midiproc (not in the nightly) is executed by eternity.exe.

msvcr110 is the Visual C++ 2012 runtime, so you need to grab that version as well. Eternity's prior build was compiled against 2012. AFAIK, nightlies by Blzut3 are built either against 2013 or 2015. EE will likely migrate up to one or other whenever I resume development on it.

Share this post


Link to post

is the odamex multiplayer code portable enough to be "added" in eternity without much labor? both ports seems to have the same base.

Share this post


Link to post

I would have thought that adding Chocolate/Crispy Dooms netcode would be easier, at least for a start.

No, Eternity and Odamex do not have the same base. Eternity is based off Smack My Marine Up, which is based off Marines Best Friend, which is based off Boom, which is based off DosDoom. Odamex is based off CSDoom, which is based off ZDoom 1.22. Completely different lineages.

Share this post


Link to post

The lineages for the ports themselves are different, but for the netcode part, I'm not sure. Ladna, an Odamex contributor, used to work on Eternity as well, there was a whole client-server branch which sits uncompleted to this day. (Looks like Ladna's Github name is Camgunz.)

Share this post


Link to post

Would be nice if Eternity had a hybrid multiplayer system.

If -vanilla is applied, it would use the Chocolate/Crispy Doom protocol, and is completely capable of joining Chocolate/Crispy servers, and vice versa (Chocolate/Crispy server able to join Eternity servers with -vanilla)

If -vanilla is not applied, it would run its own protocol, meaning it could do whatever it wanted, whether a system that is similar to Chocolate/Crispy, or a client-server system like Odamex, ZDaemon, Zandronum, and the dead client-server branch/fork/whatever. Also, if a -boom or -mbf or an all around -complevel system is implemented, due to the ridiculousness regressions needed to support those ports (like putting in DosBox's ipxnet code and restoring ipx code removed in Eternity), it could use the new system, but have chocolate/crispy style limitations (4 players max, no in-game joining, etc)

Yes, this is all wishful thinking, and I really wish either PrBoom or Eternity would get decent netcode, or odamex finally gets a stabilized demo protocol and stabilized coop support, preferably both.

Share this post


Link to post

-vanilla would be a misnomer because Choco/Crispy doesn't use vanilla netcode at all. Something like -choconet would be more appropriate.

Share this post


Link to post
Gez said:

(Looks like Ladna's Github name is Camgunz.)

And he's working on a c/s fork of prboom-plus instead of eecs now. Honestly, I don't even.

Share this post


Link to post

Creating a C/S fork of Eternity is understandable, as it is

A. A moving platform.
B. Advanced enough to eventually be a FLOSS rival to the non-free Zandronum.

Creating a C/S fork of PrBoom-Plus...makes no sense. If anything, it should have the Chocolate/Crispy Doom multiplayer code adapted for it. Adding something like a C/S fork of PrBoom-Plus probably goes against PrBoom-Plus's mission statement or something :P

Share this post


Link to post
Danfun64 said:

Creating a C/S fork of Eternity is understandable, as it is

A. A moving platform.
B. Advanced enough to eventually be a FLOSS rival to the non-free Zandronum.


Zandronum is open-source, though.

License

New code in Zandronum is released under a 4-clause license based on the OSI-approved and GPL-compatible Sleepycat License, with the addition of the "No Endorsement" clause from the 3-clause New BSD License. Practically, this means that Zandronum's source code is safe to use in either GPL or Doom Source License/Raven Source License/etc. source ports as long as the terms of the Zandronum license are satisfied.

The Zandronum license only covers Zandronum-specific code. Some source files contain additional notices of original copyright by their contributors.

See ZDoom license page for more details on other licenses used within Zandronum.


That means that you can take the GLOOME approach, remove the software renderer, OPL emulator, and FMOD sound backend, and get a GPL-compatible Zanders.

Danfun64 said:

Creating a C/S fork of PrBoom-Plus...makes no sense. If anything, it should have the Chocolate/Crispy Doom multiplayer code adapted for it. Adding something like a C/S fork of PrBoom-Plus probably goes against PrBoom-Plus's mission statement or something :P

I think it's safe to say that PrBoom+'s mission statement is left far behind in the dust. It's the kind of overreaching ambition that makes me think it'll be vaporware, but you never know...

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×