EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#4111 Posted 09 December 2013 - 12:44 PM
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?
#4113 Posted 09 December 2013 - 03:48 PM
#4115 Posted 11 December 2013 - 01:29 PM
Edit: it does not matter whether ART mapping is enabled or not.
#4116 Posted 11 December 2013 - 03:37 PM
#4117 Posted 11 December 2013 - 03:52 PM
#4118 Posted 11 December 2013 - 06:16 PM
That would make it possible to make new switches, lights, etc.
#4121 Posted 12 December 2013 - 12:21 AM
#4122 Posted 12 December 2013 - 03:13 AM
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.
#4123 Posted 12 December 2013 - 04:01 AM
#4124 Posted 14 December 2013 - 03:41 AM
Fox, on 11 December 2013 - 06:16 PM, said:
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:
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.
#4125 Posted 17 December 2013 - 08:42 AM
Edit: I got a small problem, masked floor / ceiling textures are not working outside of ROR (but it is for transparency).
This post has been edited by Fox: 17 December 2013 - 08:53 AM
#4126 Posted 17 December 2013 - 10:24 AM
Fox, on 17 December 2013 - 08:42 AM, said:
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
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.
#4128 Posted 17 December 2013 - 12:01 PM
Fox, on 17 December 2013 - 11:48 AM, said:
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 .
#4129 Posted 17 December 2013 - 08:45 PM
#4130 Posted 20 December 2013 - 10:48 AM
r4206 said:
Also add test/damagehplane.lua with these demonstrations:
- custom breakable ceilings
- breakable TROR glass
#4131 Posted 20 December 2013 - 04:21 PM
#4132 Posted 21 December 2013 - 04:07 AM
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.
#4133 Posted 22 December 2013 - 05:02 AM
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...
This post has been edited by MetHy: 22 December 2013 - 05:03 AM
#4134 Posted 22 December 2013 - 10:59 AM
MetHy, on 22 December 2013 - 05:02 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.
#4135 Posted 22 December 2013 - 12:19 PM
I suppose you could add a tag for each skill setting using the lo-tag as a bitfield.
This post has been edited by Fox: 22 December 2013 - 12:21 PM
#4136 Posted 22 December 2013 - 01:16 PM
Helixhorned, on 22 December 2013 - 10:59 AM, said:
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.
#4137 Posted 22 December 2013 - 01:45 PM
This post has been edited by MetHy: 22 December 2013 - 01:46 PM
#4138 Posted 22 December 2013 - 03:03 PM
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...
This post has been edited by Fox: 22 December 2013 - 03:08 PM
#4139 Posted 22 December 2013 - 03:06 PM
#4140 Posted 23 December 2013 - 06:47 AM
MetHy, on 22 December 2013 - 01:45 PM, said:
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.