[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

[Danukem]

The Mechanic, on 30 November 2015 - 01:33 PM, said:

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 ?

Sorry, I wasn't being clear. I was thinking about the original problem of having sprite ID change from what it says in the map file to what they are in-game. I don't see why that matters. You still have the correct order of the locators due to their tags. Then, assuming that "psprite" and "nsprite" are your own vars, you just use those IDs and put them in the vars. Also, I know you said you weren't using arrays, but that would be another possible solution here. If a locator corresponds to element i in the locator array (which is an array of sprite IDs), then i-1 would be the ID of the one before i, and i+1 would be the one after i.

[The Mechanic]

Trooper Dan, on 30 November 2015 - 01:45 PM, said:

Sorry, I wasn't being clear. I was thinking about the original problem of having sprite ID change from what it says in the map file to what they are in-game. I don't see why that matters.

All depends when you initialise this table. Lets say in EVENT_LOADACTOR you detect a locator with lotag 0, palette 0 i.e. the head locator of a path. At this point you could then iterate through every sprite in the game looking for associated locators - issue is that (if my theory is correct) the ID's of the locators may change before the game starts, I suspect depending upon whether their own EVENT_LOADACTOR has occured or not.

Anyhow, I'm 90% sure that the situation is this:

* A sprite's ID becomes fixed immmediately prior to it's associated EVENT_LOADACTOR ...
* ... in which case the later EVENT_ENTERLEVEL all sprites have been initialised, their ID's will now be fixed so I can quit worrying, waffling on and safely build my linked lists.

TTFN,
Jon

[Mblackwell]

That's why I said ages ago that you should use an array with an algorithm and insert the ids into ordered slots (based on tags) at run time. That's what I do with waypoints. I think I even posted my formula.

[The Mechanic]

Mblackwell, on 30 November 2015 - 03:44 PM, said:

That's why I said ages ago that you should use an array with an algorithm and insert the ids into ordered slots (based on tags) at run time. That's what I do with waypoints. I think I even posted my formula.

The issue was with sprite ID's and when they become stable.

I agree a 2D array could be used, with dimensions (max num paths) * (max num locators in each path), it's a totally valid way to do it, if you know max number of paths and locators in advance.

I have groups of sprites. I have groups of locators. I have groups of other types of effects too. Instead of creating individual fixed size arrays for each of them and choose some arbitary fixed sizes, I've chosen to use linked lists; only two per-actor gamevars required, they get used by whatever I'm trying to group, nice and consistent, and things that aren't related to groups can get to re-use those gamevars for whatever it is they are doing. Flexible too; take the list of locators, the lotags dont have to be 0, 1, 2, 3 etc, more likely I'd use 0, 10, 20, 30 as then if I feel I need to insert an "inbetween" locator to tweak the trajectory I insert a locator I can do it without having to renumber the ones that follow.

No, on the whole I'm happy with the linked list approach, my problem was worrying over sprite ID's which would be a problem regardless of whether I use arrays or linked lists.

If I had a specific map, or set of maps, that I were targetting then I might reconsider arrays as I'd then know exactly what size they'd need to be and it could well be more efficient than lumbering every sprite in a map with two additional vars. But for a general purpose lib, far better to have no arbitary limits.

Anyhow, as nobody has said that initialising my groups in EVENT_ENTERLEVEL is wrong, which was the original question, I'm gonna assume it _is_ the right place.

TTFN,
Jon

[Danukem]

The Mechanic, on 30 November 2015 - 05:13 PM, said:

Anyhow, as nobody has said that initialising my groups in EVENT_ENTERLEVEL is wrong, which was the original question, I'm gonna assume it _is_ the right place.

Let us know how that turns out. I honestly don't know the answer. Prior to this thread, I would have said that using EVENT_LOADACTOR is completely safe for this kind of thing. I use it for tons of stuff, myself. For example, in WGR2 I have various torches and other sprites spawn dynamic lights of the appropriate color which are made to flicker, and those lights have the sprite IDs of the sprites which spawned them. Never had a problem with it. However, when I looked at my waypoint initialization code just now, I noticed I have it happening after map load, in the player actor when player_par == 1. Since I generally don't like doing things like that in the player actor, that strongly suggests that there was a problem when I tried it at map load. Sorry to say, my memory is poor enough and I coded it long enough ago that I just don't remember.

[Kyanos]

I want to addphealth more than MAXPLAYERHEALTH in an actor other than ATOMICHEALTH to avoid the hardcoded lights.

Is this possible at all?

I've tried getplayer[THISACTOR].extra adding to that and then setting it, but even that wouldn't let me go over 100 health.

[Hendricks266]

getplayer[THISACTOR].i temp
setactor[temp].extra 200

Works for me.

Also, you can disable a sprite's hardcoded Polymer lights with SFLAG_NOLIGHT.

[Fox]

Drek, on 21 December 2015 - 01:55 PM, said:

I've tried getplayer[THISACTOR].extra adding to that and then setting it, but even that wouldn't let me go over 100 health.

You sure you wasn't using God Mode?

[Kyanos]

Hendricks266, on 21 December 2015 - 02:29 PM, said:

getplayer[THISACTOR].i temp
setactor[temp].extra 200

Works for me.
Also, you can disable a sprite's hardcoded Polymer lights with SFLAG_NOLIGHT.

Thanks, I guess dealing with the setplayer command instead of the actor directly was the issue.

Fox, on 21 December 2015 - 02:59 PM, said:

You sure you wasn't using God Mode?

Yeah, I did this...

getplayer[THISACTOR].extra temp
addvar temp 2
setplayer[THISACTOR].extra temp

I knew the code would run because the pickup would disappear and the sound would play, but no health would be added over 100.

[Fox]

Setactor.

[The Mechanic]

What is the correct way to destroy a sprite during a game ? I'm specifically thinking decorative sprites.

Setting the sprite's statnum to 1024 certainly does the trick - only it automatically destroys EVERY sprite in the same sector in one go and if one of those other sprites happens to be an enemy then it hangs Eduke !!

OK, in this instance setting the decorative sprite's cstat to 32768 is a viable alternative, but what is it about writing to statnum directly and if I did want to destroy an enemy how would I do that (assuming the enemy I want rid of is not THISACTOR so can't use killit) ?

TTFN,
Jon