[TerminX]

What's the point of that, to prevent a user from cheating to change to certain levels but not others? That kind of micromanagement of the end user's use of cheats seems a bit excessive...

Still, though, in the spirit of Duke modding there is already a way to do that. Just save the current volume and level to vars, save the map state, let the cheat do its thing and kick the game back to the original level (and load the map state) if they happened to choose something you didn't want them to warp to. I certainly don't think there needs to be specialized coding in EDuke32 for that one sadistic guy who wants to punish people who know about "DNSCOTTY" but not the "changelevel" console command.

[Fox]

Actually I was thinking of some effects that could be applied. For example, a transition effect between levels. But again, I don't have any specific use for that. It's just a matter of increasing the customization.

[Jblade]

Would it be possible to define our own bits for a definesound command, and be able to detect that with a command or something? I'm thinking it would be useful so I could set a bunch of sounds to a new flag and then be able to check if a sound with that flag is playing (so I could for example make a 'enemy voice' bit and then check to see if any sound with that is playing so an actor won't talk over itself) Of course you could do it with a ton of ifsound checks but that's kind of an ugly solution.

[Fox]

Your idea is somewhat broken. It would require you to check if there is already a sound playing with that bit (aka loop through all sound IDs with ifactorsound), which is even uglier.

I would recommend you to check for the sound ID in EVENT_SOUND:

onevent EVENT_SOUND
  switch RETURN
  case PRED_ROAM
  case PRED_ROAM2
  case PRED_RECOG
  case PRED_PAIN
  case PRED_DYING
    ifactorsound THISACTOR PRED_ROAM
      setvar RETURN -1
    ifactorsound THISACTOR PRED_ROAM2
      setvar RETURN -1
    ifactorsound THISACTOR PRED_RECOG
      setvar RETURN -1
    ifactorsound THISACTOR PRED_PAIN
      setvar RETURN -1
    ifactorsound THISACTOR PRED_DYING
      setvar RETURN -1
  break
  endswitch
endevent

[Jblade]

But that's what I wanted to avoid, having to code case specific stuff. Being able to con code a system and then just needing to set a flag and it's then taken care of by whatever I code to do with it, instead of having to manually check every sound I want to disable would be much better.

[Fox]

Is it possible to add an option to hide certain tiles from Mapster? It's rather common to use some dummy tiles as placeholders which I doesn't want to be popping while mapping.

[TerminX]

James, on 16 July 2014 - 10:01 AM, said:

Would it be possible to define our own bits for a definesound command, and be able to detect that with a command or something? I'm thinking it would be useful so I could set a bunch of sounds to a new flag and then be able to check if a sound with that flag is playing (so I could for example make a 'enemy voice' bit and then check to see if any sound with that is playing so an actor won't talk over itself) Of course you could do it with a ton of ifsound checks but that's kind of an ugly solution.

Why not just create an array in CON and store your flags there? Then you can use EVENT_SOUND and just use RETURN as the index into the array.

[Jblade]

TerminX, on 18 July 2014 - 01:36 PM, said:

Why not just create an array in CON and store your flags there? Then you can use EVENT_SOUND and just use RETURN as the index into the array.

That's a pretty good idea actually, I'll do that. thanks!

[TerminX]

No problem! I think you guys have gotten a little too comfortable with just asking for a new feature every time you want to do something that falls outside the range of what the list of commands implies you can do.

[Jblade]

Well in my defense I try and not ask for too case-specific stuff, just things I think would benefit more people than just me. AMC EP2 should be out at the end of the year so at least everybody who's added stuff will be able to see I've actually used the stuff I asked for

[Hendricks266]

TerminX, on 18 July 2014 - 01:36 PM, said:

Why not just create an array in CON and store your flags there? Then you can use EVENT_SOUND and just use RETURN as the index into the array.

I was considering posting that too, but it does not have much of an advantage over Fox's event. You still need to create a state that initializes the array, or you could use readarrayfromfile if you're feeling hexy and don't mind breaking 32 and 64-bit interoperability until that issue is fixed.

[Jblade]

Quote

or you could use readarrayfromfile if you're feeling hexy and don't mind breaking 32 and 64-bit interoperability until that issue is fixed.

I use readarrayfromfile quite alot, although nothing terrible exotic - is there a problem with it or something? (I run a 32bit OS so I've never tried the 64-bit one)

[Hendricks266]

For a particular nasty reason, those commands use 64 bits per gamevar on 64-bit, even though gamevars are 32-bit. The 64-bit behavior is incorrect and it needs to be fixed.

[Fox]

Based on what he is saying, he is not going to use large values, so it shouldn't be a problem.

[Hendricks266]

Perhaps I was not clear. The commands use 64 bits on disk per gamevar, which completely breaks interoperability between bitnesses.

[Danukem]

Recent changes in EDuke32 have broken the WGR2 TC menu display. We use a modified tile 2502 (the tile that is the glowing ATOMIC which goes on top of the logo). Our modified version is very large, but this wasn't a problem before because it was drawn underneath the menu and episode selection text so it was still readable. Note that this was hardcoded behavior: I have no CON code that draws the tile, I simply replaced the tile in the art file. But in new builds, that tile is drawn on top of everything, so the text is covered up. I realize that the old behavior could be considered a bug -- arguably the "ATOMIC" was supposed to be on top all along. I don't mind trying to deal with this change for upcoming releases, but unfortunately there are old versions out there which have been distributed far and wide (i.e. every version of this popular TC that has ever been released over the years) and anyone who updates the eduke32.exe for those versions will make the game pretty much unplayable because they won't be able to read the menu items.

[Hendricks266]

I will include a fix for this in my next push.

[Fox]

Trooper Dan, on 19 July 2014 - 09:04 PM, said:

Recent changes in EDuke32 have broken the WGR2 TC menu display. We use a modified tile 2502 (the tile that is the glowing ATOMIC which goes on top of the logo). Our modified version is very large, but this wasn't a problem before because it was drawn underneath the menu and episode selection text so it was still readable. Note that this was hardcoded behavior: I have no CON code that draws the tile, I simply replaced the tile in the art file. But in new builds, that tile is drawn on top of everything, so the text is covered up. I realize that the old behavior could be considered a bug -- arguably the "ATOMIC" was supposed to be on top all along. I don't mind trying to deal with this change for upcoming releases, but unfortunately there are old versions out there which have been distributed far and wide (i.e. every version of this popular TC that has ever been released over the years) and anyone who updates the eduke32.exe for those versions will make the game pretty much unplayable because they won't be able to read the menu items.

Ugh, if it was a bug, then it is a problem with the mod, which was unfortunate to be using that version. But I believe you could fix it by disabling the main menu tile with dynamicremap and drawing it manually with EVENT_GETMENUTILE.

Still on topic, could you make it possible to vertically offset the main menu (i.e. default value = 55 or so I think)? That would help a lot with the 64 and PSX mods.

[Hendricks266]

Fox, on 19 July 2014 - 10:01 PM, said:

Ugh, if it was a bug, then it is a problem with the mod, which was unfortunate to be using that version. But I believe you could fix it by disabling the main menu tile with dynamicremap and drawing it manually with EVENT_GETMENUTILE.

He used #2503 ("ATOMIC") because it's already drawn by the game, so why not? My menu rewrite consolidated all sprites and non-selectable text (such as Duke in the player setup) into one function that runs after the menu draws. My fix will be moving the calls to this function so that they take place before the menu text is drawn.

EDIT: My code appears to already be correct: extra stuff is drawn before menu text. Odd.

Fox, on 19 July 2014 - 10:01 PM, said:

Still on topic, could you make it possible to vertically offset the main menu (i.e. default value = 55 or so I think)? That would help a lot with the 64 and PSX mods.

I'm not going to add a sloppy hack like that. You smokin'? Wait for complete menu redefinition.

[Danukem]

Fox, on 19 July 2014 - 10:01 PM, said:

Ugh, if it was a bug, then it is a problem with the mod, which was unfortunate to be using that version. But I believe you could fix it by disabling the main menu tile with dynamicremap and drawing it manually with EVENT_GETMENUTILE.

Yes, or I could move the tile to a different number by actually editing the art file and then draw it manually. But the problem is that the TC is out there, hosted on various sites, and in some cases I didn't even put it there. If I release a new version, it won't help all those copies out there. Also, I'm not even planning on updating the old WGR2: currently we are working on a new episode, but I don't want to take the old one down since there are many changes and some people might prefer the original code (even if I include all episodes in the next release)

Hendricks266, on 19 July 2014 - 10:23 PM, said:

He used #2503 ("ATOMIC") because it's already drawn by the game, so why not? My menu rewrite consolidated all sprites and non-selectable text (such as Duke in the player setup) into one function that runs after the menu draws. My fix will be moving the calls to this function so that they take place before the menu text is drawn.

EDIT: My code appears to already be correct: extra stuff is drawn before menu text. Odd.

This is what happens.

[Fox]

Hendricks266, on 19 July 2014 - 01:01 PM, said:

For a particular nasty reason, those commands use 64 bits per gamevar on 64-bit, even though gamevars are 32-bit. The 64-bit behavior is incorrect and it needs to be fixed.

I should ask, is the bitness (supposed to be) used for anything other than optimizing Polymost and Polymer?

[Hendricks266]

Trooper Dan, on 20 July 2014 - 12:07 AM, said:

This is what happens.

That's the episode selection menu. #2503 isn't drawn by the exe at that time. Hmm.

Fox, on 20 July 2014 - 12:35 AM, said:

I should ask, is the bitness (supposed to be) used for anything other than optimizing Polymost and Polymer?

It allows the game more than 3 GB of system RAM.

[Fox]

Since it's behind the title, it's probably replacing tile 2457.

===//===//===

So, what about finally breaking the vertical look limit? My idea would be to have a 11-bits thoriz ("true horizon") player structure and a camera variable that override the value of horiz in Polymost and Polymer. Of course this would only have practical use for custom mods.

[Danukem]

Fox, on 20 July 2014 - 12:52 AM, said:

Since it's behind the title, it's probably replacing tile 2457.

Yes! It's 2457. Sorry about the earlier confusion -- I was looking through the art tiles and I saw one that looked similar at #2502.

Also I remembered that the tile is also used as a decoration in some maps, so moving the art to another tile or remapping it would break those maps as well.

[Fox]

How would remapping it break the maps?

[Danukem]

Fox, on 20 July 2014 - 12:37 PM, said:

How would remapping it break the maps?

If I remapped the tile to a different number, wouldn't it cause the tile to not display in the maps? Also, regardless of that, there is still the problem that nothing I do with future releases will help with the long-released TC when used with the current build.

[Fox]

No, that's not how dynamicremap works. Essentially there is a copy of DEFS.CON in the source code which is used for hard-coded effects, and dynamicremap allows you to modify it.

[Danukem]

Fox, on 20 July 2014 - 02:12 PM, said:

No, that's not how dynamicremap works. Essentially there is a copy of DEFS.CON in the source code which is used for hard-coded effects, and dynamicremap allows you to modify it.

OK, I'll keep that in mind, but the breakage should still be fixed on the source side -- I think it's reasonable to expect source changes to not break a popular TC that has been around for 4 years and has been working fine for all of that time.

[Fox]

In this case it should because it's v1.5 behavior:

[Hendricks266]

I know exactly what to do now. Thanks. It's not 100% tidy in the code but no biggie.