[Hendricks266]

They will walk through water as long as their picnums are not the same as the default enemies.

[Mark]

Which they are for me. Oh well....

[Fox]

Well, you shouldn't have used hard-coded enemies as the base.

[Mblackwell]

Perhaps that kind of thing should be a flag if anything. It's kind of a weird behavior.

[Jblade]

Mouse buttons 4 and 5 aren't responding in the latest snapshots, but they work fine in a September build I have so I know it's not my mouse playing up.

[Hendricks266]

It's probably related to how SDL2 doesn't treat mouse wheel scrolling as buttons any more. We have code to compensate for that but perhaps there isn't any yet for mouse buttons beyond 3.

[blizzart]

I haven´t downloaded a synthesis build recently, so I want to ask, which of all these packages I have to download if I want to use the 64bit Eduke and Mapster? And where do I find the sample files?

Sorry, but it´s a little bit confusing to me...

[MusicallyInspired]

The synthesis builds now have 64-bit binaries as well as 32-bit. All the latest builds should have them listed along with the regular 32-bit.

[blizzart]

MusicallyInspired, on 08 December 2013 - 02:43 PM, said:

The synthesis builds now have 64-bit binaries as well as 32-bit. All the latest builds should have them listed along with the regular 32-bit.

Thanks for your reply,
so the EDuke32.exe files are for both 32- and 64-bit?

[Hendricks266]

eduke32_{arch}_{debug}
eduke32-sdk_{arch}_{debug}

"eduke32" contains EDuke32; "eduke32-sdk" contains Mapster32 and the samples folder.

{arch} will be "win32" for 32-bit and "win64" for 64-bit. Currently, classic performs better under 32-bit and Polymer performs better under 64-bit.

"debug" will be present in debug builds, and absent in release builds. Debug builds run slower and take up more space than a release build, but they contain extra information that can help us fix crashes if you encounter them and report them properly.

While you mention it, I need to make each synthesis build folder sort by name, not by date.

While you mention it, I need to redesign all of Dukeworld.

[Helixhorned]

necroslut, on 18 October 2013 - 04:12 AM, said:

Edit: I tried it on another computer and it's the same, Ralt does nothing. Changing the keyboard layout didn't help either.

Is this still an issue? It works for me on Windows 7, with both 32 and 64-bit builds, so maybe it's specific to the Windows version?

In the meantime, you could try mapping a different key to the RAlt functionality by adding to the "remap" option of mapster32.cfg. For example:

; make backslash function as RAlt
remap = 2B-B8

[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.