[Danukem]

December Man, on 12 October 2015 - 09:04 AM, said:

I must've done something horribly wrong, since the placement of pstomp doesn't change a thing. Yes, I think I tried all the possible placement and the whole code I have written is just bad.

pstomp begins a sequence which results in the deletion of the sprite that is issuing the command. It is NOT used in conjunction with killit, in any order. You either use pstomp to delete the sprite, or you use killit, you do not use both. If you have any questions, look at how it is used in an unmodified GAME.CON, or look at the source code.

[Mblackwell]

And all code that you want to execute has to be run before the sprite is deleted. Telling the game to delete a sprite results in the end of its code execution.

[OpenMaw]

Is it possible to edit the Shareware of Duke3D and run it with Eduke32, but still have it considered the "shareware" version?

Alternatively, is there a way to compile a .grp that handles like a shareware copy of Duke3D?

[Hendricks266]

The short answer is yes, but why?

[Daedolon]

Bitches love shareware.

[OpenMaw]

Only for nine levels though, then they want you to pay for the rest. Hey-o!

It was just something I was curious about. I remember a long time ago trying to edit the shareware version of the game so I could release it standalone and any tampering with the grp resulted in the game thinking you were trying to run a full version.

[The Mechanic]

I was trying to detect a useractor being hit by a weapon, and unfortunately found the eduke wiki entry for ifwasweapon isn't very helpful - it mentions <weapon> but fails to give any details.

From examining the existing GAME.CON I've found:

COOLEXPLOSION1
FIREEXT
FIRELASER
FREEZEBLAST
GROWSPARK
KNEE
RADIUSEXPLOSION
RPG
SHRINKSPARK
SHOTSPARK1

Whilst the names of some of the weapons used in GAME.CON are obvious, some are not. SHOTSPARK1 appears to be both pistol and shotgun (so it seems you can't differentiate the two). As for COOLEXPLOSION1, looking through the code I thought COOLEXPLOSION1 was the octobrain's, er, whatever it's shot is called but it also appears to be fired by BOSS2 !?

Perhaps the Eduke wiki maintainer could update the relevent page.

TTFN,
Jon

PS: Also curious about FIREEXT, what is it ? I thought it might be the fire extinguisher but that actually appears (quite logically) as weapon RADIUSEXPLOSION. FIREEXT is only used in one place - in the player's code - where it simply duplicates the effect of a RADIUSEXPLOSION.

[Mblackwell]

It's all here:

http://wiki.eduke32....for_ifwasweapon

You can also theoretically check for SHOTGUN and CHAINGUN, which is just a shotspark1 actor with its extra/damage value defined by those constants.

[The Mechanic]

 Mblackwell, on 25 October 2015 - 01:39 PM, said:

It's all here:

http://wiki.eduke32....for_ifwasweapon

Cheers !

I did have a good search first but did not locate that section.

So, I'll modify my previous request to the Eduke wiki maintainer to add a link to this information from the ifwasweapon wiki page.

 Mblackwell, on 25 October 2015 - 01:39 PM, said:

You can also theoretically check for SHOTGUN and CHAINGUN, which is just a shotspark1 actor with its extra/damage value defined by those constants.

Out of curiosity how does an actor get access to this data (e.g. extra) for the weapon ?

TTFN,
Jon

[Mblackwell]

http://wiki.eduke32.com/wiki/Htextra does that help?

[Danukem]

Is there still no way to change the rotation of an in-game sprite using CON? I'm talking about the vertical rotation of the drawn sprite (not the angle). While I admit that I'm not very knowledgeable about this, it seems to me that since it is already possible to do this using the rotatesprite command on HUD sprites, then it should be possible to do it with in-game sprites (maybe by adding a functionality to tsprites).

[Fox]

Vertical rotation would be the sprite skewing, you meant the tile rotation. It probably can be done in OpenGL, but impossible in classic mode.

[pmw]

Fox, on 26 April 2013 - 03:59 PM, said:

Hmm, that's a trick one. Try this:

include this line somewhere before your actor code...

gamevar TEMP 0 2

Where you see the command "fall" in your actor, replace with:

  ifvare sector[THISACTOR].lotag 1
  {
    iffloordistl 8
      setactor[THISACTOR].zvel 0
    getsector[THISACTOR].lotag TEMP
    setsector[THISACTOR].lotag 0
    fall
    setsector[THISACTOR].lotag TEMP
  }
  else
    fall

Guys. Any other advice for this? I tried to solve that out, and I managed to make some enemies swim - not sink, but, example lizardman...when it jumps, it never comes down, lol.

I'm gonna publish my episode soon, I was just wondering, could anyone figure out working and clean solution to make _all_ enemies unsinkable?

[Mblackwell]

Try iffloordistl 1 or 4 instead of 8.

[Salvation]

I tried to copy AMC TC ironsight code into my mod (if i understand correctly, other modders are free to use the code just as long as they credit the original creators?).


As you can see on the picture, i have problem. When i push the button where ironsight / holosight should appear on screen, the original weapon does not disappear. What's wrong?

And also, currently if i want to keep ironsight on i must hold down the "ironsight button", but i would like to change like "button h: ironsight on -> press button h again: ironsight off".

Here is the code which is currently on my GAME.CON

onevent EVENT_DRAWWEAPON

ifvarand TEMP4 268435456 // Is the player holding the Sprint key down?
ifvare player[THISACTOR].curr_weapon 3
	{
	  setvar x 160
	  setvarvar WEAP_DISPLAY_TEMP2 WEAPSWAYX
	  divvar WEAP_DISPLAY_TEMP2 2
	  subvarvar x WEAP_DISPLAY_TEMP2
	  setvar y 140
	  setvarvar WEAP_DISPLAY_TEMP3 WEAPSWAYY
	  divvar WEAP_DISPLAY_TEMP3 2
	  subvarvar y WEAP_DISPLAY_TEMP3
	  setvarvar WEAP_DISPLAY_TEMP4 weapon_xoffset // setvar the weapon x sway to displaytemp4
	  divvar WEAP_DISPLAY_TEMP4 2 // divide it by 2 
	  addvarvar x WEAP_DISPLAY_TEMP4 // add it to x
	  subvar x 5 // offset it by 5
	  rotatesprite x y 52500 0 2536 shade pal 0 0 0 xdim ydim // Barrel
	  subvar y 40
	  // rotatesprite x y 12384 0 11047 0 0 1 0 0 xdim ydim // holographic crosshair
	  setvar x 160
	  subvarvar x WEAPSWAYX
	  subvar x 10
	  addvarvar x weapon_xoffset
	  setvar y 142
	  subvarvar y WEAPSWAYY
	  rotatesprite x y 52500 0 3825 shade pal 0 0 0 xdim ydim // holographic sight
	  
  }
  else
  {
	getplayer[THISACTOR].weapon_pos WEAP_DISPLAY_TEMP2
	mulvar WEAP_DISPLAY_TEMP2 -20
	setvar tilenum 2536
	rotatesprite x y M4A1_SIZE WEAP_DISPLAY_TEMP2 tilenum shade pal 0 0 0 xdim ydim
  }
 
break

endevent

Attached thumbnail(s)

• 

[Fox]

You have two if conditions open, else won't work for both of them.

Replace this:

  }
  else
  {
        getplayer[THISACTOR].weapon_pos WEAP_DISPLAY_TEMP2
        mulvar WEAP_DISPLAY_TEMP2 -20
        setvar tilenum 2536
        rotatesprite x y M4A1_SIZE WEAP_DISPLAY_TEMP2 tilenum shade pal 0 0 0 xdim ydim
  }

With this:

        break
  }
  getplayer[THISACTOR].weapon_pos WEAP_DISPLAY_TEMP2
  mulvar WEAP_DISPLAY_TEMP2 -20
  setvar tilenum 2536
  rotatesprite x y M4A1_SIZE WEAP_DISPLAY_TEMP2 tilenum shade pal 0 0 0 xdim ydim

[The Mechanic]

What is the correct way to replace a sprite's picnum during a game ?

I have custom tile that is replaced during the game with one of several other tiles depending upon current status. i'm hoping there is a way that avoids me writing to picnum itself, overriding it via some display event or something?

TTFN,
Jon

PS : In case it is of any relevence, the sprite is not a useractor, I simply check for it in EVENT_GAME and process it accordingly.

[Kyanos]

The Mechanic, on 19 November 2015 - 01:39 AM, said:

i'm hoping there is a way that avoids me writing to picnum itself, overriding it via some display event or something?

not that I can think of, you'll need to directly tell it to change picnum, then store the old tile# in a var if you need it later.

The Mechanic, on 19 November 2015 - 01:39 AM, said:

PS : In case it is of any relevence, the sprite is not a useractor, I simply check for it in EVENT_GAME and process it accordingly.

it shouldn't matter if the original tile is/was an actor, or if the new picnum is.

[Fox]

appendenvent EVENT_LOADACTOR
  getactor[THISACTOR].mdflags Temp
  orvar Temp 16
  setactor[THISACTOR].mdflags Temp
endevent

appendenvent EVENT_EGS
  getactor[THISACTOR].mdflags Temp
  orvar Temp 16
  setactor[THISACTOR].mdflags Temp
endevent

appendenvent EVENT_ANIMATESPRITES
  ifactor MYACTOR
    settspr[THISACTOR].tsprpicnum MYACTOR2
endevent

[Salvation]

I did exactly as you pasted but i still got the same problem.

Fox, on 18 November 2015 - 07:17 PM, said:

You have two if conditions open, else won't work for both of them.

Replace this:

  }
  else
  {
        getplayer[THISACTOR].weapon_pos WEAP_DISPLAY_TEMP2
        mulvar WEAP_DISPLAY_TEMP2 -20
        setvar tilenum 2536
        rotatesprite x y M4A1_SIZE WEAP_DISPLAY_TEMP2 tilenum shade pal 0 0 0 xdim ydim
  }

With this:

        break
  }
  getplayer[THISACTOR].weapon_pos WEAP_DISPLAY_TEMP2
  mulvar WEAP_DISPLAY_TEMP2 -20
  setvar tilenum 2536
  rotatesprite x y M4A1_SIZE WEAP_DISPLAY_TEMP2 tilenum shade pal 0 0 0 xdim ydim

[The Mechanic]

Fox, on 19 November 2015 - 06:00 AM, said:

appendenvent EVENT_LOADACTOR
  getactor[THISACTOR].mdflags Temp
  orvar Temp 16
  setactor[THISACTOR].mdflags Temp

........

appendenvent EVENT_ANIMATESPRITES
  ifactor MYACTOR
    settspr[THISACTOR].tsprpicnum MYACTOR2
endevent

Cheers Mr Fox sir ! Worked a treat and way better than teh filthy hack I was using.

TTFN,
Jon

[Salvation]

Problem solved. Just added another "setvar RETURN 1" inside the iron sight code. Now just switching the holographic sight off and replace it by iron sight.

Salvation, on 19 November 2015 - 06:45 AM, said:

I did exactly as you pasted but i still got the same problem.

[The Mechanic]

A while ago I discovered that sprite id's may change between EVENT_LOADACTOR and the main EVENT_WORLDs/EVENT_GAMEs. Question is, when does this renumbering take place ? Specifically, can I assume the renumbering has been done _prior_ to EVENT_ENTERLEVEL ?

TTFN,
Jon

[Fox]

That's impossible. Even gamevars are stored based on the sprite ID.

[The Mechanic]

Fox, on 29 November 2015 - 10:36 PM, said:

That's impossible. Even gamevars are stored based on the sprite ID.

Possible I'm afraid.Refer to this thread.

Sprite ID's as displayed Mapster are often different to their ID's during the game. That change must be occuring at some point during Eduke's initialisation.

There is precious little documentation for many of the events What I _think_ (ok, _hope_) is happening is that if a specific sprite's ID is going change then it happens immediately prior to it's EVENT_LOADACTOR. Thus, any sprites that have had EVENT_LOADACTOR called on them have an ID that is no longer going to change, any sprites not yet initialised _may_ undergo an ID number change.

This creates an issue when you are trying to link collections of sprites together during initialisation.

Anyhow, if my above theory is correct then by the time we get to EVENT_ENTERLEVEL (which appears to happen after all EVENT_LOADACTOR calls) all ID's have their final values, thus at this point I could link up collections of sprites. Hence my question in previous post.

TTFN,
Jon

[Fox]

Perhaps during premap such a thing could happen. However premap is not available to CON, and you should never assume an sprite ID may change.

The Mechanic, on 30 November 2015 - 02:08 AM, said:

This creates an issue when you are trying to link collections of sprites together during initialisation.

Are you listing the IDs of sprites in a map (i.e. set the hi-tag of a sprite to the ID of another)? That's a really bad idea.

[Danukem]

If you want to link sprites together during initialization, you just have to do it a different way. If you need them to be linked in a specific order, then the most common way to do it is by manually giving them ordered tags (lotags or something). If you are creating a path for actors to follow, then you can write an algorithm that determines the order at runtime (checking distance and line of sight from one to another, and so on). Using sprite IDs sounds like it would be difficult anyway, because if you edit the map and have to delete a sprite it's going to mess up your order.

[The Mechanic]

Trooper Dan, on 30 November 2015 - 08:08 AM, said:

If you want to link sprites together during initialization, you just have to do it a different way. If you need them to be linked in a specific order, then the most common way to do it is by manually giving them ordered tags (lotags or something). If you are creating a path for actors to follow, then you can write an algorithm that determines the order at runtime (checking distance and line of sight from one to another, and so on). Using sprite IDs sounds like it would be difficult anyway, because if you edit the map and have to delete a sprite it's going to mess up your order.

Hmm ... ok, more detail.

I have a custom locator.

"Extra" is a number used to group them together, so I could have multiple groups (paths) defined
"Lotag" is their relative position within the group
"Hitag" is an activation channel (consistent with rest of library)
"Angle" specifies if initially enabled / disabled.
"Palette" has a special meaning, 0 = defineing a group of locators, 21 = grouping all sprites in a sector.

During EVENT_LOADACTOR extra, lotag and hitag are safely stored in some per-actor gamevars and then reset to zero so nothing funny happens. If locator had lotag of 0 and pal 0 it is head of a group and given statnum 'A', otherwise it is given statnum 'B'

Each locator has a number of gamevars, in particular psprite and nsprite which get set up to point to previous and next locators within the same group.

At some point, the groups need to be built. So, for path locators :

For each sprite with statnum B
Search sprites with statnum A with a matching "extra" so as to find the head of the group
Insert sprite into head sprite's linked list of locators in the appropriate relative position (based on "lotag").

This creates groups of paths that code-wise are easy and efficient to navigate both forwards and backwards, whilst the use of statnums keep the initialisation process efficient by avoiding iterating over every sprite in the map multiple times.

Special case is locator with palette 21. This says "group _every_ sprite in this sector together (linked list again) and associate it with a locator path (via 'extra'). The locator subsequently follows the path group, dragging with it all those sprites that had originally been in the same sector. Thus you create flying objects out of sprites.

For the mapper, they simply need to (1) define a locator path, lotag 0,1,2,3.... all with same 'extra' (2) in another sector draw whatever object they like out of sprites (3) stick a locator (pal21) in that sector and presto they have a flying object. Simple to set up - easier than setting up a subway!. Wouldn't dream of having a mapper type in sprite ID's !!!

Path locators can also used for elevators, making multi-floor elevators trivial for the mapper.

I can only link between locators using ID, ergo ID mustn't change. I *know* it doesn't change once you start getting EVENT_GAME so my prototype version did a special check in EVENT_GAME to see it this was the first such event and if so built the groups at that point.

Consider what would happen if in EVENT_LOADACTOR I tried to initialise a group - some sprites might not be initialised so (if my theory is correct) their ID's may subsequently change => disaster and it is in fact exactly what happened to me. Debugging CON code is not the easiest of things and it took some time for the penny to drop.

I'm now re-writing it all as a puka library so time to do it properly. Now that I've played around with what events fire when and yes, learnt a lot more about how the Eduke environment works, I *think* EVENT_ENTERLEVEL is where I should build the groups. But ever since the PITA I suffered when I first came across sprite ID's changing I've been paranoid about sprite ID's, hence questioning EVENT_ENTERLEVEL.

TTFN,
Jon

[Danukem]

What you are doing is very nifty and useful. I once talked about doing something similar myself, but then I got lazy. To augment your feature, I would suggest having the mapper tag one of the sprites in the construct as the central pivot point (optional). Then when it moves around, you can use rotatepoint relative to the central sprite to turn the construct appropriately as it is moving along the locators. That would be very good for vehicles.

The Mechanic, on 30 November 2015 - 09:06 AM, said:

For each sprite with statnum B
Search sprites with statnum A with a matching "extra" so as to find the head of the group
Insert sprite into head sprite's linked list of locators in the appropriate relative position (based on "lotag").

What statnums are you using? Some of them have hardcoding that could cause trouble. If you can do it safely, it is efficient. A somewhat less efficient but still manageable solution would be to use gamearrays to hold the IDs of the sprite constructs. Then you would only need to loop through (filled elements of) the arrays, not all the sprites in the map.

The Mechanic, on 30 November 2015 - 09:06 AM, said:

I can only link between locators using ID, ergo ID mustn't change.

You lost me here. Why can you only link them using ID?

[The Mechanic]

Trooper Dan, on 30 November 2015 - 10:52 AM, said:

What you are doing is very nifty and useful. I once talked about doing something similar myself, but then I got lazy. To augment your feature, I would suggest having the mapper tag one of the sprites in the construct as the central pivot point (optional). Then when it moves around, you can use rotatepoint relative to the central sprite to turn the construct appropriately as it is moving along the locators. That would be very good for vehicles.

This is still the area I'm mulling over. At the moment I had thought of using ang as something easy for the mapper to set initial enabled/disabled state, but it might better be used to specify an angle that the collection of sprites should rotate to, gradually rotating as it progresses locator-to-locator. The necessary angle could also be infered from the positions of the locators in the path, in fact that'll probably have to be the way it works since the locators can be moved so paths can dynamically change.

Whatever, a group of sprites are pulled along by a special locator (pal21) and hence the plan is they would rotate around that special locator.

Trooper Dan, on 30 November 2015 - 10:52 AM, said:

What statnums are you using? Some of them have hardcoding that could cause trouble. If you can do it safely, it is efficient. A somewhat less efficient but still manageable solution would be to use gamearrays to hold the IDs of the sprite constructs. Then you would only need to loop through (filled elements of) the arrays, not all the sprites in the map.

To date I've tried to minimise statnum usage.The only statnum I' relying on in-game is 333, which I use to mark activator targets. I'm using 334 as head locator statnum, 335 as general locator statnum but these are only required during initialisation, whereupon they change to 333 if they have "activation"-type functionality or 0.

I dont want to use gamearrays as that would limit the number of paths and/or locators in path - or be a very big array This way costs just two per-actor gamevars and I reuse those gamevars for other purposes in other effects.

In the prototype, I didn't use statnums but instead a sort of double linked list - it worked but was _way_ overcomplicated. The statnum method of initialisation is a good compromise of processing efficiency and ease of coding.

Trooper Dan, on 30 November 2015 - 10:52 AM, said:

You lost me here. Why can you only link them using ID?

Consider 4 locators in this order : 3, 10, 6, 20. They need to be given the following "psprite" and "nsprite" values

Sprite psprite nsprite
3 -1 10
6 10 20
10 3 6
20 6 -1


How else can, for example, sprite 10 record that it's preceeding locator is sprite 3 ?

TTFN,
Jon