[Fox]

It depends of which value you are trying to change. For example, .vel would have no effect after the projectile is fired because it's used to calculate the sprite .xvel/zvel.

Also remember setprojectile refers to a picnum, and setthisprojectile to a sprite ID.

[Jblade]

No you misunderstand, I'm saying the specific feature userdata doesn't appear to be set using those two commands, no matter what I use (I asked helixhorned to add that to projectiles a while back so I can set what damage type a projectile is right in it's definition instead of having to add case-specific stuff everywhere)

[Danukem]

James, on 04 July 2014 - 02:21 PM, said:

No you misunderstand, I'm saying the specific feature userdata doesn't appear to be set using those two commands, no matter what I use (I asked helixhorned to add that to projectiles a while back so I can set what damage type a projectile is right in it's definition instead of having to add case-specific stuff everywhere)

I didn't know about that feature. How are you checking to see if the member is being set? It's weird that you could use the command to set it without getting an error if it's not actually doing anything. Also, how do you plan to use the information to apply the damage (i.e. what events, what point in the projectile's lifecycle, etc)?

[Hendricks266]

James, on 04 July 2014 - 10:56 AM, said:

Does setprojectile[whatever].userdata and setthisprojectile[whatever].userdata work, or are they not 'plugged in' properly? I'm trying to use it in my code and neither of the two work (using setprojectile before it's fired or using setthisprojectile afterwards)

It looks plugged in properly. Odd. Helix wrote this to test: http://svn.eduke32.c.../weaponvars.con

[Jblade]

If I set the projectiles' userdata to 32 beforehand and just do that, it works - but if I set it back to 64 after the missile is fired than then missile in transit is set back to 64 too (I'm fairly sure none of the other projectile settings should affect one already fired unless using setthisprojectile but I may be mistaken) Using setthisprojectle just doesn't seem to affect the sprite (I've logged down what the sprite's userdata is, and it's still 64 even after being set)

[Hendricks266]

I reviewed the code again and it all looks right. Could I ask you to put together an example CON module of this not working? (Basically, I could run "eduke32.exe -mx userdatatest.con" and userdatatest.con would contain a projectile definition, and EVENT_TURNAROUND (for example) shoots it and sets whatever doesn't work and EVENT_GAME prints addlogvar, etc. Hopefully that makes sense.)

The fact that the gamestructure code passes inspection suggests something more insidious is at work.

[Jblade]

I just threw together a little example and it worked, so I'm not sure why it's not working in my proper con file. I'll just have to search and see if there's some conflicting information or something like that. Here's the test code in anycase:

defineprojectile 958 PROJ_WORKSLIKE 32770
defineprojectile 958 PROJ_SPAWNS RPG_EXPLODE
defineprojectile 958 PROJ_VEL 999
defineprojectile 958 PROJ_EXTRA 0
defineprojectile 958 PROJ_XREPEAT 32
defineprojectile 958 PROJ_YREPEAT 32
defineprojectile 958 PROJ_CSTAT 128
defineprojectile 958 PROJ_USERDATA 32

gamevar PROJ_LOG 0 0
gamevar TEMP 0 2

onevent EVENT_TURNAROUND
setvar RETURN 1
setprojectile[958].userdata 64
eshoot 958
setvarvar PROJ_LOG RETURN
setprojectile[958].userdata 32
endevent

onevent EVENT_GAME
getthisprojectile[PROJ_LOG].userdata TEMP
addlogvar TEMP
endevent

[Simon_Croes]

I don't know where else to put it but I recently downloaded the last Eduke32 snapshot and I decided to look into the multiplayer. As my surprise it got a new menu! But as I wanted to change the game options (to select an other map, etc) it crashes. Even when I try it in standard Duke3D 1.4 (nothing modified). I get this error in my log: g_errorLineNum: 0, g_tw: 0
I don't know what that means. I use the -server command and I know multiplayer is still being a WIP but I was wondering if someone else got this crash. I haven't tried older snapshots.
I'll attach the full log and a screen.

Attached thumbnail(s)

• 

Attached File(s)

•  eduke32.log (1.34K)
  Number of downloads: 382

[Fox]

The update with EVENT_ACTIVATECHEAT is really good. Would it be possible to make scotty### return (2 + ###*65536)?

(I don't have any specific use for it now, but I tought of it as something usefull)

[TerminX]

That seems completely unnecessary when you can just set a flag that the warp cheat was activated and then read the new level and volume number yourself once the new map loads.

[Fox]

But then you wouldn't be able to prevent the cheat from being activated (i.e. set RETURN to -1).

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