[Scott_AW]

I noticed in Windows 8, classic render no longer seems to be supported. Which means the tricks I used to the voxel models (setting them as floor sprites to reduce clipping) need to be undone for it to run right in the 16bit+ renderers.

I'm sure I could have this fixed in CON, setting the models back to simple sprites, since they don't convert to models if they are a wall or floor sprite.

Thankfully I'm using more sprites in this one, so converting the voxel things to models in polymost/polymer isn't so bad.

That being said, anyone know if you can force 8bit mode to work in Windows 8?

[TerminX]

Sure sounds like you're using an older build...

[Scott_AW]

Maybe, I also had to run things through a shortcut because windows 8 hates Bat files now. I'll have to get the most recent version and test it on Win8 to see.

[The Commander]

Your version of Windows 8 must be wack, I have no issues.

[Helixhorned]

Polymer lights with tile projections display the pink background color where it should be see-through. I think that's a regression, but I didn't bisect anything yet.
Edit: it does not matter whether ART mapping is enabled or not.

[Micky C]

I remember seeing that a few weeks ago, and when I was a certain distance away the pink went away like it should. It's only when you're close that the pink is there. Either way it should be fixed I suppose.

[Mark]

I'm pretty sure the purple was there in 4039 that I recently updated from.

[Fox]

Is it possible to include an dynamicremap-like command, but that makes a tilenum inherit the behavior of another? From a technical side, it would basically makes the game assume that one tilenum is another for condition checks in the source code.

That would make it possible to make new switches, lights, etc.

[Hendricks266]

EVENT_ANIMATESPRITES

[Fox]

Lights = sprites?

[Jblade]

A way of adding new light sprites would be very handy, yeah. I thought of a few ways to do it, one of them being placing a sprite at level load-time infront of certain textures that'll change it if hit by a weapon. That seems a bit crude, but I'm not sure how the hardcoded walls handle destruction.

[High Treason]

I always went with using plain old SE's for manipulating lights.

onevent EVENT_GAME
ifactor SECTOREFFECTOR  {
  ifvare LOTAG 49 {
	do some stuff
}
}
endevent

Of course assumes vars and event_loadactor code.

Usually using xrepeat/yrepeat or angle as a means of inputting something. You could be really elaborate and use the hitag to link it to a new SE coded in CON which would then control the light (change color, rotate, flicker) after IDs stored in an array or something allowing it to change the HITAG to the desired value(s) once the game is running (this would be done according to a value in a new SE) - the only thing I had trouble making them do was follow other sprites around outside of setting X, Y and Z because I could never figure out the math to offset it properly so it wouldn't end up sat inside the model it was following.

Forgive my tired ramblings, haven't had much sleep the past few days.

[Jblade]

I mean lights as in textures, like the default Duke ones that you shoot and get destroyed.

[Helixhorned]

 Fox, on 11 December 2013 - 06:16 PM, said:

Is it possible to include an dynamicremap-like command, but that makes a tilenum inherit the behavior of another? From a technical side, it would basically makes the game assume that one tilenum is another for condition checks in the source code.That would make it possible to make new switches, lights, etc.

That's an interesting request, but one without a catch-all solution that's possible to codify in a single command. Take the example of breakable lights. One of the occurences of their logic is in Sect_DamageCeiling():

int32_t Sect_DamageCeiling(int32_t sn)
{
    int32_t i, j;

    switch (DYNAMICTILEMAP(sector[sn].ceilingpicnum))
    {
    case WALLLIGHT1__STATIC:
// (...)
    case TECHLIGHT4__STATIC:

        A_SpawnCeilingGlass(g_player[myconnectindex].ps->i,sn,10);
        A_PlaySound(GLASS_BREAKING,g_player[screenpeek].ps->i);

        if (sector[sn].ceilingpicnum == WALLLIGHT1)
            sector[sn].ceilingpicnum = WALLLIGHTBUST1;
// (...)
        if (sector[sn].ceilingpicnum == TECHLIGHT4)
            sector[sn].ceilingpicnum = TECHLIGHTBUST4;

// [handle SE12]
// [handle SE3]

So right now, you have a "hard-coded" (only possible to remap with dynamicremap) set of tiles with that behavior. Generalizing that to allow adding user-defined ones could proceed by in various ways:

- Allow specifying the relevant data either with a CON or DEF directive, say "definebreaklight <basetilenum> <brokentilenum>". The so-defined list then has the character of game resources (it's invariant during a game).
- Hook into the C code using a new CON event, say EVENT_GETBREAKTILENUM.

On one hand, this shows that your original request is unrealstic: hard-coded features are scattered all throughout the source and have to be tackled separately. Furthermode, there's the ever-recurring issue of which level of generality you want to operate at. The new feature would make moddable some previously hard-coded aspect. But suppose that later, you want to expose to scripting a concept that encompasses that one...

 Hendricks266, on 11 December 2013 - 09:48 PM, said:

EVENT_ANIMATESPRITES

That's a local ("unsynchronized") event whose main use is to change the display of sprites on the screen. It must not be used to alter game state.

[Fox]

Is it possible to include a command that returns the position of a sprite in the screen? I have been trying to do it myself (screenshot), but it's difficult with the nuances of each rendering mode, plus there is the varying aspect ratio. Preferably making it work by providing the x-y-z of the camera and x-y-z of whatever you want to check the position in relation to the screen, and returning the value shifted by 16.

Edit: I got a small problem, masked floor / ceiling textures are not working outside of ROR (but it is for transparency).

[Helixhorned]

 Fox, on 17 December 2013 - 08:42 AM, said:

Is it possible to include a command that returns the position of a sprite in the screen? I have been trying to do it myself (screenshot), but it's difficult with the nuances of each rendering mode, plus there is the varying aspect ratio. Preferably making it work by providing the x-y-z of the camera and x-y-z of whatever you want to check the position in relation to the screen, and returning the value shifted by 16.

I agree that the scripting system should expose such a function because there are many variables by which rendering is affected, like you say. Doing that for classic should be easy -- the calculation from {world position, ang, horiz} of the camera and the position of the target to screen position is explicit in the code. For the GL modes, it's not so straightforward.

I'm not very interested in evolving CON though, a language that lacks even basic structured programming concepts like argument passing.

Quote

Edit: I got a small problem, masked floor / ceiling textures are not working outside of ROR (but it is for transparency).

How are they supposed to operate when there's nothing above/below them? Translucent ceilings/floors without TROR neighbors "correctly" result in a HOM effect.

[Fox]

I use it with showview command.

[Helixhorned]

 Fox, on 17 December 2013 - 11:48 AM, said:

I use it with showview command.

I meant, what is the behavior that you expect? When reporting a supposed bug, that's an important piece of information to cross-check whether it's a real bug or a misunderstanding on the part of the reporter .

[Fox]

I expect the hall of mirrors you mentioned, which I can use to my advantage.

[Helixhorned]

r4206 said:

Scripting: Add EVENT_DAMAGEHPLANE and document it in Lunatic doc Appendix B.

Also add test/damagehplane.lua with these demonstrations:
- custom breakable ceilings
- breakable TROR glass

[Micky C]

Cool, is the breakable TROR glass in the vanilla game now or is that a demonstration of a lua mod?

[Helixhorned]

It's mainly a demonstration of what's possible with the new event. While it's already perfectly usable for inclusion into mods (well, apart from the fact that it uses the soon-to-be-removed 'con._sound'), I agree that it should be somehow more integrated into vanilla EDuke32.

An option would be to provide a stadard "effect extensions" library of sorts. The individual effects would be toggleable via command-line switches -- or, if such a system is ever devised, put as additional information into map-text files. An issue with this is that you'd want to make it parametrizable. For example, the code in damagehplane.lua currently considers both tile 198 and GLASS2 hplanes as 'breakable', but you may want to have it only for one (they look the same as far as I can tell), or add other tiles. From Lua code, parametrization can be had at module 'require' time, if the module itself is written to accept the additional information.

My local tree also contains a change that makes it possible to chain DAMAGEHPLANE events, i.e. define separate parts as modules.

I suggest this discussion to be continued in the Lunatic thread. There's much potential for brainstorming, and everyone can be part of that.

[MetHy]

Couldn't find an eduke32 request thread so I'll ask here.

in Doom, one can decide if ANY sprite will appear or not depending on the difficulty settings. In Duke, you can only decide that for enemies (and ammo and health items I think? I don't even know). Do you think it'd be possible to add a feature so that one can decide if ANY sprite appears or not depending on the difficulty? I'm sure it could be useful, like, image a platforming segment, in easy you'd be able to add a platform to help the player for that segment...

[Helixhorned]

MetHy, on 22 December 2013 - 05:02 AM, said:

Do you think it'd be possible to add a feature so that one can decide if ANY sprite appears or not depending on the difficulty?

That's easily accomplished with CON's eventloadactor or EVENT_LOADACTOR. You'd only need to research a bit whether the tag you want to put the skill into isn't used in other (hard-coded or CON, if applicable) effects.

[Fox]

At least in the original source code these are the sprites which skill settings apply to:

Spoiler

TRIPBOMB
OCTABRAINSTAYPUT
LIZTROOPSTAYPUT
PIGCOPSTAYPUT
LIZMANSTAYPUT
BOSS1STAYPUT
PIGCOPDIVE
COMMANDERSTAYPUT
BOSS4STAYPUT
BOSS1
BOSS2
BOSS3
BOSS4
ROTATEGUN
GREENSLIME
DRONE
LIZTROOPONTOILET
LIZTROOPJUSTSIT
LIZTROOPSHOOT
LIZTROOPJETPACK
LIZTROOPDUCKING
LIZTROOPRUNNING
LIZTROOP
OCTABRAIN
COMMANDER
PIGCOP
LIZMAN
LIZMANSPITTING
LIZMANFEEDING
LIZMANJUMP
ORGANTIC
RAT
SHARK
RECON
ATOMICHEALTH
STEROIDS
HEATSENSOR
SHIELD
AIRTANK
TRIPBOMBSPRITE
JETPACK
HOLODUKE
FIRSTGUNSPRITE
CHAINGUNSPRITE
SHOTGUNSPRITE
RPGSPRITE
SHRINKERSPRITE
FREEZESPRITE
DEVISTATORSPRITE
SHOTGUNAMMO
FREEZEAMMO
HBOMBAMMO
CRYSTALAMMO
GROWAMMO
BATTERYAMMO
DEVISTATORAMMO
RPGAMMO
BOOTS
AMMO
AMMOLOTS
COLA
FIRSTAID
SIXPAK

I suppose you could add a tag for each skill setting using the lo-tag as a bitfield.

[Daedolon]

Helixhorned, on 22 December 2013 - 10:59 AM, said:

That's easily accomplished with CON's eventloadactor or EVENT_LOADACTOR. You'd only need to research a bit whether the tag you want to put the skill into isn't used in other (hard-coded or CON, if applicable) effects.

I think he speaks mainly as a mapper, not a modder.

For MetHy: I think it should be possible to make the additional platforms destructible and have some kind of skill level controlled explosions (somehow, I think I could find a way) to blow them up before the player gets to them.

[MetHy]

Well it was just an example. I was just thinking such an in-built feature could be interesting. For example in E1M3 in Doom they use it to add "lamp" sprites in a pitch dark corridor to guide the player through in easier difficulties.

[Fox]

Would it be posible to separates the shade and fog colors? I feel like using the same color for both is very limitating, especially for realistic environments. I am not 100% sure, but as far I know it would be technically possible with the way lookup palette works.

I also would like to request the ability to have a black fog (0, 0, 0) that uses a shade table generated by the engine. Otherwise I am forced to have a shade table with the same shade values as Duke 3D palette files...

[MusicallyInspired]

Oooooohhh maps that have varying methods of completion based on difficulty would be AWESOME! Replay value would be sweet and would actually encourage people to try other difficulty levels that they're not used to. You'd have to figure out how to beat a level all over again!

[Helixhorned]

 MetHy, on 22 December 2013 - 01:45 PM, said:

I was just thinking such an in-built feature could be interesting.

Hard-coding such functionality may entail backward compatibility issues. Suppose the interface is "for every sprite with zvel >= 1 and zvel <= 4, that number is checked against the skill". While to my knowledge, zvel is never used as a tag in vanilla Duke, large mods such as WGR2 definitely use all available sprite members for custom effects. To combat that, you could make that behavior conditional to only a few selected tile numbers, but who's to decide which ones those are? Doing that in a CON mutator in a whitelist approach is the only sensible option.

It's understandable to not want to include custom CONs with a map though. The traditional approach of some maps to ship modified {GAME,USER,DEFS}.CON files is inadequate: it forces the user to either copy them to the game directory and delete them afterwards (clumsy) or provide the root one at the command line (which Windows users shy away from). Mutators are definitely preferred, but also suffer from the increased "installation" complexity.

So... what I'm thinking about is to enable auto-loadable CON or Lua mutators on a per-map basis, like already there for some other file types such as music. That should be doable in the Lunatic build, since the Lua state is recreated with each new game.