Duke4.net Forums: [RELEASE] EDuke32 Addon Compilation - Duke4.net Forums

Jump to content

  • 68 Pages +
  • « First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

[RELEASE] EDuke32 Addon Compilation  "Version 3.13 released on December 6, 2016!"

User is offline   Reaper_Man 

  • Once and Future King

#121

View PostNightFright, on 25 November 2015 - 11:49 AM, said:

I can provide you with the latest con file for Grins since I have removed some warnings in the meantime. Would save me some time if you managed to work with that one and add your fixes there.

I will give Grins another playthrough shot before Xmas, provided that a solution is found for that problem EDuke32 currently seems to have when applying sprite resize bug fixes.


Sure, go ahead and send them to me. My email is msleeper (at) gmail.

If I remember correctly, the first map is kind of a hassle because of the timer, but the rest aren't so bad.

What's the issue with resizing? I know we made the sprites gigantic and sized them down to preserve details, and even back in 2002 that caused some problems. Nowadays there's probably a better way of doing that, but it's been a minute since I've done any Eduke modding.
0

User is offline   Mblackwell 

  • Evil Overlord

#122

You were probably doing sizeat in the beginning of the actor code, but if the actor was asleep (for example an enemy out of player view, or a pickup sprite) you'll see the transition. In EDuke32 you can get around this by setting x/yrepeat in EVENT_LOADACTOR for those picnums.
0

User is online   NightFright 

  • The Truth is in here

#123

The thing right now is that my resizing fix code that I applied works, but for some reason EDuke32 adds dummies of the resized sprites randomly throughout the levels. No idea why this happens. I have already asked Hendricks to look into this matter and hope it gets solved before Xmas. Dunno if it's something in my fix code or EDuke32 itself, but I know that the patches I had written used to work at some point. However, by now I am unable to find any snapshot that actually does the trick, so it's kinda... complicated.

Maybe you can fix the problematic sprites while reviewing the con file, too. Then these fixes may not be necessary any more.

@Reaper:
You should have the con in your mailbox by now.

This post has been edited by NightFright: 25 November 2015 - 02:09 PM

0

User is offline   Danukem 

  • Duke Plus Developer

#124

View PostNightFright, on 25 November 2015 - 02:08 PM, said:

The thing right now is that my resizing fix code that I applied works, but for some reason EDuke32 adds dummies of the resized sprites randomly throughout the levels. No idea why this happens. I have already asked Hendricks to look into this matter and hope it gets solved before Xmas. Dunno if it's something in my fix code or EDuke32 itself, but I know that the patches I had written used to work at some point. However, by now I am unable to find any snapshot that actually does the trick, so it's kinda... complicated.

Maybe you can fix the problematic sprites while reviewing the con file, too. Then these fixes may not be necessary any more.

@Reaper:
You should have the con in your mailbox by now.


I have seen a lot of strange stuff over the years, but I have never seen EDuke32 randomly add tiles into a map. Since you describe them as "dummy" tiles, I'm guessing they are not the same picnum as the actor (i.e. they are uncoded tiles). Perhaps there is an art file that has a duplicate of the tile on a different tile number, and those sprites were already in the maps, but for some reason they were not being displayed before. They could have been intended as stayput versions of the actor, for example, but were never coded. If the tiles had 0 size and your code changed them to large size, or if they had a tag (such as for difficulty level) that got removed somehow, then that would account for it.
0

User is online   NightFright 

  • The Truth is in here

#125

The thing is that it happens in every single addon that has these fixes applied, so it doesn't look like a coincidence to me. What strongly contradicts the assumption that EDuke32 is to blame for it is that there isn't any snapshot where this issue doesn't show up. Still, I am pretty sure I haven't seen this problem when I released v1.0 of the compilation. One way or the other, it needs to be solved since it's a pretty annoying glitch. Maybe something is wrong with the way I inject the patch code, or even the patches themselves are flawed.

As an example, in "The Gate", it works like this:

The game is launched by using thegate.con which contains this code:
include BDEFS.CON
include BUSER.CON
include PATCHES.CON
include BGAME.CON
include BDP.CON


patches.con is loaded before the actual game.con code (bdp.con contains custom, mod-exclusive code) and looks like this:
// Disable ep.4 intro + Duke team outro
gamevar LOGO_FLAGS 1575167 0

// Sprite resize bugfix for Predator (4818 PREDATOR/4819 PREDSTAYPUT)
onevent EVENT_SPAWN
   switch sprite[THISACTOR].picnum
   case 4818
   case 4819
      setactor[THISACTOR].xrepeat 42
      setactor[THISACTOR].yrepeat 36
   break
   endswitch
endevent


The only relevant part is the sprite resize stuff at the bottom. The first time you notice the glitch is when you jump out of the window right to the bottom of the street. There is a "fake" Predator on top of a huge stone/rock/whatever thing blocking the street, doing nothing at all.

This post has been edited by NightFright: 26 November 2015 - 02:33 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#126

So what is the patch code? I am guessing that you are using code for more than just resizing sprites. If you are moving or copying tiles to different tile numbers in order to avoid conflicts between .art files, then lots of problems are possible, depending on how it's done.
0

User is online   NightFright 

  • The Truth is in here

#127

Actually, the code above is everything I am adding to what's already there. It definitely works because it avoids the Predators to shrink when encountering them, but however it has this weird side effect.

You can take a look at the complete code by analyzing all the con files of the addon in the attached zipfile. I have merged bdp.con into gategame.con (formerly bgame.con) for convenience purposes.

This post has been edited by NightFright: 26 November 2015 - 02:41 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#128

View PostNightFright, on 26 November 2015 - 02:34 AM, said:

Actually, the code above is everything I am adding to what's already there. It definitely works because it avoids the Predators to shrink when encountering them, but however it has this weird side effect.

You can take a look at the complete code by analyzing all the con files of the addon in the attached zipfile. I have merged bdp.con into gategame.con (formerly bgame.con) for convenience purposes.


Your code:

// Sprite resize bugfix for Predator (4818 PREDATOR/4819 PREDSTAYPUT)
onevent EVENT_SPAWN
   switch sprite[THISACTOR].picnum
   case 4818
   case 4819
      setactor[THISACTOR].xrepeat 42
      setactor[THISACTOR].yrepeat 36
   break
   endswitch
endevent


Instead of using EVENT_SPAWN, I would use EVENT_LOADACTOR

You can do that right now and I'm pretty sure the problem will be fixed, but to know why, read on. EVENT_LOADACTOR only applies to the sprites in the map at map load time. EVENT_SPAWN applies to all sprites (excluding certain statnums) when they enter the game, whenever that is. This may not sound like it would be a problem, but I believe it is in this case. Without looking at the other code I can't be sure, but it's most likely that this TC has one or more actors that behave differently depending on whether they were in the map from the start, or spawned later (this could have been detected using the "ifspawnedby" CON command, before eduke). The key fact here is that when a sprite is spawned by another sprite using CON code, it normally starts with a size of 0. If the author is using that sprite as an effector of some sort, then keeping it at size 0 is desirable, because it makes the sprite invisible. Having spawned actors start at size 0 is desirable, because otherwise you would see them get resized in game. The only actors you see get resized are the ones placed directly using the map editor -- respawns aren't an issue because they are invisible until their actor code resizes them (or in the case of actors with hardcoding, they are sized appropriately right away).
2

User is online   NightFright 

  • The Truth is in here

#129

I appreciate your help with this investigation, DT. Your explanation was even understandable for me, and I am quite a noob with these things. xD Let's see if we can figure this out together!

Regarding your suggestion: Well, that's basically the approach I took in the beginning if you check this old post here. Fox recommended to use EVENT_SPAWN instead back then, so I did.

The thing is, not so long ago, in an attempt to fix this issue by myself, I actually replaced EVENT_SPAWN with EVENT_LOADACTOR to see what happens. The result was that the dummy/fake sprites were gone, but so were the fixes. Sprite resizing happened again as if the patch code hadn't been applied at all. I will try again now with latest EDuke32 snapshots, but somehow I have my doubts that the result will be any different.

This post has been edited by NightFright: 26 November 2015 - 12:27 PM

0

User is offline   Danukem 

  • Duke Plus Developer

#130

View PostNightFright, on 26 November 2015 - 12:21 PM, said:

The thing is, not so long ago, in an attempt to fix this issue by myself, I actually replaced EVENT_SPAWN with EVENT_LOADACTOR to see what happens. The result was that the dummy/fake sprites were gone, but so were the fixes.


Yeah I would try it again, and when it doesn't work, then we'll figure out why and go from there.

EVENT_LOADACTOR should do the job if the wrong-sized sprites were placed in the map using the map editor. If the sprites are spawned in-game, then no fix should be necessary.

There are, of course, possible wildcards that could muck things up. For example, I'm not sure what would happen if you had two different instances of EVENT_LOADACTOR without using "appendevent". Would it only use code from the first instance?

If it turns out to be a tough problem, I would use DNDEBUG near the location of one of the errant dummy sprites. Check the picnum of the sprite in debug.map in mapster to verify the picnum, and then check that location in the original map to see what picnum of sprite (if any) occupies that location.
0

User is offline   Danukem 

  • Duke Plus Developer

#131

I have an update about the resizing issue, and since it may involve a bug that will interest others, I'll post about it here.

For a completely unrelated reason I used EVENT_SPAWN to resize HEAVYHBOMB. To my surprise, pal 1 HEAVYHBOMBs started appearing in single player. (Items marked with pal 1 are only supposed to appear in multiplayer). Also, the sprites were dummies, I could not pick them up like normal pipebombs. So this suggests that we have an eduke bug here. Apparently, if EVENT_SPAWN is used on a sprite, the hardcoding which normally causes a sprite to not appear (at least in the case of multiplayer-only tags, possibly in other cases) does not work.
2

User is offline   Nevander 

#132

edit: nevermind

This post has been edited by Nevander: 15 December 2015 - 01:26 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #133

View PostTrooper Dan, on 28 November 2015 - 12:01 AM, said:

So this suggests that we have an eduke bug here.

I was able to replicate the behavior you describe--as far back as OldMP, which is based on r1199 from 2009. This tells me that it is EVENT_SPAWN's intended function. It's a feature: you can intercept sprite deletions on map start by changing their size and statnum.

Looking at the source where is called, what you'll need to do is only resize sprites that have a non-zero xrepeat.

@NightFright:

// Sprite resize bugfix for Predator (4818 PREDATOR/4819 PREDSTAYPUT)
onevent EVENT_SPAWN
    switch sprite[THISACTOR].picnum
    case 4818
    case 4819
        ifvarg sprite[THISACTOR].xrepeat 0
        {
            setactor[THISACTOR].xrepeat 42
            setactor[THISACTOR].yrepeat 36
        }
        break
    endswitch
endevent

2

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#134

Note that internally the game sets some sprites scale to zero to delete them. So naturally if you change the scale during the spawning tics, these sprite will remain.

This post has been edited by Fox: 29 November 2015 - 10:34 PM

1

User is offline   Danukem 

  • Duke Plus Developer

#135

View PostFox, on 29 November 2015 - 10:34 PM, said:

Note that internally the game sets some sprites scale to zero to delete them. So naturally if you change the scale during the spawning tics, these sprite will remain.


If the game does that to delete multiplayer only sprites when starting a map in singleplayer, then that would certainly explain it.
0

User is online   NightFright 

  • The Truth is in here

#136

View PostHendricks266, on 29 November 2015 - 10:16 PM, said:

I was able to replicate the behavior you describe--as far back as OldMP, which is based on r1199 from 2009. This tells me that it is EVENT_SPAWN's intended function. It's a feature: you can intercept sprite deletions on map start by changing their size and statnum.

Looking at the source where is called, what you'll need to do is only resize sprites that have a non-zero xrepeat.

@NightFright:
[Stuff]

That code seems to do the trick, at least in "The Gate". No dummies any more while resizing is still prevented. Need to check it in the other four addons that are affected.

I was also wondering if this kind of code makes any sense (from ZeroHour):

   case LIZTROOP
      setactor[THISACTOR].xrepeat 25
      setactor[THISACTOR].yrepeat 25
      ifspritepal 3
         setactor[THISACTOR].xrepeat 40
         setactor[THISACTOR].yrepeat 35
      ifspritepal 9
         setactor[THISACTOR].xrepeat 30
         setactor[THISACTOR].yrepeat 30   
   break


Somehow I am sceptical about the "ifspritepal" parts, I don't think the game recognizes that. There's no warning or error message about it in the logs, but it doesn't mean it's correct.

This post has been edited by NightFright: 30 November 2015 - 02:50 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#137

View PostNightFright, on 30 November 2015 - 02:49 AM, said:

Somehow I am sceptical about the "ifspritepal" parts, I don't think the game recognizes that. There's no warning or error message about it in the logs, but it doesn't mean it's correct.


It's fine, but you need to use braces because it is followed by 2 commands. So it should be:

ifspritepal 3
{
      setactor[THISACTOR].xrepeat 25
      setactor[THISACTOR].yrepeat 25
}
ifspritepal 9
{
         setactor[THISACTOR].xrepeat 30
         setactor[THISACTOR].yrepeat 30
}
break


Some languages care about indenting but CON isn't one of them. :)
0

User is offline   Hendricks266 

  • Weaponized Autism

  #138

View PostNightFright, on 30 November 2015 - 02:49 AM, said:

I was also wondering if this kind of code makes any sense (from ZeroHour):

You would need curly braces surrounding what you want to do ifspritepal because you have more than one statement.

        ifspritepal 3
        {
            setactor[THISACTOR].xrepeat 40
            setactor[THISACTOR].yrepeat 35
        }


Since you're setting the size on the current actor, you can use sizeat instead of structure access.

Here is the code posted in your previous thread, updated. It was actually broken in some respects due to the lack of curly braces, and of else statements for your ifcount statements.

[code removed]

What were you intending with "ifcount" for Duke, It's ZeroHour's ORGANTIC and Infestation in Time's BLUESLIME? EVENT_SPAWN only takes place during the first tic of an actor's execution.

This post has been edited by Hendricks266: 30 November 2015 - 08:21 AM

0

User is online   NightFright 

  • The Truth is in here

#139

Actually I had already applied those braces today by myself just to be sure. ^^

Regarding ifcount (or ifspawnedby), I saw in the CON code that there were different cases for sizeto in the code and assumed that it works the same way with ifcount than with ifspritepal. If that doesn't make any sense, now is the time to fix it... if I know how it's supposed to be.

Examples from "Infestation in Time" where I potentially screwed up:
Spoiler

Also, is it needed to put the ifvarg line everywhere like this:
case LIZTROOP
      ifvarg sprite[THISACTOR].xrepeat 0
      {
         setactor[THISACTOR].xrepeat 25
         setactor[THISACTOR].yrepeat 25
      }
      ifspritepal 3
      {
         ifvarg sprite[THISACTOR].xrepeat 0
         {
            setactor[THISACTOR].xrepeat 40
            setactor[THISACTOR].yrepeat 35
         }
      }
      ifspritepal 9
      {
         ifvarg sprite[THISACTOR].xrepeat 0
         {
            setactor[THISACTOR].xrepeat 30
            setactor[THISACTOR].yrepeat 30
         }
      }  
   break


Or is this enough?
   case LIZTROOP
      ifvarg sprite[THISACTOR].xrepeat 0
      {
         setactor[THISACTOR].xrepeat 25
         setactor[THISACTOR].yrepeat 25
      }
      ifspritepal 3
      {
         setactor[THISACTOR].xrepeat 40
         setactor[THISACTOR].yrepeat 35
      }
      ifspritepal 9
      {
         setactor[THISACTOR].xrepeat 30
         setactor[THISACTOR].yrepeat 30
      }  
   break


CONS of "Infestation in Time" and "ZeroHour" are attached if needed for comparison. "Dukenstein", "The Gate" and "Grins of Divinity" don't have such cases and should be fixed already.

This post has been edited by NightFright: 30 November 2015 - 09:01 AM

0

#140

I corfirm from personal experience that Infestation In Time is pretty broken at first levels, the most striking example among many is scorpion tanks that doesn't move, don't attack and even not destructibles i guess. But remains a good challenging mod to complete.

Quote

CONS of "Infestation in Time" and "ZeroHour" are attached if needed for comparison. "Dukenstein", "The Gate" and "Grins of Divinity" don't have such cases and should be fixed already.


I don't get why it was decided to choose Dukenstein, it is really that remembered and appreciated to deserve a revised version? Why no one thinked about like this?

http://www.moddb.com...ass-destruction

I know it is a kind of Proto-Attrition, but it has certainly laid the groundwork for Attrition mechanics itself plus it's made from Trooper Dan in his "DeeperThought" period (so that could also eventually fill the empty section on its website http://fissile.duke4...sile_dnwmd.html).

Another nice choice for a classic style episode that need to get rid of some bugs could be Duke It Out In New York (to not be confused with New York Rebellion).

http://dukertcm.com/...e-new-york.html


Ps. Trooper Dan has already contacted you to have permission about add the updated maps in his mods?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #141

View PostNightFright, on 30 November 2015 - 08:37 AM, said:

Also, is it needed to put the ifvarg line everywhere like this:
Or is this enough?

The first case is functionally correct but neither is optimal.

    case LIZTROOP
        ifvarg sprite[THISACTOR].xrepeat 0
        {
            ifspritepal 3
                sizeat 40 35
            else ifspritepal 9
                sizeat 30 30
            else
                sizeat 25 25
        }
        break


View PostNightFright, on 30 November 2015 - 08:37 AM, said:

Regarding ifcount (or ifspawnedby), I saw in the CON code that there were different cases for sizeto in the code and assumed that it works the same way with ifcount than with ifspritepal. If that doesn't make any sense, now is the time to fix it... if I know how it's supposed to be.

Indeed it doesn't make any sense. EVENT_SPAWN is only needed to make sure sprites are the correct size before the actor block takes over. If the actor code has a sizeto, all we need to do in the event is make sure the sprite is what it should be before the sizeto takes over.

ifcount is entirely out of place in EVENT_SPAWN because it is only run once, before the actor's every first tic. Its count will never elapse.

Here is the fixed code I referred to.

The Gate
Spoiler

Grins of Divinity
Spoiler

Infestation in Time
Spoiler

Duke, It's ZeroHour
Spoiler

There are many subtleties to good code design and I'll try to teach some of the changes I made.

  • sizeat used where structure access is unnecessary
  • appendevent, which makes more sense for mutator-like code
  • consistent 4-space width "tabs"
  • break indented logically
  • braces used whenever needed, but only when needed (EDIT: turns out to be nowhere)
  • else used

You'll notice I decided to run the xrepeat check at the very beginning and break out of the entire event if it fails. This is a stylistic choice on my part to keep the code length small. Note that these EVENT_SPAWN invocations should only be used for this resizing purpose. If for some reason you needed to do something unrelated in EVENT_SPAWN, you can simply add a separate appendevent block.

You'll want to check the two cases where the code formerly used ifcount to make sure they look right, and by "check" I mean test in-game, with this code, in multiple locations of these enemies. The "problem" here has existed since before you released the initial version of this pack, so something must have gone wrong during the testing phase when you were originally preparing it.

This post has been edited by Hendricks266: 30 November 2015 - 06:02 PM

1

User is online   NightFright 

  • The Truth is in here

#142

@ Hendricks:
Great! This code also seems to work, just like the one with ifvarg. I will also apply this to Dukenstein. Afterwards, I guess the best thing will be to play through at least a full episode to see if there are any sprites which show glitches. Already found that a different sizeat value needs to be applied to #5120 (white robot hulk) in Grins (sizeat 32 32 instead of 40 40), will be fixed. Thanks a lot again for all the assistance you provided! I already suspected that it was rather a code issue than one with EDuke32. If I understood correctly (and to sum up my original mistake), the code I had originally used prevented EDuke from wiping/hiding sprites which would normally be gone after the levels had been loaded. I still don't get why the dummy sprites appeared in those spots since when checking those maps, absolutely nothing is there to find. Anyway, main thing is it doesn't happen any more. :)

@ Fantinaikos:
The choices of entries in this compilation are of course somewhat subjective. I tried to add as many as possible, but it's impossible to fulfill everyone's wishes. I try to avoid code-heavy addons which have been specifically written for EDuke as they inevitably break while new snapshots keep being released. I am aiming for a collection that will keep working, regardless what happens with EDuke32. That's also why I decided to remove "Nuclear Showdown" again for v2.0 (never got it fully working, anyway). It's disappointing for some of you, but we are still talking about a collection with far over 1.000 SP levels. And good ones.

Regarding Duke NY: I have taken a look at this addon a while ago already when I was looking for more candidates to add. This thing is, frankly spoken, a clusterf*ck. What worried me most was the fact that the author(s) cheated by reusing the exact same levels over and over again (with different names, even different files for 100% identical maps) to make the episodes appear longer than they actually were. What's left is a mess of broken and, if I may say so, pretty sub-par levels which are hardly worth anyone's time. I may take a look at this again later on, but the probability for this to find its way into the compilation in any form is quite low. I will add one more entry to the pack before the release, and that will be TamDuke by pmw. Trying to aim for a healthy mix of older and newer addons.

This post has been edited by NightFright: 01 December 2015 - 04:42 AM

0

User is offline   FistMarine 

#143

edit

This post has been edited by FistMarine: 11 December 2016 - 06:48 AM

1

User is online   NightFright 

  • The Truth is in here

#144

I already explained that I cannot add any more addons if I want to stick to my release deadline at the end of December. TamDuke should be easy to add since it will not involve any extra code, so it can just be used without any major changes. I have been working on this update for almost half a year now without interruptions, I guess it's not too harsh to ask for a break. :)
0

User is offline   FistMarine 

#145

edit

This post has been edited by FistMarine: 11 December 2016 - 06:48 AM

1

#146

Before release, it is possible do something to make possibly Vacation Cove ACTUALLY work with Duke Caribbean? Personally I did some basic CON editing by myself to play it as an episode (adding Sharks Cove also) and thats almost perfectly worked, but I'd like to see it officially. I can even post my CON if anyone is interested.
0

User is online   NightFright 

  • The Truth is in here

#147

That would go against the intention to stay as true to the original releases as possible. I have no means to ask the author(s) of that mod for authorization, and to respect their efforts, I cannot apply modifications that go against the original presentation of the addon. Besides, Vacation Cove works fine the way it stands. You could use the Caribbean art files to replace weapons and monsters maybe, but other than that...
0

#148

View PostNightFright, on 01 December 2015 - 11:27 AM, said:

That would go against the intention to stay as true to the original releases as possible. I have no means to ask the author(s) of that mod for authorization, and to respect their efforts, I cannot apply modifications that go against the original presentation of the addon. Besides, Vacation Cove works fine the way it stands. You could use the Caribbean art files to replace weapons and monsters maybe, but other than that...


Well I have not told the WHOLE story, me neither have touched the Vacation Cove CONs or the Carribean CONs, the CON i edited it was in VACAPLUS by Hendricks266. This has avoided an entire ART replacement process and a more extensive overwriting (even if VACAPLUS it's clearly based on original Carribean files).

By the way, Nuclear Winter Plus And Vacation Plus seems either stalled on github, any news about it?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #149

View PostFantinaikos, on 01 December 2015 - 11:55 AM, said:

By the way, Nuclear Winter Plus And Vacation Plus seems either stalled

HRPs are community projects, and there have not been any submissions to NW+ or Vaca+ in years.

View PostFantinaikos, on 01 December 2015 - 11:55 AM, said:

on github

Subversion is not Git, and Git is not GitHub.
0

User is offline   FistMarine 

#150

edit

This post has been edited by FistMarine: 11 December 2016 - 06:49 AM

1

Share this topic:


  • 68 Pages +
  • « First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options