[Mark]

Ok. I didn't realise your goal was creating something for everyone. Your doin' great, carry on.

[Fox]

The Mechanic, on 03 October 2015 - 04:57 AM, said:

Do you mean unsynchronised between multiple players ? Or something worse ?

Yeah. It's okay to use ifsound to check if a sound should be played. But, for example, sounds are never played if you have sounds off in the menu, so anything that affects the game would break the sync in multiplayer.

[The Mechanic]

Me again. This CON system is driving me _nuts_!

I desperately need an explanation of what is going on with sprite indexes as seen in a CON file and actual sprite numbers I see in mapster and how they might change.

Example: using headspritesect + nextspritesect, during a particular EVENT_LOADACTOR, I'm iterating round some sprites in a sector. In my test map I get three sprites (223,220,208). Fine. I have this:

gamevar myvar -1 2 // Per actor

I use myvar to keep a reference to the next sprite - a linked list. So, 223 has myvar=220, 220 has myvar=208 and 208 has myvar=-1 cos its the last one.

When the game is running, my CON file access sprite 223 only to find it's myvar is now -1 !?!? Wtf !?!? . So, just for a test, I also wrote the myvar values into each sprite's xvel,yvel and zvel (just to be thorough) and used DNDEBUG to dump a map and see what the hell is going on. Well, the three sprites in the sector all have xvel,yvel and zvel as I'd expected - only the the sprite numbers are different - according to mapster, they are sprites 219, 216 and 204. In effect, they've been moved down by 4. I've noticed these sprites get set an "owner", e.g. sprite 219 has an owner of 223 and so forth.

Purely for test purposes I subtracted 4 from the myvar values. As expected I now accessed the correct sprite number - 219 instead or 223 - and (....drum roll...) the sodding value of myvar was still -1

I've clearly missed something fundamental - but what ? How _should_ I be keeping a reference to specific sprites ? Could something happen during the game that could cause sprite numbers to re-arrange yet again ? Or can I assume that prior to the first EVENT_GAME sprite data moves around but once the first EVENT_GAME occurs the sprite data finally stays put ?

TTFN,
Jon

[Mblackwell]

Question(s):

Why are you doing the iteration in LOADACTOR?
What's your goal?
Did you remember to use s/getactorvar[actorid].myvar ?


If the sprites are being spawned at any point (beyond initial load) the IDs can definitely change. Nothing to do with CON, it's the engine itself.

[The Mechanic]

Mblackwell, on 05 October 2015 - 12:12 PM, said:

Question(s):

Why are you doing the iteration in LOADACTOR?
What's your goal?
Did you remember to use s/getactorvar[actorid].myvar ?


If the sprites are being spawned at any point (beyond initial load) the IDs can definitely change. Nothing to do with CON, it's the engine itself.

I'm grouping sprites together during initialisation so I can subsequently manipulate them as group of sprites.

As an example, I've a custom "locator" sprite which get grouped together (via hitag) in a user defined order (lotag) in order to define a path, imagine the overhead of sorting that little lot on every game tic. Then there is grouping regular sprites - such as a platform made of regular sprites - which are linked together in a group and follow a path defined by those locators. Pretty much impossible if the sprite indexes keep moving around.

If I can't reliably identify the exact same sprite on different game tics then that pretty much destroys a lot of what I'm wanting to achieve

TTFN,
Jon

[Fox]

If I get it, you are using the hitag to store the ID of another sprites? That's a no-no. Sprites are not supposed to keep their ID when the map is loaded by the game.

[Mblackwell]

You should always save hi and lo tags into a var and then set them to 0, I assume you're doing that already.

A couple of better bets might be:

1) Use custom statnums and headspritestat. (This is great for random stuff)

2) A better method still for LOCATOR type things would probably be to create arrays with offsets. To do it of course you'll need to figure out the max/how many points you want in each path. The hitag would be ordered rather than a random unique number. Each mylocator would simply have to insert its sprite id at position mylotag*MAXPOINTS+myhitag in the array. So for 30 separate paths with 30 different points you'd need an array size of 930 (actually you'd get 31 paths I think due to path 0 but I'm not going to do the math atm). Then individual actors just need to traverse their assigned set of mylocators.

[The Mechanic]

Fox, on 05 October 2015 - 04:23 PM, said:

If I get it, you are using the hitag to store the ID of another sprites? That's a no-no. Sprites are not supposed to keep their ID when the map is loaded by the game.

No. The hitag is used as the "channel" that marks an actor as part of that group. The idea was during initialisation this would be used to set up linked list pointers (implemented as per-actor gamevars). Where sorting was needed that was done via lotag. Advantages:
1) After initialisation, lotag and hitag are redundant
2) When I fire an activation (a jonz version at this point in time) I just scoot across the first sprites in the group and flag that they've been activated and need to do something when it is their turn.
3) When moving a group of sprites they absolutely have to move at exactly the same time and not wait for their respective EVENT_GAME calls else they will flicker. A linked list of exactly the ones to move is quick and simple.

All in all a brilliant plan - right up to the point where ID's change

The effects are totally configured via standard mapster, so primarily they need configuring via lotag/hitag, 'extra' if I need a bit more, and so on (I've a csutom mapster with a menu system which will simplify this setup, but the effects will always be configurable via standard mapster). Part of initialisation is to stash these values and if necessary reset them. With very few exceptions, I leave standard sprite array data well alone after initialisation.

Mblackwell, on 05 October 2015 - 07:08 PM, said:

You should always save hi and lo tags into a var and then set them to 0, I assume you're doing that already.

Indeed. Other than borrowing a few flags in cstat (which has some debugging advantages) I'm avoiding reusing standard sprite variables.

Mblackwell, on 05 October 2015 - 07:08 PM, said:

A couple of better bets might be:

1) Use custom statnums and headspritestat. (This is great for random stuff)

I didn't think I could use statnum (wiki page) as I infered it might change in, or influence, the game operation.

"Unassigned status numbers are reserved for future EDuke32 features. Please ask the developers to allocate an official user statnum range for CON-side features, should this be desired." You start the petition to allocate statnum > 1024 for user defined use whilst I print the campaign t-shirts and mugs With luck, the Eduke developers need do no more than update the wiki so very little effort required?

Mblackwell, on 05 October 2015 - 07:08 PM, said:

2) A better method still for LOCATOR type things would probably be to create arrays with offsets.

Do you mean that, using my previous example sprites {223,220,208}, their ID's may move but their relative ID's will always be the same e.g. {222,219,207}, or {23,20,08} etc ? Otherwise I don't see how an array will help.

Mblackwell, on 05 October 2015 - 07:08 PM, said:

To do it of course you'll need to figure out the max/how many points you want in each path. The hitag would be ordered rather than a random unique number. Each mylocator would simply have to insert its sprite id at position mylotag*MAXPOINTS+myhitag in the array.

But the ID changes and its been suggested this isn't just on completion of initialisation but also if during the game something is spawned.

Mblackwell, on 05 October 2015 - 07:08 PM, said:

So for 30 separate paths with 30 different points you'd need an array size of 930 (actually you'd get 31 paths I think due to path 0 but I'm not going to do the math atm). Then individual actors just need to traverse their assigned set of mylocators.

Again, how do they find their associated locators as the ID's of these locators may change?

OK, example. My group of sprites, lets say {42,69}, are moving from locator 100 to locator 110. Suddenly, something is spawned and causes sprite ID's to change, lets say my locators are now 98 and 108 and group of sprites {22,49}. How does my group of sprites find these locators? Bear in mind this is unsynchronised, that is, the group of sprites may move after the locator's ID's have changed but before the locator's have been processed so that they could update some table to reflect their new ID's ?

AH! (lightbulb finally flickers into life), maybe I've just seen where you were going. Assign each group a unique statnum value and use this as the linking mechanism e.g. sprites with statnum 1025 follow the path of locators statnum 1234. I'll take a peek in the code for the size of statnum - if I'm _real_ lucky I could simply use statnum = 1024 + original hitag value. No need for any extra tables at all. Mblackwell, I owe you one.

Right, off to re-write half me darn code

TTFN,
Jon

[Edit] Sprites that are blocking, hitable and have hitag (=>destructable) have their statnums set to 17 so above method for grouping needs to be to iterate all sprites with matching statnums AND all sprites with satnum 17 and matching hitag. Given I'm not interacting with enemies,players,weapons,projectiles and so forth- only inanimate objects - additional checking for statnum 17's is the only extra effort I need. I hope.

[Mblackwell]

For the array method (using gamearray) you'd do the filling of array elements AFTER load (in the actor code) so the ids would already be set.

If you decide to go the route of using statnums instead you need to do something like changespritestat within each actor AFTER they have loaded and set all of their proper parameters, and make sure it is a completely unused statnum. At that point they will become non-actors, and you'll require an external loop to cycle through all of the elements.

[December Man]

How to modify the genericshrunkcode like the genericgrowcode? Changing what is spawning upon stomping the shrunken enemy etc.?

[The Mechanic]

Mblackwell, on 06 October 2015 - 05:07 AM, said:

For the array method (using gamearray) you'd do the filling of array elements AFTER load (in the actor code) so the ids would already be set.

Previously you mentioned ...

Mblackwell, on 05 October 2015 - 12:12 PM, said:

If the sprites are being spawned at any point (beyond initial load) the IDs can definitely change. Nothing to do with CON, it's the engine itself.

... which, rightly or wrongly, I interpreted as meaning all sprite ID's could change after something spawned during the game ?

Mblackwell, on 06 October 2015 - 05:07 AM, said:

If you decide to go the route of using statnums instead you need to do something like changespritestat within each actor AFTER they have loaded and set all of their proper parameters, and make sure it is a completely unused statnum. At that point they will become non-actors, and you'll require an external loop to cycle through all of the elements.

Well, it seems my idea of using statnum=1025+original hitag is a non-starter as you cant write values above 1025 to cstat. Rats. Interestingly, setting a sprite's statnum to, say, 130 sees it persist into the game (rem: I'm talking inanimate actors like wall sprites, that kinda thing) and it's EVENT_GAME is still called. (Just to be clear, I've no intention of requiring a user to modify a statnum via mapster to achieve anything, this was just a test to see if a statnum got destroyed anywhere during initialisation).


I've gone round the design loop so many times I'm getting a bit dispondant. Can you confirm that a sprite ID won't ever change under any circumstances _after_ initialisation i.e. if I'm in EVENT_GAME and it is called with THISACTOR of say 20, then that sprite will for ever more be sprite 20 irrespective of any spawning or conversely destruction might occur in the game? Sorry to labour this point but this need to group things is pretty fundamental to some of the things I'm trying to achieve.

If the sprite ID's after initialisation do stay put then I'll return to my list method to define a group but instead of then having a list that links between groups I'll use statnum to mark, say, the primary sprite in a group, a different statnum to mark other game sprites of mine, etc so that way I can easily iterate through the relevant groups (which I guess is kinda what statnum is intended for). Does this sound reasonable?

TTFN,
Jon

[Hendricks266]

December Man, on 06 October 2015 - 07:16 AM, said:

How to modify the genericshrunkcode like the genericgrowcode? Changing what is spawning upon stomping the shrunken enemy etc.?

We're not going to give this one to you. You need to learn how to script for yourself. It's possible to understand the entire process by reading the existing code. It's essential if you want to script anything of significance.

[Perro Seco]

I always wanted to make a splash sound when the player enters a water sector, but I can't find a way to do it. All I get is an infinite loop of sound while the player is on water... Somebody knows how to do it?

[Mblackwell]

The Mechanic, on 06 October 2015 - 07:34 AM, said:

I've gone round the design loop so many times I'm getting a bit dispondant. Can you confirm that a sprite ID won't ever change under any circumstances _after_ initialisation i.e. if I'm in EVENT_GAME and it is called with THISACTOR of say 20, then that sprite will for ever more be sprite 20 irrespective of any spawning or conversely destruction might occur in the game? Sorry to labour this point but this need to group things is pretty fundamental to some of the things I'm trying to achieve.

If the sprite ID's after initialisation do stay put then I'll return to my list method to define a group but instead of then having a list that links between groups I'll use statnum to mark, say, the primary sprite in a group, a different statnum to mark other game sprites of mine, etc so that way I can easily iterate through the relevant groups (which I guess is kinda what statnum is intended for). Does this sound reasonable?

TTFN,
Jon

Correct, after initilization any sprites that exist will have their ids set in stone and anything spawned in-game with espawn will give the correct id via RETURN.

Edit:
I'd probably just do a thing like this

gamearray MYLOCATORS    930 // Max Groups * Max Points + Max Points/Position
gamevar INIT            0 2
gamevar TEMP            0 0
gamevar L_GROUP         0 2
gamevar L_POSITION      0 2

define MAXPOINTS        30
define MYLOCATOR        3585

eventloadactor MYLOCATOR
    getactor[THISACTOR].hitag L_GROUP
    getactor[THISACTOR].lotag L_POSITION
    setactor[THISACTOR].hitag 0
    setactor[THISACTOR].lotag 0
enda

useractor notenemy MYLOCATOR
    ifvare INIT 0
    {
        cstat 32768
        setvarvar TEMP L_GROUP
        mulvar TEMP MAXPOINTS
        addvarvar TEMP L_POSITION
        setarray MYLOCATORS[TEMP] THISACTOR
        setvar INIT 1
    }
enda


eventloadactor someenemyorsomething
    getactor[THISACTOR].hitag L_GROUP
    setactor[THISACTOR].hitag 0
enda
useractor someenemyorsomething
    loop through L_GROUP * MAXPOINTS + until you hit a 0/unfilled ID,
    doing comparison to find the nearest point and use that as your
    start position and then iterate through it and do some facing
    code and other nonsense to move it in the appropriate direction.

    You could also use this same type of code to build
    groups of effects actors or whatever else.
enda

[Mblackwell]

Perro Seco, on 06 October 2015 - 10:32 AM, said:

I always wanted to make a splash sound when the player enters a water sector, but I can't find a way to do it. All I get is an infinite loop of sound while the player is on water... Somebody knows how to do it?

Use a var! I'm guessing you're checking ifonwater, right? If you use a var you can say something like

gamevar ON_WATER 0 1

actor APLAYER
    ifonwater
    {
        ifvare ON_WATER 0
        {
            soundonce SPLASHSOUND
            setvar ON_WATER 1
        }
    }
    else
        setvar ON_WATER 0
enda

[Perro Seco]

Mblackwell, on 06 October 2015 - 01:46 PM, said:

Use a var! I'm guessing you're checking ifonwater, right? If you use a var you can say something like

gamevar ON_WATER 0 1

actor APLAYER
    ifonwater
    {
        ifvare ON_WATER 0
        {
            soundonce SPLASHSOUND
            setvar ON_WATER 1
        }
    }
    else
        setvar ON_WATER 0
enda

I was using a var, but I couldn't get what I wanted. Whit your code it works great now. Thank you!

[Mblackwell]

You're welcome!

[The Mechanic]

OK, I give in, how do you use 'movesprite' ?

When originally planning I did a test, simply moving a decorative sprite during EVENT_GAME. I did:

movesprite THISACTOR 64 0 -128 65537 tempy

Behold, a sprite slowly and smoothly moving.

Now time to use it in anger and its not working as advertised; during EVENT_GAME I need to initialise the position a decorative sprite and I use 'movesprite' to achieve it, completely ignoring the sprite in later EVENT_GAME's i.e. this is a one-off move. Result ? Eduke32 bizarely can't make its mind up, sometimes it draws the sprite in its initial position, sometimes in various positions in the general direction of (but not the correct) position, rapidly flickering between the various psotions. If I use DNDEBUG and look at the resulting map, the sprite has moved HALF WAY towards where it should be.

So, for test purposes, I revert to the original test movesprite to initialise the decorative sprite's position (which is a very small movement) but I still see the sprite shimering.

I have some per-actor variables, but when the sprite is moved every one of the standard sprite struct variables is as they'd normally be.

TTFN,
Jon

[Edit] If I manually add the required deltax, deltay and deltaz to the sprite's position then I get an improvement; instead of flickering between original position and half way towards the final position, it now flickers between the old and new position (and a few positions inbetwwen).

[Fox]

The Mechanic, on 08 October 2015 - 01:05 PM, said:

OK, I give in, how do you use 'movesprite' ?Now time to use it in anger and its not working as advertised; during EVENT_GAME I need to initialise the position a decorative sprite and I use 'movesprite' to achieve it, completely ignoring the sprite in later EVENT_GAME's i.e. this is a one-off move.

That's intended. As the name indicates, it simply moves the sprite. You have to set it every tic you want the sprite to move.

The Mechanic, on 08 October 2015 - 01:05 PM, said:

Result ? Eduke32 bizarely can't make its mind up, sometimes it draws the sprite in its initial position, sometimes in various positions in the general direction of (but not the correct) position, rapidly flickering between the various psotions.

That sounds like an interpolation problem. By default sprites have two values for the coordinates, which is used to smoothen the movements up to 120 frames per second compared to the in-game time of 30 frames (tics) per second. Add this before you use movesprite:

setactor[THISACTOR].htbposx sprite[THISACTOR].x
setactor[THISACTOR].htbposy sprite[THISACTOR].y
setactor[THISACTOR].htbposz sprite[THISACTOR].z

The Mechanic, on 08 October 2015 - 01:05 PM, said:

If I use DNDEBUG and look at the resulting map, the sprite has moved HALF WAY towards where it should be.

I don't remember if that's the case for movesprites, but in some circumstances the sprite velocity equals half or a quarter of the expected (i.e. build units per tic). So just multiply the value to match your desired velocity.

[The Mechanic]

Fox, on 08 October 2015 - 01:41 PM, said:

That's intended. As the name indicates, it simply moves the sprite. You have to set it every tic you want the sprite to move.

Hmmm ... me thinks the wiki needs modifying, it is to easy to assume 'movesprite' did _exactly_ that, not realising that Eduke might be trying to smoothly move it.

Fox, on 08 October 2015 - 01:41 PM, said:

That sounds like an interpolation problem. By default sprites have two values for the coordinates, which is used to smoothen the movements up to 120 frames per second compared to the in-game time of 30 frames (tics) per second. Add this before you use movesprite:

setactor[THISACTOR].htbposx sprite[THISACTOR].x
setactor[THISACTOR].htbposy sprite[THISACTOR].y
setactor[THISACTOR].htbposz sprite[THISACTOR].z

Bingo ! ... ish. That has sorted the multi-position flickering Only for some reason it only moves half the distance it should.

However it totally fails again if the sprite does not have a hitag However the following seems to work without requiring teh sprite to have a hitag and moves to the correct position, not simply half way (temp1,temp2,temp3 being deltax,deltay,deltaz respectively):

getactor[jactor].x temp5
addvarvar temp5 temp1
setactor[jactor].htbposx temp5
setactor[jactor].x temp5
getactor[jactor].y temp5
addvarvar temp5 temp2
setactor[jactor].htbposy temp5
setactor[jactor].y temp5
getactor[jactor].z temp5
addvarvar temp5 temp3
setactor[jactor].htbposz temp5
setactor[jactor].z temp5
// TODO : Will need to manually update sector number if crossing sectors

Fox, on 08 October 2015 - 01:41 PM, said:

By default sprites have two values for the coordinates, which is used to smoothen the movements up to 120 frames per second compared to the in-game time of 30 frames

Ah-ha ! That makes sense now as I thought I could see the sprite being displayed in four different positions. Guess I need a bit of a think - EVENT_GAME is 30fps-per-actor which is where I intend to be moving a sprite but looks like it'll be a lot smoother if I can use this interpolation. Perhaps use brute force position calcs for instant move, then during move between points (locators) switch to using movesprite.

Fox, on 08 October 2015 - 01:41 PM, said:

I don't remember if that's the case for movesprites, but in some circumstances the sprite velocity equals half or a quarter of the expected (i.e. build units per tic). So just multiply the value to match your desired velocity.

I didn't want to just double the value, not knowing the cause. However it seems that you cant use movesprite to move sprites that aren't destructable

Anyhow, 'htbpo*' is the key to getting this working right, cheers Fox.

TTFN,
Jon

[Mblackwell]

Depending on your CLIPMASK you might be colliding with other sprites or walls unexpectedly as well.

For a simple movement/offet of X,Y,Z build units assuming you don't need to see it move just setting the correct x,y,z is enough rather than bothering with movesprite.

In all cases (setting x,y,z or using movesprite) it's a good idea to call updatesectorz and set the sprite's current sector to the correct one.

[The Mechanic]

Mblackwell, on 08 October 2015 - 02:42 PM, said:

Depending on your CLIPMASK you might be colliding with other sprites or walls unexpectedly as well.

For a simple movement/offet of X,Y,Z build units assuming you don't need to see it move just setting the correct x,y,z is enough rather than bothering with movesprite.

In all cases (setting x,y,z or using movesprite) it's a good idea to call updatesectorz and set the sprite's current sector to the correct one.

I'm currently using a clipmask of 65537 but I'll probably use 0. When I tried 65537 in my initial tests it was cool to see the sprite reach a wall and move no further in that direction ... although it seems ceilings dont count as blockable as my test sprite went right through it.

Anyhow, the group of sprites I'm moving are following a path defined by "locators" and it is up to the map designer to ensure that the path between the two is valid. As I mentioned in my previous post, I know I need to update the sprites sector too - I shall simply determin sector, if there is no sector (a void) then the afflicted sprite just stays where it is whilst the map designer gets their act together (suitable message in eduke log). I've not reached the point of looking at player or enemy interactions - I'm assuming I'll need to move any actor or enemy currently stood on the sprites manually too?

TTFN,
Jon

[Mblackwell]

I believe the answer to your last question is an enigmatic "it depends". But probably in many cases. I mentioned needing to update the sector since if you don't you get weird glitches (visual and otherwise). So that might be part of your issue if you're not already doing it.

[The Mechanic]

Mblackwell, on 08 October 2015 - 05:08 PM, said:

I believe the answer to your last question is an enigmatic "it depends".

That sounds a bit ominous. More fun ahead

Mblackwell, on 08 October 2015 - 05:08 PM, said:

I mentioned needing to update the sector since if you don't you get weird glitches (visual and otherwise). So that might be part of your issue if you're not already doing it.

Yes, a point worth raising, currently I'm at the stage of working in a single sector. I'm anticipating some issues as when moving between sectors there will be a point where a sprite is crossing a sector boundary; the rendering in the original Duke3d would probably rule out crossing sectors with sprites then potentially not getting rendered but Eduke32 seems a lot better in that respect. We shall see. I beleive movesprite also updates the sector and if I'm lucky (unlikely based on issues so far!) during the game I can return to using this - initialising the position clearly can't use movesprite though.

That lot was supposed to be the easy bit; rotating a group of sprites without accumulating rounding errors is going to be .. um ... "interesting".

TTFN,
Jon

[Fox]

The Mechanic, on 09 October 2015 - 12:33 AM, said:

Yes, a point worth raising, currently I'm at the stage of working in a single sector. I'm anticipating some issues as when moving between sectors there will be a point where a sprite is crossing a sector boundary; the rendering in the original Duke3d would probably rule out crossing sectors with sprites then potentially not getting rendered but Eduke32 seems a lot better in that respect. We shall see. I beleive movesprite also updates the sector and if I'm lucky (unlikely based on issues so far!) during the game I can return to using this - initialising the position clearly can't use movesprite though.

Eduke32 doesn't render sprites from sectors out of reach. That's an optimization issue, there's no reason for the game to render a sprite that you cannot see in first place. Movesprites do update the sector automatically, but you can also use setsprite as a shortcut for modifying the coordinates directly.

The Mechanic, on 09 October 2015 - 12:33 AM, said:

That lot was supposed to be the easy bit; rotating a group of sprites without accumulating rounding errors is going to be .. um ... "interesting".

I am thinking of re-calculating the position in relation to the pivot and subtracting it.

[The Mechanic]

Fox, on 09 October 2015 - 04:40 AM, said:

Eduke32 doesn't render sprites from sectors out of reach. That's an optimization issue, there's no reason for the game to render a sprite that you cannot see in first place.

The issue is when a sprite should be visible by the player but the sector containing the sprite in not in the players field of view, this can make it prone to not being rendered - see attached. However it doesn't always become in an issue in Eduke32 - I guess it must be a bit more clever than the original Duke3D but it does still happen.

Fox, on 09 October 2015 - 04:40 AM, said:

I am thinking of re-calculating the position in relation to the pivot and subtracting it.

Lets say it takes 5 seconds to move/rotate-90 between two locators. At 30 calcs per second that is rotating a tiny 90/150 degrees at a time. When rotating a sprite about pivot point this could lead to accumulation of rounding errors over time. I suspect at initialisation I may have to to store the delta-x and delta-y between a sprite's center and the rotational center and always calculate the rotation-induced position shift relative to those stored values. Sorry, not very good at explaining things, did that make sense ?

TTFN,
Jon

Attached thumbnail(s)

• 

[Fox]

 The Mechanic, on 09 October 2015 - 08:28 AM, said:

The issue is when a sprite should be visible by the player but the sector containing the sprite in not in the players field of view, this can make it prone to not being rendered - see attached. However it doesn't always become in an issue in Eduke32 - I guess it must be a bit more clever than the original Duke3D but it does still happen.

The thing is that sprites should never be outside of their visible sectors. Whenever that happens, it's because of a glitch or an improper code. For example, it's also possible to use CON to connect nonadjacent sectors, which the player would die if he tries to cross a wall. Similarly, sprites outside of their sectors is not something expected by the engine.

 The Mechanic, on 09 October 2015 - 08:28 AM, said:

Lets say it takes 5 seconds to move/rotate-90 between two locators. At 30 calcs per second that is rotating a tiny 90/150 degrees at a time. When rotating a sprite about pivot point this could lead to accumulation of rounding errors over time. I suspect at initialisation I may have to to store the delta-x and delta-y between a sprite's center and the rotational center and always calculate the rotation-induced position shift relative to those stored values. Sorry, not very good at explaining things, did that make sense ?

Eehhh, I suspect my solution wouldn't work. You would have to try yous.

[The Mechanic]

 Fox, on 09 October 2015 - 09:27 AM, said:

The thing is that sprites should never be outside of their visible sectors. Whenever that happens, it's because of a glitch or an improper code. For example, it's also possible to use CON to connect nonadjacent sectors, which the player would die if he tries to cross a wall. Similarly, sprites outside of their sectors is not something expected by the engine.

In my example image, the sprite is in its correct sector, its just that it is bigger than it's sector.

When moving sprites slowly between sectors, there will always be the situation at some point where the center of the sprite is in one sector (and has the correct sectnum value) but part of the sprite is in another sector. It's a case of suck it and see to find out how real a problem it is in practice. If it ends up sucking then I still have vertical movement - multi-floor TROR elevator for example.

It is possible to fudge this; when a sprite crosses two sectors, come up with a plan for adjusting x,y (setting sectnum exactly as per x,y) and then use xoffset and yoffset to nudge it back into the correct position. Compare the attached image with previous one - I've placed the sprite in the player's sector, then manipulated xoffset and yoffset to put it back exactly where it was in the first image. The sprite no longer dissapears. It's a solution - but probably more complicated than it is worth.

TTFN,
Jon

Attached thumbnail(s)

• 

[December Man]

 Hendricks266, on 06 October 2015 - 07:34 AM, said:

We're not going to give this one to you. You need to learn how to script for yourself. It's possible to understand the entire process by reading the existing code. It's essential if you want to script anything of significance.

Ok, thanks for the motivation. I figured it out, but I don't know whether this is the optimal way to do it. Currently, the shrunken enemy dies before Duke actually steps on him.

gamevar TEMP6 -1 1

state genericshrunkcode

  ifcount 32	
  {
      ifactor ENEMY
	{
	  ifpdistl SQUISHABLEDISTANCE
	{
		ifvarvarg player[THISACTOR].actorsqu TEMP6		
		{	
        addkills 1
		sound SOUND
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		killit
		}
		getplayer[THISACTOR].actorsqu TEMP6
		}
		}
	else
		ifactor ENEMY2
	{
		  ifpdistl SQUISHABLEDISTANCE
	{
	    ifvarvarg player[THISACTOR].actorsqu TEMP6
		{
        addkills 1
		sound SOUND
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		killit
		}
        getplayer[THISACTOR].actorsqu TEMP6
		}
		}
		
    ifpdistl SQUISHABLEDISTANCE
    pstomp
  }
  else
  {
    sizeto MINXSTRETCH MINYSTRETCH
    spawn FRAMEEFFECT1
  }
ends

[Mblackwell]

Run pstomp before killit.