[Fox]

First of all, I have a question: how I am supposed to check if the ID of an player is valid? Something like sprite[].statnum MAXSTATUS but for a player...

Also I had like to request an orientation bit for "texture repeat", which would have the following effect:

[Hendricks266]

...You want us to add a flag to enable a bug that does not exist in the first place? I can understand aiming for accuracy in Resurgence, but this is going off the deep end.

Give us an example of an actual good reason to add this and then we'll think about it.

[Danukem]

Fox, on 27 July 2012 - 10:07 PM, said:

First of all, I have a question: how I am supposed to check if the ID of an player is valid? Something like sprite[].statnum MAXSTATUS but for a player...

Are you talking about the player ID, or the sprite ID of the player sprite? If you are talking about the player ID, then it will always be 0 in a single player game, and it will never be greater than the maximum number of players in a multiplayer game.

[Fox]

Hendricks266, on 28 July 2012 - 01:36 AM, said:

...You want us to add a flag to enable a bug that does not exist in the first place? I can understand aiming for accuracy in Resurgence, but this is going off the deep end.

Give us an example of an actual good reason to add this and then we'll think about it.

Huh? This has nothing to do with Resurgence (and I don't think Duke 64 render the bleeding of tiles like that).

I want it for drawing repeat patterns, which I eventually used for other projects like this:

[Micky C]

Can we put in spotlights that don't cast shadows yet? Is it in the works?

[Hendricks266]

Fox, on 28 July 2012 - 10:50 AM, said:

I want it for drawing repeat patterns, which I eventually used for other projects like this:

Ah, now that is a valid reason. Sorry about the confusion, the messed up pistol sprite threw me off. This would require engine code. IIRC, sprites are specifically coded to avoid the circular blending behavior.

[Plagman]

Rotatesprite already has a bit to set repeating, IIRC.

[Fox]

Which one?

[Reaper_Man]

Just gonna leave this here.

http://www.altdevblo...-native-client/
https://developers.g.../native-client/

[Fox]

I got an issue with a non-functioning SE in Eduke32. For some reason, the blue access card elevator in Spaceport map extracted from the Nintendo 64 ROM does not work, and it won't "teleport" you to the other point.

The map works fine with DOS version of Duke 3D. And if you copy the sectors on a new map it works just fine, meaning it has something to do with a superfluous component of the sector / wall structure (such as firstwall for example).

Attached File(s)

•  spaceport64.zip (31.95K)
  Number of downloads: 721

[Helixhorned]

Fox, on 04 August 2012 - 05:51 AM, said:

I got an issue with a non-functioning SE in Eduke32. For some reason, the blue access card elevator in Spaceport map extracted from the Nintendo 64 ROM does not work, and it won't "teleport" you to the other point.

The map works fine with DOS version of Duke 3D. And if you copy the sectors on a new map it works just fine, meaning it has something to do with a superfluous component of the sector / wall structure (such as firstwall for example).

This is one of those wacky cases where the behavior depends on the particular order of sprite indices (the most famous example probably being the order in which the cameras are cycled each time you "use" a viewscreen). Here's what happens: the warping elevator SE in sector 3 needs to determine when it can teleport the player and sprites contained in it to its matching sector. This is the case when no "hole" is visible from it any more. But the fake ceiling door, sector 178, is immediately adjacent to it! If its spawn-time code executes before the warp-elevator's one, the "door" will be closed and an engine function searching for the "next z step" fails. This is exactly what happens with the extracted map and EDuke32. Now, when you highlight the whole map from Mapster32 and copy it to a new one, currently the sprite index order is changed in general, and with this quasi-duplicated map, the SE17 runs first.^[*] So why does it work with the DOS or N64 version? I don't know for sure, but the two most natural possibilities are

• The order in which the two SEs run is reversed because of different order in which the code is run between EDuke32 and DOS/N64. I haven't compared the original DOS source with ours, but I'm leaning more to assume that they're functionally identical in this respect.
  
• That it works in DOS/N64 is coincidence. Currently, I have made EDuke32 terminate the the extracted level since, as noted above, the "find next z step" function fails, and moreover the resulting (invalid) sector index -1 was used to access the sector array, which is undefined behavior.

^[*]Side note: I screwed up with copy-pasting. Before r2965, some sector and wall members which are used for TROR functionality would get reset, regardless of whether the source or destination map had any TROR. Now, the bug still persists if the portion to be duplicated contains TROR, but I think its fix has to wait until the new map format.

[Fox]

Am I the only one who have a problem with hard-coded polymer lights in Eduke32? The developers are against using new art, but they are okay with these lights?

I know you can remove them through CON with some effort. But I believe they should come in a CON patch with HRP or something.

[Hendricks266]

It's not too hard for modders to account for it. I would have to say that it's better to include hardcoded lights because they are not really the addition of any other resources. SW's palswaps are stored in the source code. Plus, you would not have noobs whining why the Polymer checkbox only serves to make the game slower. On the other hand, it wouldn't cause the misinformed masses to think EDuke32=HRP and edit the Duke 3D Wikipedia article to say that xDuke and hDuke keep the original look of the game while EDuke32's updated graphics using OpenGL have high performance requirements that do not work on many computers.

[Fox]

Hendricks266, on 21 September 2012 - 04:01 PM, said:

I would have to say that it's better to include hardcoded lights because they are not really the addition of any other resources. SW's palswaps are stored in the source code.

They are. What are these RGB values based on? Who says that the Expander must emit orange light, and not red? Why the light of some explosions expand with the animation and others don't?

[necroslut]

The hardcoded lights should at the very least come with an option to switch them off. They're just way too big and as they shine through walls they give away secrets (the old "switch in the wall" trick), and fuck up countless of old of mods where tiles has been changed into something else, such as a green-glowing M16 or a switch without diods shining green/red.
I too find it a bit odd that while other features are rejected because it would harm compability, this thing seems to be fine with everyone.

[Fox]

I nocited that some actors run EVENT_ANIMATESPRITES in multiple instances (to make shadows, for example). If it was possible to control such feature, we could create effects such as mirrors in the floor, etc.

[Hendricks266]

What do you mean by control?

[Fox]

I don't know exactly how it could be done. Perhaps setting RETURN to 1 would force it to draw the sprite a second time?

[Hendricks266]

The issue with that would be that it would be easy to make an infinite recursion.

[Mblackwell]

Hendricks266, on 29 September 2012 - 04:55 PM, said:

The issue with that would be that it would be easy to make an infinite recursion.

The only way I could think of would be to add a new member that counts down if non-zero. Said member being the number of draws. ANIMATESPRITES would then let you check the value of this member to determine what you do with the extra draw (cancel it, alter it, etc).

It's really not a perfect solution however. And it definitely wouldn't really be useful in creating the effect you want (a mirror floor). The effect you want would be the ability to flip showviewunbiased (player's current view with y inverted) and then display it using DISPLAYROOMS and making the floor transparent. Currently not possible afaik however.

Really it's the kind of thing that should be done in the engine though.

[Fox]

Yeah, I guess if you could mirror horizontally or vertically (or even rotate) showview it would be possible to do any form of reflection.

Edit: I got a particular conflict... now we can change the current menu being displayed, so I can bypass the episode select screen. Buuut it became impossible to select a User Map. Would it be too much to ask to move the User Map option to the main menu?

[Hendricks266]

Fox, on 29 September 2012 - 05:59 PM, said:

Edit: I got a particular conflict... now we can change the current menu being displayed, so I can bypass the episode select screen.

Wait, how did you do that?

[Fox]

Primarily using this:

ifvare current_menu 100
  cmenu 110

[Hendricks266]

Where does that code go?

[Fox]

I think it was in EVENT_DISPLAYMENU?

[High Treason]

I spent over an hour modifying the source code to achieve the same thing.

Probably still will as I want to force E4L1 but that can likely be done from CON, but I do wonder if anything else can be manipulated in this fashion...

Edit: Incidentally, if you really want the user-map thing, could you not, say, get .bits in event_processinput and then in displaymenu ifvarand a key (U, for example) to cmenu 102 so that pressing this key whilst in the menu brings up the User Map menu?

[Hendricks266]

That's not how bits works. The input structure is currently limited to game functions, not raw input. I have been thinking of exposing raw input to CON because you need it to properly replicate EVENT_DISPLAYCROSSHAIR on the Wii from CON.

[Mblackwell]

You could always access the usermap menu from the console by setting a global var which then triggers the menu to display.

[Hendricks266]

The console has a "cmenu" command too.

[Blue Lightning]

Where might a player find the newest Eduke 32?