EDGE 2.1.0 Discussion [RC-1 Released on 10.3.2018]

[RUNSABER]

^That sliding projectile bug was around for quite awhile, I had to go in and do additional DDF editing just to get them to stop, and even if you do THAT, the shells lose their velocity and have no realistic inertia at that point: merely stopping in place after a bounce.

As far as ammo goes, just use COAL and add a string to display current ammo and loaded ammo. I did it for DAMNED, you should be able to do it too.

[Coraline]

^That sliding projectile bug was around for quite awhile, I had to go in and do additional DDF editing just to get them to stop, and even if you do THAT, the shells lose their velocity and have no realistic inertia at that point: merely stopping in place after a bounce.

I provided a new release, 3DGE-2.1.0-Test3 RC2, which should have the sliding bug fixed.

All we did was change the wall bounce from random to perpendicular, so now they will *never* slide or bounce or sound loop anymore, at least with RC1.

Try this one out guys and let me know!

[CeeJay]

I'm no programmer, but can't you go back to version 2.0.4 Final and compare the bouncing code with the Test builds? This issue appeared first in Test 1.

might be too late, but have you figured out how to do the reload code where its one shell at a time, but when it hits full cap, it stops the reload animation? like with a shotgun

Something I've been asking for multiple times over the years, even came up with basic ideas of how it would function DDF-wise.

[Coraline]

might be too late, but have you figured out how to do the reload code where its one shell at a time, but when it hits full cap, it stops the reload animation? like with a shotgun

Something I've been asking for multiple times over the years, even came up with basic ideas of how it would function DDF-wise.

Guess what -- we now have this ability. Heres a quick rundown:

We now have the ability to loop weapon sprite
states based on the quantity of ammo used to reload a clip. I made a
new DDF weapon action called DJNE. It's just like JUMP, but decrements
the reload quantity for the specified attack and jumps if it's not
zero. The jump chance is now interpreted as the attack specifier: 0% is the primary attack ammo, and non-zero percent is the secondary attack ammo. For example, I modified Duke It Out's shotgun like this

STATES(SECRELOAD)=SHGC:A:2:NORMAL:NOTHING,
SHGC:B:2:NORMAL:NOTHING,
SHGC:C:3:NORMAL:NOTHING,
SHGC:D:2:NORMAL:NOTHING,
SHGC:E:0:NORMAL:EJECT(SHOTGUN_CASING),
SHGC:E:4:NORMAL:PLAYSOUND(SGCOCK),
SHGC:D:2:NORMAL:NOTHING,
SHGC:C:3:NORMAL:NOTHING,
SHGC:B:2:NORMAL:NOTHING,
SHGC:A:2:NORMAL:NOTHING,
SHGG:A:0:NORMAL:DJNE(SECRELOAD:1,100%),
SHGG:A:0:NORMAL:SEC_REFIRE;
STATES(SECATTACK)=SHGG:A:3:LIT90:SEC_SHOOT,
SHGG:B:3:NORMAL:NOTHING,
SHGG:C:2:NORMAL:NOTHING,
SHGG:A:2:NORMAL:EJECT(SHOTGUN_CASING_II),
SHGG:A:0:NORMAL:SEC_CHECKRELOAD,
SHGG:A:2:NORMAL:NOTHING;
SHGG:A:0:NORMAL:SEC_REFIRE;

where I also set the SEC_CLIPSIZE to 10. So the primary attack does one shot and reloads, while the secondary attack does up to ten shots, then does the reload animation up to ten times. If you shoot three times and manually reload, it does three reload animations. A modder would put individual shell insertions in there, but I just made use of
the existing animation. Note that like the JUMP, it can jump to
anywhere. So it's pretty flexible. For my simple change, I make it
jump to SECRELOAD entry 1 (the start of reloading).

This will be in RC4, which I might push tonight or tomorrow.

[Coraline]

I'm no programmer, but can't you go back to version 2.0.4 Final and compare the bouncing code with the Test builds? This issue appeared first in Test 1.

And we cannot - the symantecs changed between that and 2.1.0. Its not a big deal anymore - we fixed the bounce code already

[chronoteeth]

might be too late, but have you figured out how to do the reload code where its one shell at a time, but when it hits full cap, it stops the reload animation? like with a shotgun

Something I've been asking for multiple times over the years, even came up with basic ideas of how it would function DDF-wise.

Guess what -- we now have this ability. Heres a quick rundown:

We now have the ability to loop weapon sprite
states based on the quantity of ammo used to reload a clip. I made a
new DDF weapon action called DJNE. It's just like JUMP, but decrements
the reload quantity for the specified attack and jumps if it's not
zero. The jump chance is now interpreted as the attack specifier: 0% is the primary attack ammo, and non-zero percent is the secondary attack ammo. For example, I modified Duke It Out's shotgun like this

STATES(SECRELOAD)=SHGC:A:2:NORMAL:NOTHING,
SHGC:B:2:NORMAL:NOTHING,
SHGC:C:3:NORMAL:NOTHING,
SHGC:D:2:NORMAL:NOTHING,
SHGC:E:0:NORMAL:EJECT(SHOTGUN_CASING),
SHGC:E:4:NORMAL:PLAYSOUND(SGCOCK),
SHGC:D:2:NORMAL:NOTHING,
SHGC:C:3:NORMAL:NOTHING,
SHGC:B:2:NORMAL:NOTHING,
SHGC:A:2:NORMAL:NOTHING,
SHGG:A:0:NORMAL:DJNE(SECRELOAD:1,100%),
SHGG:A:0:NORMAL:SEC_REFIRE;
STATES(SECATTACK)=SHGG:A:3:LIT90:SEC_SHOOT,
SHGG:B:3:NORMAL:NOTHING,
SHGG:C:2:NORMAL:NOTHING,
SHGG:A:2:NORMAL:EJECT(SHOTGUN_CASING_II),
SHGG:A:0:NORMAL:SEC_CHECKRELOAD,
SHGG:A:2:NORMAL:NOTHING;
SHGG:A:0:NORMAL:SEC_REFIRE;

where I also set the SEC_CLIPSIZE to 10. So the primary attack does one shot and reloads, while the secondary attack does up to ten shots, then does the reload animation up to ten times. If you shoot three times and manually reload, it does three reload animations. A modder would put individual shell insertions in there, but I just made use of
the existing animation. Note that like the JUMP, it can jump to
anywhere. So it's pretty flexible. For my simple change, I make it
jump to SECRELOAD entry 1 (the start of reloading).

This will be in RC4, which I might push tonight or tomorrow.

whilst this does work, doesnt it sorta... eliminate the ability to give weapons alternate fires or alternate reloads? since you're going to the sec attack?

[Coraline]

No. Notice that it was the secondary reload that was modified for the test. You can have it do either the primary or the secondary attack.

Remember that the jump label (SECRELOAD:1 in the example above) can be ANY weapon state at all! The jump chance
is now an indicator for which ammo quantity to decrement. In the example, it used 100% to indicate
the secondary ammo quantity. DJNE uses the chance to figure out which quantity to decrement,
and if the result is not zero, jumps to the weapon state indicated by the jump label.

The quantity is part of the weapon struct, so this is per-weapon, not global. And there are two entries so that it can be
either or both the primary or secondary ammo.

[CeeJay]

Interesting, I'll give it a try in Immoral Conduct 2 as this mod had proper reloading for the shotgun (the ol' fashioned way).

Don't push the builds, I would rather see as many bugs and glitches as possible sorted out before new releases.

EDIT: Another thing I'd be dying to see implemented would be RTS being able to directly "communicate" with WEAPONS.DDF somehow. Calling for specefic states independantly from the weapon you currently using (can you say quick kick) or trigger the current weapon to go to a certain state. Think it could open up a lot of doors.

[RUNSABER]

Thought I'd put together a little mock level to test these new engine features out, and I will say that the upcoming PK3 support makes communication between files VERY easy - so easy that you can save time creating the necessary resource files for modding by simply dragging and dropping. These new features will definitely make it easier for new comers to set up and play. On the other hand, I found my MAP01.WAD lumps not loading or being trumped by DOOMII's MAP01 priority. Even dropping the .wad into the root directory didnt work, so to save myself more hours of frustration and potentially get enough back for sleeping, I decided to stick with the .WAD setup. PNG offsetting is still an absolute pain, with me questioning editing them in SLADE OR by DDF is worth dealing with. For me, the standard setup is still a go.

I tested overlaying translucent sprites on top of one another and by gosh - they dont seem to look weird or glitchy though the black backgrounds in PNGs still need to be removed in order for them to look clean. I would like to see additive translucency in the future, or some way to play around with its alpha channels.

My computer still runs 3DGE like shit, so the only way to increase framerate is to reduce the radius/intensity of the dynamic lights used in-game. I'll have to keep a personally-configured DDF file aside just for me - good thing 3DGE is customizable!

Questions regarding dynamic lights. So far I only know of: QUADRATIC, LINEAR, CONSTANT, MODULATE, and ADD. Can you explain the uses of each one, which ones are still working/not working, and which is best for optimized gameplay? I seem to get the best lighting out of Linear lighting, whereas quadratic lighting is best with pure hexidecimal colors. Lastly please dont push the builds, less bugs is awesome but how can you snuff them out without us testing it! I'll keep playing around and post anything weird.

Update: Multiplayer crashes when 3 or more bots are used. In earlier versions of 3DGE I was able to play Greenwar with at least 12-14 bots.

[Danfun64]

I provided a new release, 3DGE-2.1.0-Test3 RC2

...source code? Is this release (or anything made afterwards) available on the Hyper3dge trunk? What progress has been made on the split-screen/controls/controller front?

[Coraline]

I provided a new release, 3DGE-2.1.0-Test3 RC2

...source code? Is this release (or anything made afterwards) available on the Hyper3dge trunk? What progress has been made on the split-screen/controls/controller front?

It's linked to our Github -- if you check the changelog, you can see the link for yourself. ^_^

We are still fixing bugs before moving to split-screen. I have been loosely eyeballing how Eternity does it now,
with a brief explanation from its developer, so hopefully not too much longer.

EDIT: Another thing I'd be dying to see implemented would be RTS being able to directly "communicate" with WEAPONS.DDF somehow. Calling for specefic states independantly from the weapon you currently using (can you say quick kick) or trigger the current weapon to go to a certain state. Think it could open up a lot of doors.

Well about that, you can use RTS_ENABLED_TAG and RTS_DISABLED_TAG. It would be able to communicate just fine -- is that what you were trying
to refer to? Or do you mean something more specific?

For instance,

---

So if you want the trigger to occur when a weapon is switched to
(instead of fired, for example), put the RTS_ENABLE_TAGGED into the
weapon up state list, and make a trigger with the on-condition
HEALTH(1). As long as you have at least 1 health (you would be dead
with 0 health), it will trigger the moment it's enabled by switching
to the weapon. You can put RTS_DISABLE_TAGGED in the weapon down state
list to turn off the trigger when not using the weapon.

[Graf Zahl]

e moving to split-screen.

If I may ask: What's so compelling about that feature?

[Rachael]

It allows two people to play a multiplayer of the same game with controllers. My ex made me do it with Borderlands 2 on her XBox.

[Coraline]

It allows two people to play a multiplayer of the same game with controllers. My ex made me do it with Borderlands 2 on her XBox.

Yep. It's the best thing to Multiplayer that 3DGE has right now.

Can anyone test out the RTS_ENABLED_TAGGED(); in Weapons.ddf? Is that what you guys wanted when you
explained the RTS <-> Weapons.ddf communication?

[CeeJay]

Well about that, you can use RTS_ENABLED_TAG and RTS_DISABLED_TAG. It would be able to communicate just fine -- is that what you were trying
to refer to? Or do you mean something more specific?

Yes, something like that. I'll throw together a little demo to test it.