[oasiz]

++ Nothing official yet, just splitting this to have things in one place as the list grew quite quickly ++

I'm planning to introduce some simple effect extensions down the line to mainline eduke32.
TX was open to such requests as long as they aren't completely shit and stupid.

This would work by utilizing PAL23 (yellow key) on some effector sprites.

Already what is configured a few months back is a D (masterswitch) that can be re-triggered multiple times.
This means that it's sort of like an activator but with user delays.


Functionality would always rely on PAL23 or everything "new" would be 100% ignored.
These would be very basic few line changes at first such as:
- Disable interpolation for escalators, you get 30fps motion but it looks continous
- Allow some control over ST15 warp elevators (possibly based on horiz/jump/crouch or maybe rigged to activators)
- SE29 "float" would use it's angle to determine: UP (ceiling) DOWN (floor) Left/right (both)
- Hopefully a musicandfx that can be triggered on/off or one-off sounds could be triggered
- Maybe things with respawn (or a duplicate) that allows you to spawn inanimate sprites as 1:1 (change the picnum + stat)

Down the line I would like to introduce some additional effects as new SE numbers but these would have to be designed in a way that doesn't clash.
I think PAL23 is a rather safe bet for now.

If there are simple things along the line of this, I would be curious to hear from mappers.
As much as I love working around things or coming up with clever ways, let's admit that some things would be a lot smoother if everything didn't rely on a brittle one-off construct.
Ideal end game scenario would be less reliance on CON to run larger world effects but still have the map format be 100% compatible otherwise.

Considering that we have a very good 1.5 source reconstruction, it could be possible that I backport these changes for DOS usage as well to have some love there too.

[Aleks]

oasiz, on 16 August 2022 - 01:49 AM, said:

I'm planning to introduce some simple effect extensions down the line to mainline eduke32.
TX was open to such requests as long as they aren't completely shit and stupid.

This would work by utilizing PAL23 (yellow key) on some effector sprites.

This sounds like a great idea, there is indeed a lot of effects that are almost possible to implement with just vanilla Duke or that require such a vast workaround that they are barely worth the extra resources required to invest.

Quote

- Hopefully a musicandfx that can be triggered on/off or one-off sounds could be triggered

This can technically be implemented right now with an activator locked + musicandsfx sprites in the same sector for ambient sounds, but it's impossible to turn off the sound if the player is standing in its radius - so perhaps this wouldn't really need a lot of extra work (also IIRC it was possible to turn off back in the original DOS Duke, but not sure about this).


Few other ideas from the top of my head that would make the life much easier:

• locators that could be actually linked to certain subway/RPV, so that there could be more than a single path created in a map (maybe being able to start from a different number than lotag 0 for the locators, e.g. matching the channel for subway SE sprite, would do the trick at least for having more subways and a single RPV path?);
• cyclers, SE8/SE9 and SE12 (not sure if it would make sense with SE3/SE4 as these already use palettes for something else) that only lighten the walls and ceiling/floor of a sector (so e.g. the shadow cast from the lintel can be easily done instead of masking the ceiling with sprites);
• SE20 that only affects floor/ceiling.

If you don't mind, I'll be messaging you on Discord when I come up/remind myself of other stuff like that, which is something I get quite often while mapping

[oasiz]

Hi,

Thanks for the ideas!

* Locators, I think this might require a lot of extra work. I'd have to look more in to this.
* Light thing, this does sound interesting indeed, yeah. Remember that you can already tag walls to prevent this. However separate floor/ceiling is very helpful.
* SE20, this is the bridge FX? This works by moving wallpoints around so it technically has to affect walls and not just floor/ceiling.

Discord is fine, I wanted to have this here for documentation purposes as well.

Once I get more knowledge, I kind of want to port over the sector copy functionality at some point as this allows all sorts of things.

[quakis]

oasiz, on 16 August 2022 - 01:49 AM, said:

I'm planning to introduce some simple effect extensions down the line to mainline eduke32.

So we might be getting our own Boom equivalent of extended mapping features down the line, too? Haha. I look forward to seeing where this goes.

One thing comes to mind I'd love to see "fixed" ; Light switches remembering all your intricate shading and not defaulting everything to a flat value once reset. Might actually use the darn things.

Gets me dreaming of the improbable - lifting Blood's entire editor feature set right into Duke's. Blood mapping was such a joy working with, all that control and other possibilities I've barely yet tapped into. If I wasn't already swamped with stuff, I'd return to mapping for it in a flash.

[Danukem]

oasiz, on 16 August 2022 - 01:49 AM, said:

- Maybe things with respawn (or a duplicate) that allows you to spawn inanimate sprites as 1:1 (change the picnum + stat)

Can you explain what you mean by this?

Various mods already extend the abilities of respawn and other effectors; I worry that changing picnum and/or statnum of something spawned would break existing mod features, depending on how it was implemented.

[oasiz]

quakis, on 16 August 2022 - 04:10 PM, said:

So we might be getting our own Boom equivalent of extended mapping features down the line, too? Haha. I look forward to seeing where this goes.One thing comes to mind I'd love to see "fixed" ; Light switches remembering all your intricate shading and not defaulting everything to a flat value once reset. Might actually use the darn things.Gets me dreaming of the improbable - lifting Blood's entire editor feature set right into Duke's. Blood mapping was such a joy working with, all that control and other possibilities I've barely yet tapped into. If I wasn't already swamped with stuff, I'd return to mapping for it in a flash.

That would require an overhaul of the system, plan is to focus on easy quick wins. I'm not a C++ programmer but I know that many things are achievable with just some extra flags

Danukem, on 16 August 2022 - 08:53 PM, said:

Can you explain what you mean by this?Various mods already extend the abilities of respawn and other effectors; I worry that changing picnum and/or statnum of something spawned would break existing mod features, depending on how it was implemented.

The goal here is to slightly reduce reliance on CON effectors that tend to reinvent the wheel from mod to mod.
This is why the feature is strictly opt-in and the above example could be used to "spawn" i.e. a staircase from sprites or other such things.
Not to create a full fledged replacement effector replacement that mods now have to hook onto.

Some of these like float/wave on ceiling would be something that already is implemented in Fury but there are honestly so many things that needlessly require extra coding, which increases the entry barrier for those who just want to do stuff in Vanilla.
A lot of the times the CON way is also not as efficient speed-wise as it could be.

I think the best examples here would be that lighting affecting only floor/ceiling or neither. Or fixing slidedoor's autoclose.
Simple "if" cases for the most part but they just need to be hooked onto

In a way I'd wish there was a CON set that purely focused on mapping experience without affecting vanilla but it would have to be engineered and done in a way that doesn't interfere with other loaded CONs, among other things.
At least with this approach I could document changes and compile a DOS 1.5 binary.

[Jan Satcitananda]

oasiz, on 16 August 2022 - 01:49 AM, said:

Down the line I would like to introduce some additional effects as new SE numbers but these would have to be designed in a way that doesn't clash.
I think PAL23 is a rather safe bet for now.

If there are simple things along the line of this, I would be curious to hear from mappers.
As much as I love working around things or coming up with clever ways, let's admit that some things would be a lot smoother if everything didn't rely on a brittle one-off construct.
Ideal end game scenario would be less reliance on CON to run larger world effects but still have the map format be 100% compatible otherwise.

Considering that we have a very good 1.5 source reconstruction, it could be possible that I backport these changes for DOS usage as well to have some love there too.

Great to know that you're going to extend the vanilla Duke effects and also want to preserve backward compatibility (EDuke32 used to be pretty loose on the latter what is a big shame).

Please consider a "no interpolation" option for effects like floor/ceiling rise and elevators! This could be useful to make things appear and disappear out of the view instantly. Maybe an "instant" SE 31/32 (with an infinite speed) that just set z's to their final value would be a great addition and make mapper's life easier.

[oasiz]

Even better, I want to implement a new SE for such that is sector copy/paste.
This is what we have in Fury and already present in games such as RR, maybe I can study it's code for this.
Something like this would be more down the list of features but It's one of my "musthaves"

Basically what you can do is have (made up numbers) SE64 on a sector, which is a "destination" and SE65 which is source.

Lotag = SE number
Hitag = Trigger
Extra = Pairs (i.e. 5 sectors you want to copy would be 1-2-3-4-5.. as unique identifiers)

A very crude version would be "copy all" which includes Z, slope, ceiling/floor height picnums, tags and all.
This is probably one of the most powerful things that exists in Fury.
There we use other tags to further specify things like "Only copy heights, only copy lighting" etc..

You'd walk over a touchplate/press a button and it would trigger such things.


Edit: Disabling interpolation would be easy as it's just not calling one function that adds it to the list of sectors.
I kind of want to be a bit more like SW with the approach eventually where a sprite's .extra could somehow be used as a bitfield for behavior changes (further reducing risk for compatibility as it's PAL + bitmask to enable anything). With a simple m32 script it should be easy to toggle things on/off along with the usual documentation.

[Danukem]

oasiz, on 16 August 2022 - 10:00 PM, said:

The goal here is to slightly reduce reliance on CON effectors that tend to reinvent the wheel from mod to mod.
This is why the feature is strictly opt-in

I do think the only way that new mapping features will be universally adopted in the community is to build them into the source code. No CON mod would be universally adopted, even if it was distributed with EDuke32. And as you pointed out, implementing through CON is not necessarily efficient.

Some of us modders have been using all the existing tags supported by the .map format (PAL, EXTRA, LOTAG, HITAG, XVEL, YVEL, ZVEL, OWNER) to store information about our effects and flag for various things. Unless you expand the .map format to include new tags, then the new features will be triggered by those same tags. As long as the additions are confined new features on existing sector effector lotags (e.g. it only goes into effect when its an SE20 and EXTRA is tagged) then the potential for breaking mods is pretty limited, since typically we leave the old hardcoded effects alone and we make new ones. I personally like to code on the unused lotags of sectoreffectors for my effects.

[brullov]

Here we go:

• Enemies/NPCs spawn keys/ any other custom pickup after kill;
• Custom speed for slide doors;
• Ability to change the speed of the one-way train;
• Silent + no visual effect respawn effect;
• Weather Effector (place a SE inside the sector with a parallax sky and it will automatically create raindrops or snow) / would be nice to control the frequency of the particles too;
• Special PAL which will force enemies to not see the player from behind (like in Doom);
• Special PAL which will force enemies to be harmless (they do not attack the player);
• Ability to have a conveyor belt that is off at the beginning of the level;
• Ability to add any sound FX for a one-way train while it's moving;
• Ability to make a curved way for a one-way train;
• Ability to use any sound for ambient fx with custom replay delay;
• Ability to force any sprite to be unbreakable;
• Ability to force any sprite to be breakable;
• Delay effect;
• Kill them all effector. After the player kills a certain amount of enemies, this effector activates;
• Be able to make any sprite as a custom 'keycard' or a needed object to the proceeding. E.g. the player needs to pick up fuel to activate the generator;
• Custom particle spawner with custom trajectory (smoke effect, jibs coming from the pipe or fireballs);
• Projectile shooters with more control. Work with delay, projectile amount, speed, and touchplate. (E.g. be able to create turrets controlled by the player);
• More customizable light effects: delay, color swap, one-time activation;
• Engine, but it works for the floor and walls too;
• Vehicles with player control;
• Swinging gates (swing doors made of flat sprites);
• Z-motion (vertical) flat sprite move (doom doors made of flat sprites);
• X/Y flat sprite move (slide doors made of flat sprites);
• Destroy them all effector. After the player destroys a certain amount of breakable objects, this effector activates;
• Vertical player movement (ladders, ropes);
• Sprite remover (after activation, sprite deletes);
• Activated touchplate;
• Delayed SFX;
• SE for the instant player kill;

This is a short list that came to mind immediately. Maybe I will add more ideas later. I understand that most of my ideas here are useless, but I'd be glad to have any of them!

P.S. I always wanted to be able to create custom enemies. E.g. with custom sprite PAL I could change the enemy's projectile, assault trooper throwing pipebombs in your face!

P.S.S. I also would like to create custom bosses. E.g. with custom sprite PAL pig cop can have much more health. Would be nice to mix this effect with the ability to change enemy's type attack.

P.S.S.S. Bosses made with sectors! A giant robot, or alien creature.

[Ninety-Six]

I don't know what literally any of this means but more built-in accessible features is always a plus.

[Reaper_Man]

brullov, on 17 August 2022 - 03:50 AM, said:

Here we go:

Some of this seems more suited to being done in scripting, and not as new / extensions of existing SE effects. For example, virtually every enemy's code is handled in CON already, meaning extending their behavior wouldn't be done in the source code. Doing things like changing their attack or HP amount is trivial, making them passive or "can't see from behind" is less so but still very doable.

Things like hardcoded sound effects being exported to MUSICANDSFX, extending more SEs to using GPSEED, silent RESPAWNs, all seem great. In a broad sense, any effects with hardcoded behaviors should be able to be overridden by the mapper.

[brullov]

Reaper_Man, on 17 August 2022 - 05:54 AM, said:

Some of this seems more suited to being done in scripting, and not as new / extensions of existing SE effects. For example, virtually every enemy's code is handled in CON already, meaning extending their behavior wouldn't be done in the source code. Doing things like changing their attack or HP amount is trivial, making them passive or "can't see from behind" is less so but still very doable.

Things like hardcoded sound effects being exported to MUSICANDSFX, extending more SEs to using GPSEED, silent RESPAWNs, all seem great. In a broad sense, any effects with hardcoded behaviors should be able to be overridden by the mapper.

100% agreed. I just don't like that Duke's enemies are mostly hitscan / projectile shooters and there is no option for stealth in the game. I also would like to have the ability to make a user map with more enemy variety and not include any custom art/script/sound. I know it sounds silly, but as I mentioned, I'd rather tell you all my ideas with such an opportunity. No need to take them seriously! I am pretty sure most of them can be united and combined in one clever solution.

[Aleks]

oasiz, on 17 August 2022 - 01:13 AM, said:

Even better, I want to implement a new SE for such that is sector copy/paste.
This is what we have in Fury and already present in games such as RR, maybe I can study it's code for this.
Something like this would be more down the list of features but It's one of my "musthaves"

Basically what you can do is have (made up numbers) SE64 on a sector, which is a "destination" and SE65 which is source.

Lotag = SE number
Hitag = Trigger
Extra = Pairs (i.e. 5 sectors you want to copy would be 1-2-3-4-5.. as unique identifiers)

A very crude version would be "copy all" which includes Z, slope, ceiling/floor height picnums, tags and all.
This is probably one of the most powerful things that exists in Fury.
There we use other tags to further specify things like "Only copy heights, only copy lighting" etc..

You'd walk over a touchplate/press a button and it would trigger such things.


Edit: Disabling interpolation would be easy as it's just not calling one function that adds it to the list of sectors.
I kind of want to be a bit more like SW with the approach eventually where a sprite's .extra could somehow be used as a bitfield for behavior changes (further reducing risk for compatibility as it's PAL + bitmask to enable anything). With a simple m32 script it should be easy to toggle things on/off along with the usual documentation.

Speaking of copying sectors, how about implementing the other Ion Fury exclusive effects (of course if you guys as Voidpoint would be OK with this)? I remember reading about SEs for changing slopes or changing firstwall of a sector, which would be great to have, separately from the copy properties one.

As for the stuff Brullov is suggesting, I remember hearing about the "map plus" thing, is this still being worked on (i.e. a map that would "contain" its own extra art/con files for easier and more robust installation), so perhaps that would be a solution for some of his inquiries.

BTW, Oasiz, I suggest you should make a new thread for this thing, since it's already gained significant attention and would probably be easier to keep a track of this way. If you pull this off, it's gonna be a real gamechanger for us mappers!

[oasiz]

I'll do a separate thread when I get time to work on this and it's getting more serious..
Fury stuff is all done in CON, there are no source level changes there.

Any "map plus" would rely on the eventual addon system being worked on.
If any effects would be done then they wouldn't likely be ported as-is as many of them contain loads of workarounds to not require source level edits in the first place (i.e. our ceiling float requires a floor float as a reference and it uses that to create the offsets required for ceiling)


Brullov's list:
== Mostly CON stuff, could perhaps be hacked to RESPAWN or such but low prio
- Enemies/NPCs spawn keys/ any other custom pickup after kill;
- Kill them all effector. After the player kills a certain amount of enemies, this effector activates;

== I think it ties to xvel, it might be possible to override this but not sure. May affect distance.
- Custom speed for slide doors;
- Ability to change the speed of the one-way train;

== I think are in my capabilities and fit the scope more or less
- Silent + no visual effect respawn effect;
- More customizable light effects: delay, color swap, one-time activation; (to some degree)
- Engine, but it works for the floor and walls too; (floor is fine, walls would require use of bridge fx)
- SE for the instant player kill;
- Ability to have a conveyor belt that is off at the beginning of the level;
- Activated touchplate; (why though?)

== CON stuff
- Weather Effector (place a SE inside the sector with a parallax sky and it will automatically create raindrops or snow) / would be nice to control the frequency of the particles too;
- Special PAL which will force enemies to not see the player from behind (like in Doom);
- Special PAL which will force enemies to be harmless (they do not attack the player);
- Ability to force any sprite to be unbreakable;
- Ability to force any sprite to be breakable;
- Be able to make any sprite as a custom 'keycard' or a needed object to the proceeding. E.g. the player needs to pick up fuel to activate the generator;
- Destroy them all effector. After the player destroys a certain amount of breakable objects, this effector activates;
- Vertical player movement (ladders, ropes);

== Low prio / probably out of my skills
- Projectile shooters with more control. Work with delay, projectile amount, speed, and touchplate. (E.g. be able to create turrets controlled by the player);
- Ability to add any sound FX for a one-way train while it's moving;
- Ability to use any sound for ambient fx with custom replay delay;
- Sprite remover (after activation, sprite deletes);
- Delayed SFX;

== Out of scope / too much work
- Ability to make a curved way for a one-way train;
- Custom particle spawner with custom trajectory (smoke effect, jibs coming from the pipe or fireballs);
- Vehicles with player control;
- Swinging gates (swing doors made of flat sprites);
- Z-motion (vertical) flat sprite move (doom doors made of flat sprites);
- X/Y flat sprite move (slide doors made of flat sprites);

- Delay effect;
--> Effects are all case specific, you do have masterswitch PAL23 nowdays which allows retrigger


But let's not get too excited yet
I bet TX will look in horror at this thread and what I come up with before things ever have hope of getting mainlined.
However... I've prototyped some simple changes here and there (i.e. ceiling float) and it's working fine.
I've got some more familiarity with duke3d codebase during the past few years when tinkering with mapster scripts, little bit of CON and now source level (i.e. when I was doing shadow warrior scripts, I had to basically port stuff from editor C file to m32)

RE: Danukem
Yes, this is my main concern. I know all about overusing data fields and every free nibble that is available.
Ion Fury is a very good case in this aspect as I've had to extend the m32 script to make things like velocity editing "easy".
We even use blend some times to define things since lotag/hitag/extra/xvel/yvel/zvel/cstat/owner wasn't enough.
My concern here is that if I use a new tilenum, it might require again overlapping existing tiles.
One option is a "Magic token SE" that would enable a map to even consider enabled features. However I dislike this idea a bit as it would require a bunch of more IF cases vs. just one pal check for existing fx.

Pal23 is very rarely used I believe and it's distinctly visible at least.
I would limit the use to SE/special sprites or such for now.

[brullov]

Thanks for the detailed feedback on my list! TBH, most of my ideas are based on playing Blood and custom episodes for it. As for the 'activated touchplate', it could be used to activate a certain event only after a specific switch was used by the player. Here is an example:

[oasiz]

Ah got it... might be doable but would need to see how.
I think you can already use respawners to do lotag0 touchplates so maybe some control over that would help.

[brullov]

Well, it's just an idea to be without workarounds. I already implemented silent enemy spawners in my map, but it would be cool to have a 'legal' option to create such scripts.

[Danukem]

brullov, on 17 August 2022 - 11:55 AM, said:

Well, it's just an idea to be without workarounds. I already implemented silent enemy spawners in my map, but it would be cool to have a 'legal' option to create such scripts.

Pretty much everything you listed that is doable via CON scripts has been done before; a lot of it was done in my old Duke Plus mod. I'm not saying you should use that mod since it comes with a lot of unwanted baggage.

But my point is I'm sure you could just ask someone for help to cook up a few scripts for your maps and then include them. With Doom64hunter's new mod management system I don't think it would be much trouble for players at all if you are worried about people not being able to play your map.

[brullov]

Danukem, on 17 August 2022 - 12:20 PM, said:

Pretty much everything you listed that is doable via CON scripts has been done before; a lot of it was done in my old Duke Plus mod. I'm not saying you should use that mod since it comes with a lot of unwanted baggage.

But my point is I'm sure you could just ask someone for help to cook up a few scripts for your maps and then include them. With Doom64hunter's new mod management system I don't think it would be much trouble for players at all if you are worried about people not being able to play your map.

There are few reasons:

1. Keep your project simple. It's much easier for a regular player to just drag'n'drop user map and play it rather than installing the mod. Yes, you can make your mod well organized and make it easy to play, but it's psychologically easier to manage fewer files;

2. It's pretty much the same reason as above, but creating additional CONs for a single level is a little bit silly in my opinion. Personally, I always feel lazy to install such maps-mini mods from the past, which require a bit more movement than placing a map and .ogg file in the root;

3. Among all famous Build Engine games (SW, Blood, IF), Duke's editor effects are the weakest. Art assets/enemies variety too by the way. Don't get me wrong, I love Duke and such a 'problem' leaves a lot of space for creativity. But sometimes I wish I could create scripts easier and faster alone. Without any help from coders or more experienced mappers ( thanks oasiz one more time for scripting difficult stuff for my previous releases!).


I am not a CON hater. I am just dreaming about a more powerful Duke Nukem 3D level editor.

[Danukem]

brullov, on 17 August 2022 - 01:07 PM, said:

2. It's pretty much the same reason as above, but creating additional CONs for a single level is a little bit silly in my opinion. Personally, I always feel lazy to install such maps-mini mods from the past, which require a bit more movement than placing a map and .ogg file in the root;

Yeah it would be better if you could load something like a WAD from the user map menu instead of loading a MAP, and the WAD would include whatever is needed. On the other point though, I don't see why you would think of it as creating CONs for a single level. There could be a community CON with general utility functions which could be included with any maps that use it. The code for many of the features you want already exists -- it would just need to be ported over and made more modular.

brullov, on 17 August 2022 - 01:07 PM, said:

3. Among all famous Build Engine games (SW, Blood, IF), Duke's editor effects are the weakest. Art assets/enemies variety too by the way. Don't get me wrong, I love Duke and such a 'problem' leaves a lot of space for creativity.

That's true, but Duke is also the only one where scripts were shipped with the game and have always been an integral part of it.

[Reaper_Man]

I can understand the desire to not ship CON files with minimal changes to them with just for your usermap. That EDuke can load files from subdirectories or from a single ZIP file makes things look more clean and helps portability quite a lot. However:

A.) I'm pretty sure this was explicitly stated by Todd Replogle why USER.CON exists, so users could easily edit gameplay variables and distribute them. So distributing a map with edited CON was something 3D Realms assumed and even expected users would do. But more importantly

B.) Again, virtually all code relating to enemies exists outside of the source code. Meaning there is no sane, non-spaghetti code way to do even the simplest of things, even if extending enemy behavior and functionality was something the EDuke team was wanting to do here. As counter-intuitive as it sounds, that's outside the power and scope of the core game engine, specifically because it's exactly why CON exists and what CON allows you to do. Enemy behaviors are intentionally programmed outside the source code.

[Aleks]

brullov, on 17 August 2022 - 10:38 AM, said:

Thanks for the detailed feedback on my list! TBH, most of my ideas are based on playing Blood and custom episodes for it. As for the 'activated touchplate', it could be used to activate a certain event only after a specific switch was used by the player. Here is an example:

Just to chime in about this one in particular, but it's quite easy to do with targets/shooters (so for example, the touchplate triggers a single shrinker shot in a dummy sector that's inaccessible to player that would hit the target, but the path of the shot is initially blocked by a door that opens when the "activation" of the touchplate is triggered). Also I remember Quakis used a tiny bridge sector with a touchplate in it that would stretch to make it possible for players to step on after some other activation in Flaming Shipwreck, probably could be even easier to do with slide doors.

[brullov]

@Aleks
Yeah, pretty easy


@Reaper_Man

My proposals about enemies aren't worth it, so let's not focus on them that much. I hope more customizable trains and sprite doors won't slip among my not clever ideas.

@Danukem

Community CON is an interesting idea, but I'd like to have something bundled with Eduke32. The addon manager which was teased before is something that we are talking about right now.

[Danukem]

brullov, on 17 August 2022 - 06:21 PM, said:

@Danukem

Community CON is an interesting idea, but I'd like to have something bundled with Eduke32. The addon manager which was teased before is something that we are talking about right now.

These aren't mutually exclusive ideas. The CON bundled with Eduke32 could be made by the community and loaded with the addon manager. It doesn't matter who codes it though, that's not important.

EDIT: And of course it would be great to also have EDuke32 source changes to expand the functionality of SEs etc where it makes sense.

[Reaper_Man]

Since this is it's own thread now I wanted to reiterate in case it was lost as conversation:

Reaper_Man, on 17 August 2022 - 05:54 AM, said:

In a broad sense, any effects with hardcoded behaviors should be able to be overridden by the mapper.

There's a handful of various ST and SE behaviors with hardcoded sounds, speeds, etc. that would be great if mappers could take control of. I know some of these hardcoded restrictions are for safety, preventing illegal movement or breaking an effect entirely, but keeping these unrestricted effects behind the PAL 23 wall would both prevent legacy maps from breaking, and signal a caveat emptor to mappers using them.

brullov, on 17 August 2022 - 06:21 PM, said:

My proposals about enemies aren't worth it, so let's not focus on them that much. I hope more customizable trains and sprite doors won't slip among my not clever ideas.

re: Two-way trains with curves (or put another way, non-looping / two-way subway trains), I haven't looked at the engine source for these effects but I wonder if this might be feasible as a branch of subway trains rather than the two-way trains. Also I don't know if this would be more logical as a new SE number. Also also, trying to make them compatible with SE 14 cars probably would be a huge pain in the ass. I can take a look but won't have time to experiment until after we release AWOL.

[brullov]

[oasiz]

Reaper_Man, on 18 August 2022 - 06:23 AM, said:

re: Two-way trains with curves (or put another way, non-looping / two-way subway trains), I haven't looked at the engine source for these effects but I wonder if this might be feasible as a branch of subway trains rather than the two-way trains. Also I don't know if this would be more logical as a new SE number. Also also, trying to make them compatible with SE 14 cars probably would be a huge pain in the ass. I can take a look but won't have time to experiment until after we release AWOL.

I think the problem is mainly that subway trains beeline "ahead" and don't have a support for reversing without actually turning around completely.
But yes, a freely x/y movable sector is one of the "holy grails" in duke mapping since there is practically nothing to work with there.

One possibility here would be to flag the rotation away, this way you end up with a x/y sector that can move around freely (imagine a x/y moving platform + bottomless pit)

Reaper_Man, on 18 August 2022 - 06:23 AM, said:

Since this is it's own thread now I wanted to reiterate in case it was lost as conversation.
There's a handful of various ST and SE behaviors with hardcoded sounds, speeds, etc. that would be great if mappers could take control of. I know some of these hardcoded restrictions are for safety, preventing illegal movement or breaking an effect entirely, but keeping these unrestricted effects behind the PAL 23 wall would both prevent legacy maps from breaking, and signal a caveat emptor to mappers using them.

It seems like sounds/speed options were added later at duke dev in the first place. Check that september/95 video and most doors and elevators still play the same activation sound heard all the way back in lameduke. In LD it even baked in sound/autoclose/speed, much like Doom.
All instances of explosions also seem to have this, this is why the drill and SE130 are likely silent with it's explosions on retail (although explosion itself is less of sector effect).
There are some restrictions that are more of a result of the code itself, like co-existance.
When a map is loaded, some things get processed there and then. A sector .extra for example might be used to store speed/distance/delay for various effects, meaning that another effect co-existing in the same space gets affected (This is how you can slow down rotation with dropfloor + rotate sector as dropfloor uses it for delay and rotation uses it for speed).

It would be nice to have things like a remote toggle gpspeed I guess where you could just say "bam!" with a button and it would either set the .extra value to something new or raise/lower to a set value/relative offfset.

I have a bunch of ideas what can work though... With Fury I'm already practically stabbing the map struct directly with the effect set we have so I have a somewhat decent understanding on how far some things can be taken.
Like this for example.. The few x/y moving platforms we have are actually SE0 rotation but we offset the pivot sprite in code, this causes a side effect where the engine gets worried and re-offsets the whole sector to that new pivot location.
It's essentially abusing a 1 rotation speed sector (gets rounded out to 0 in practice) and the engine takes care of the rest like interpolation and such.
There are a lot of weird edge cases for effects if you just give mappers more control with the existing stuff

[Reaper_Man]

Regarding rotation for hypothetical two-way subways, I guess it really depends on what mappers would intend or expect this effect to function. As you said, a rotationless multi-stop moving sector (like two-way trains) would be significantly easier to implement than a literal "reverse SE6 subway train" that turns through corners in reverse when going backwards.

Is there any documentation on how a sector's properties that you're mentioning (.extra, etc.) alter the SE/ST effects?

[oasiz]

Reaper_Man, on 19 August 2022 - 07:02 AM, said:

Is there any documentation on how a sector's properties that you're mentioning (.extra, etc.) alter the SE/ST effects?

"lol, read the source"
But more seriously, some effectors use xvel internally, some use .extra of sector[] or sprite[].
I would recommend checking through actors.cpp (search for SE_0), you should land on a nice switch-case kaboodle that will give you some clues.
For sector, sectors.cpp and search for ST_1 (or ST_numberhere) and you'll land on one.

i.e. the simplest case for SE_29_WAVES would be to apply the Z to ceilingz/floorz conditionally, it's that simple of a change away.

All are pretty neatly done there and mostly premap/etc.. might have some info on setup for certain cases.

For the most part, things are consistently inconsistent.
SE sprites also have their own 40 byte (10x4b) "temp" struct for storing internal stuff typically.

Another example I believe would be slidedoor that uses sector.extra to determine distance and xvel=16 for the speed itself (likely 16 unit increments per tick)