[Helixhorned]

Fox, on 28 December 2014 - 10:50 AM, said:

SMOOTHMOVE works, NODAMAGEPUSH not.

You mean with the exact example I posted or some other case? For the former: works fine here. For the latter: I'd have to see the code, and potentially some context like the order in which useractor and sprite* directives appear. LunaCON warns you if you violate the rule stated earlier. (Except that it considers actor but not precache -- might need to fix that.)

[Fox]

I am using C-CON.

Edit: When you end the episode, the blocking of sounds continues in the main menu. (my mistake)

Attached File(s)

•  EDUKE.CON (78bytes)
  Number of downloads: 334

[Helixhorned]

Fox, on 28 December 2014 - 11:26 AM, said:

I am using C-CON.

I understand that you're mainly or exclusively using C-CON for development and testing. I merely suggested to at least look at the CON translation log with LunaCON, as it may give you hints of erratic behavior for running the same code under C-CON. LunaCON is stricter, and that's a good thing.

You posted the same code snippet as I, from which you meant to say that that one didn't work for you in a vanilla environment? I dunno... the NEWBEAST just fails to be pushed away by a continuous burst of chaingun fire for me, from which I conclude that NODAMAGEPUSH works. In which way does it fail to work for you?

EDIT: Just to be clear, that snippet is supposed to be used as root CON file, like this:

eduke32 -v1 -l1 ndp.con

and not as a mutator.

[Fox]

Hit it with an RPG.

[Hendricks266]

Fox, on 28 December 2014 - 11:26 AM, said:

Edit: When you end the episode, the blocking of sounds continues in the main menu.

I don't understand.

[darkprince227]

I've just tested the new build and the cutscenes now work beautifully, thanks Hendricks (and all the others involved, of course)

Also, there seems to be this litle problem with the User maps menu----



I'm very sure it shouldn't be like that.

Also, the polymost override and Z-pack addons get totally cancelled out, maybe I should tell LeoD about this though.

Anyway, keep up the good work, you guys are the best!

[Hendricks266]

darkprince227, on 28 December 2014 - 12:26 PM, said:

Also, there seems to be this litle problem with the User maps menu----

duke0006.png

I'm very sure it shouldn't be like that.

I don't understand what you think is the problem. Also, that is not a screenshot from the most recent build.

[darkprince227]

Hendricks266, on 28 December 2014 - 12:35 PM, said:

I don't understand what you think is the problem. Also, that is not a screenshot from the most recent build.

Sorry, wrong picture Here it is....



Is the background square supposed to be completely black? because didn't it used to be transparent?

[Hendricks266]

It's intended, yes, though I agree that the translucent background looked better. I'll make it translucent again once I extend rotatesprite (internally) to take crop parameters, which I'll need to do anyway to make TX happy with how lines of text disappear when scrolled off the top or bottom of a scrolling region.

[darkprince227]

Cheers, Hendricks

By the way, I love the new sliding menu thing. Nice touch

[Helixhorned]

Fox, on 28 December 2014 - 12:06 PM, said:

Hit it with an RPG.

r4863 said:

actors.c: replace hard-coded list with missing check for SFLAG_NODAMAGEPUSH.

In A_RadiusDamage(). The code snippet that is disabled for such actors
increases the damaged actor's .xvel by (4 times the) damage amount and
is responsible for the strange effect of enemies becoming faster TOWARDS
the player on being hit with an RPG frontally.

Thanks to Fox for a keen eye.

[Fox]

Hendricks266, on 28 December 2014 - 12:45 PM, said:

It's intended, yes, though I agree that the translucent background looked better. I'll make it translucent again once I extend rotatesprite (internally) to take crop parameters, which I'll need to do anyway to make TX happy with how lines of text disappear when scrolled off the top or bottom of a scrolling region.

Just leave the text without black boxes, translucent or not. If you are worried about mods that use custom backgrounds, use a separate background like the Save/Load menus.

[Helixhorned]

Fox, on 28 December 2014 - 01:02 PM, said:

Just leave the text without black boxes, translucent or not. If you are worried about mods that use custom backgrounds, use a separate background like the Save/Load menus.

IMO a translucent black background looks classy. I'm biased though, since I originally implemented it in order to prevent a scene drawn underneath rendering the text unreadable.

[Hendricks266]

Helixhorned, on 28 December 2014 - 01:13 PM, said:

IMO a translucent black background looks classy.

Agreed. I had to replace the xdim/ydim-based cropping of the tile with M_BlackRectangle() so that it would animate properly, and I had to disable the translucency because the patchwork displayed multiple layers of the tile in certain places.

[Fox]

The mouse cursor is cropped at the bottom of the screen if the full status bar is visible.

[LeoD]

Roma Loom, on 02 December 2014 - 11:38 PM, said:

Is it just me or loading a savegame doesn't load maphacked polymer light sources?

Roma, does your problem persist?

Helixhorned, on 15 December 2014 - 12:15 PM, said:

For a simple test -- saving E1L1 on Polymer+HRP and loading from a just started EDuke32 instance -- everything works as expected for me. However, that doesn't exclude the possibility of failure for more complicated usage paths. Map hack light info is not stored in the savegame itself. Rather, the file map name stored in the savegame is used to construct that of a .mhk file (by replacing .map with .mhk) and that one is attempted to be loaded. So, if there's a discrepancy of what EDuke32 sees as its virtual file system between when the savegame was made and at load time, issues can arise.

Helix, could you save the relative (virtual FS) path of the loaded MHK separately? This would be an important first step into actually implementing the UserMapHack system...

darkprince227, on 28 December 2014 - 12:26 PM, said:

Also, the polymost override and Z-pack addons get totally cancelled out, maybe I should tell LeoD about this though.

Delete textures, textures.cache and retry. Post your eduke32.log in the Z-Pack thread if the problem persists. Btw, I actually stick to r4495 (synthesis 4488) for daily usage. As far as I'm concerned all later versions are broken in one way or the other, on one hardware or the other.

[Hendricks266]

Fox, on 28 December 2014 - 01:51 PM, said:

The mouse cursor is cropped at the bottom of the screen if the full status bar is visible.

I don't have this issue with the latest synthesis.

[Fox]

Is it possible to add an .htflags so enemies are not eaten by Protozoid Slimers like the bosses?

[Diaz]

It's been a while since I last worked on my EDuke32 stuff, and when I returned I noticed some changes:

First of all, the enemy palette issue is fixed, thanks Helixhorned.

Second, Polymer performance seems much, much worse now - maybe some added extra stuff that needs to be turned off?

Third, I had coded some actors to get the floor shade instead of the ceiling shade when under a parallaxed sky. That code doesn't work anymore and the ceiling shade is being applied, which I don't want.

More reports as I keep testing...

[Helixhorned]

Diaz, on 30 December 2014 - 04:01 AM, said:

Third, I had coded some actors to get the floor shade instead of the ceiling shade when under a parallaxed sky. That code doesn't work anymore and the ceiling shade is being applied, which I don't want.

If you wish to change displayed sprite shade, there are two viable options. G_DoSpriteAnimation() will set the tsprite's shade to that of the ceiling or floor unconditionally, unless the corresponding actor has SFLAG_NOSHADE set, or the sprite CSTAT_SPRITE_NOSHADE ([N] from Mapster32).

This means that the options are:

1) to set any of these bits on the sprite. Then, sprite[].shade can be changed and will be taken over to the tsprite.

2) modifiy the tsprite's shade in EVENT_ANIMATESPRITES. Example:

gamevar tmp 0 0
 
state setup_animatesprites
    ifactor LIZTROOP
    {
        getactor[THISACTOR].mdflags tmp
        orvar tmp 16
        setactor[THISACTOR].mdflags tmp
    }
ends

onevent EVENT_EGS
    state setup_animatesprites
endevent

onevent EVENT_LOADACTOR
    state setup_animatesprites
endevent

onevent EVENT_ANIMATESPRITES
    ifactor LIZTROOP
    {
        setvarvar tmp totalclock
        andvar tmp 255
        settspr[THISACTOR].tsprshade tmp
    }
endevent

I'm not sure which recent change might have affected your code in that regard. Could you post the relevant parts of it?

[Helixhorned]

LeoD, on 28 December 2014 - 02:30 PM, said:

Helix, could you save the relative (virtual FS) path of the loaded MHK separately? This would be an important first step into actually implementing the UserMapHack system...

What would the immediate gain be? If it's likely to be implemented as part of that system, why not wait for it to appear naturally?

Quote

Btw, I actually stick to r4495 (synthesis 4488) for daily usage. As far as I'm concerned all later versions are broken in one way or the other, on one hardware or the other.

Are these 'hard' issues like crashes or incorrect rendering? Which ones would be the most critical in your opinion?

[Hendricks266]

LeoD, on 28 December 2014 - 02:30 PM, said:

Helix, could you save the relative (virtual FS) path of the loaded MHK separately? This would be an important first step into actually implementing the UserMapHack system...

My to-do list goes like this:
Enhance some visual aspects of the new menus
UserMaphacks
[Other stuff for 64 and TM]
[Other stuff for Android]

[LeoD]

Helixhorned, on 30 December 2014 - 01:05 PM, said:

What would the immediate gain be? If it's likely to be implemented as part of that system, why not wait for it to appear naturally?

I don't trust nature, it may force me to do it on my own. And that part could be especially hard for me, as far as I can tell from thinking about an implementation concept.

Helixhorned, on 30 December 2014 - 01:05 PM, said:

Are these 'hard' issues like crashes or incorrect rendering? Which ones would be the most critical in your opinion?

I'm quite tolerant to rendering issues. But recently, crashes at startup or when leaving the game have sneaked in. Some of them seem hardware dependent. Sometimes it's the normal executable, sometimes it's the debug version.
I've kept telling myself that I'll hunt all those down once I've reached my mystic UserMapHack milestone, but it appears that I'm constantly about fifty maps away from it
Maybe I should take a break from that mostly comfortable task and switch to some painful bug hunting. (Spell check just offered me 'Hermaphroditus' for 'UserMapHack' )
Other than that, two annoying things reported back in June are still present:
- USE and left mouse click as confirmation/proceed action in save/load game menus and maybe elsewhere, too, do not work as in the DOS executable.
- Start the game, use the left mouse click only to proceed to the top menu. Use the mouse wheel to scroll down to LOAD GAME. Confirm with left mouse click. Use the mouse wheel to scroll to a used slot of your choice. Use left mouse click to load that savegame -> the selection jumps to the slot above.

Feature request: Please put basic information about the CPU into eduke32.log.

Hendricks266, on 30 December 2014 - 02:34 PM, said:

My to-do list goes like this:
Enhance some visual aspects of the new menus

Those side-scrolling menus are quite annoying on a wide screen.

Hendricks266, on 30 December 2014 - 02:34 PM, said:

My to-do list goes like this:
UserMaphacks

I was about to post this in the UserMapHacks thread totay:

Spoiler

Please implement the maphack tokens.

I tried to upvote, but my quota on this topic seems to be spent already.

[TerminX]

I have a theory that some of the crashes are somehow related to the keyboard layout switching. I feel like I've seen a couple of logs where there were duplicate messages about switching the layout (e.g one message for switching from a foreign layout to the US layout but more than one message about switching back), which shouldn't be possible. Maybe try manually setting your system keyboard layout to US before launching the game and see if that does anything...

[Micky C]

I've noticed that with the classic renderer, mapster seems to display overlapping sprites (sharing the same x-y coordinates) differently to eduke32, and in a superior and less glitchy way. I can provide example pics if needed, but is there anything that would explain this? Ideally whatever's going on with mapster can be moved over to eduke32 which should improve some things. I wonder if it has anything to do with Helix's modifying of stuff regarding sprites and masked walls a while back.

[Helixhorned]

Micky C, on 04 January 2015 - 03:46 AM, said:

I can provide example pics if needed

Please do.

[Micky C]

Ah the joy of avoiding spoilers.
Running both mapster and eduke from r4873.



Mapster, view-alligned sprite sharing x-y coords with a floor-alligned sprite. Perfection.


In-game, floor-alligned sprite gets drawn over the top one, including the lens flair sprite that's positioned higher up on the z axis (everything candle-related disappears completely when looking down enough).


Voxel in mapster. Uses a separate floor-alligned sprite as a shadow. So far so good.


In-game same thing as before, the floor-alligned sprite is drawn on-top. This happens both when the voxel is wall-alligned and view-alligned.
Edit: When the voxel is floor-alligned the shadow sprite starts to show through in mapster too, however less consistently than it does in-game (where it is drawn on top from all angles).

[TerminX]

Pretty sure that's related to my flawed attempts at fixing z fighting issues with wall and floor sprites. I have something that revises it in my tree that I'll commit soon.

[Helixhorned]

TerminX, on 04 January 2015 - 06:24 AM, said:

I have something that revises it in my tree that I'll commit soon.

Oh. Me too. I just removed that sort-by-statnum, which is not very meaningful. That's since Duke3D though, so maybe we're not conflicting?

Edit:

Quote

Pretty sure that's related to my flawed attempts at fixing z fighting issues with wall and floor sprites.

Ah, that was in polymost.c, so it looks like we shouldn't step on each other's toes. My changes are mostly in engine.c.

EDIT2: Congrats for deceiving me into initially thinking that the first one is a Polymer shot BTW, Micky!

[TerminX]

Helixhorned, on 04 January 2015 - 06:37 AM, said:

Oh. Me too. I just removed that sort-by-statnum, which is not very meaningful. That's since Duke3D though, so maybe we're not conflicting?

Edit:

Ah, that was in polymost.c, so it looks like we shouldn't step on each other's toes. My changes are mostly in engine.c.

I'd be careful removing that, I think I tried it once and ended up with oddities involving the sprites that spawn when shooting things.