[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

[Fox]

Don't set the statnum to 1024, that's asking for problems. You can delete other sprites by setting their x/yrepeat to zero. It doesn't work with certain sprites such as projectiles, but it should do the job with decorative sprites or enemies.

[Kyanos]

early morning answer is to try sizeat 0 0


edit; foxs answer was on the next page I didn't get to read... opps

[The Mechanic]

Fox, on 31 December 2015 - 05:18 AM, said:

Don't set the statnum to 1024, that's asking for problems. You can delete other sprites by setting their x/yrepeat to zero. It doesn't work with certain sprites such as projectiles, but it should do the job with decorative sprites or enemies.

This doesn't really delete sprites, for example the Box (spritenum 951) vanishes but if an RPG subsequently lands nearby it still catches fire.

Works fine for enemies though, provided you manually adjust the kill count with addkills 1.

TTFN,
Jon

[Danukem]

First, I would change the sprite's statnum to 1 (make it an actor). Use the changespritestat command for that so that the linked lists of statnums is updated. Now that the sprite is statnum 1, it will run actor code in EVENT_GAME or if you have it defined as an actor and you can use the killit command on it. Or, changing its size to 0 0 might actually delete it at that point.

[The Mechanic]

Trooper Dan, on 31 December 2015 - 10:08 AM, said:

First, I would change the sprite's statnum to 1 (make it an actor). Use the changespritestat command for that so that the linked lists of statnums is updated. Now that the sprite is statnum 1, it will run actor code in EVENT_GAME or if you have it defined as an actor and you can use the killit command on it. Or, changing its size to 0 0 might actually delete it at that point.

Ah-ha ... I have a number of per-sprite vars which are actually only used by a few non-decorative sprites, so I could changespritestat 1, set one of these now spare vars to flag as "delete me" which I can then detect in EVENT_GAME. Cheers.

TTFN,
Jon

[Danukem]

I changed a line of code and it introduced a divide by zero error in a distant part of the code (a value that couldn't have been zero before now could be). The compiler of course tells me exactly which line of code was trying to divide by zero...and it made me remember a darker time. It was about 8 years ago that a forum member named Hunter_Rus introduced the feature whereby the compiler actually tells you what line of code is fucking up. Before then, you would get an error or warning but you had no idea where in the code it happened. Debugging was so much harder back then.

[The Mechanic]

Trooper Dan, on 03 January 2016 - 11:16 AM, said:

Before then, you would get an error or warning but you had no idea where in the code it happened. Debugging was so much harder back then.

'Course, we 'ad it 'ard, we used to live in't shoe box in middle of t'road. Kids these days don't know they're born.

One debug thing I'd really like to see is being able to output text in addlogvar; I'm using temp1, temp2, temp3 ... etc shared between loads of functions, would be nice if I could have:

addlogvar temp1 spriteId

with text "spriteId" written to logfile instead of text "temp1". When trying to debug something with 3 or 4 "temp" vars dumped out it can get a trifle confusing.

TTFN,
Jon

[The Mechanic]

Is it possible to detect the version of eduke that is running ? There are two types of detection I'd like.

The first is within actual CON functions as it'd be nice to detect if user could be alerted if they are using an incompatible version. For example:

Quote

---------------------------------------------------------------- --------
r5492 | hendricks266 | 2015-12-26 07:41:59 -0800 (Sat, 26 Dec 2015) | 3 lines

Add new spriteflag SFLAG_GREENSLIMEFOOD = 8388608, which controls whether GREENSLIME will eat a given actor.

The flag is automatically set on LIZTROOP, LIZMAN, PIGCOP, and NEWBEAST, .....

Excellent ! Now NEWBEASTHANGING can be made edible like it should have been in the first place. But if I make a map that relies on this feature then it'd be nice to find some way of warning the player e.g. if old version of eduke then automatically open a door sector which exposes wall with writing on that tells them they have the wrong version.

The other version detection that'd be nice is to only include a CON file if version >= some number is running as that'd allow libraries to be able to utilise newer features whilst remaining backwards compatible as it were.

TTFN,
Jon

[Mblackwell]

There used to be a command "enhanced", but it's not functional anymore.

You could always use EVENT_INIT and echo a quote with a required version string. However if it's something that will error out on older versions then I have no idea.

[Danukem]

I know this was covered a long time ago, but could someone explain why it would be prohibitively difficult to enhance CON language so that we can do things like this:

addvar sprite[THISACTOR].z 1024

A great deal of writing CON code involves getting struct members into variables and then manipulating those variables before putting them back into the structs. It makes for a lot of typing and it reduces readability.

[The Mechanic]

Mblackwell, on 03 January 2016 - 01:29 PM, said:

You could always use EVENT_INIT and echo a quote with a required version string. However if it's something that will error out on older versions then I have no idea.

Kinda what I wanted to hear read. What I mean is it confirms I haven't missed something in the documentation.

Trooper Dan, on 03 January 2016 - 04:47 PM, said:

I know this was covered a long time ago, but could someone explain why it would be prohibitively difficult to enhance CON language so that we can do things like this:

addvar sprite[THISACTOR].z 1024

I could hazard a guess (and only a guess). Firstly it is an example of a read-modify-write operation of which I can't think of any others, everything seems to be a read or a modify or a write.

Secondly I suspect the original code may not be that well structured, why else would there be a need to use seperate "addvar" and "addvarvar" for example ?

But maybe something has changed - I noticed recently (r5499) that "set" can now be used to replace setvarvar, if it replaces setvar as well then excellent (about 1/3rd of my errors these days is using e.g. xxxvar instead of xxxvarvar). It was one of the things that prompted my previous question about being able include a CON file if above a certain version.

Trooper Dan, on 03 January 2016 - 04:47 PM, said:

A great deal of writing CON code involves getting struct members into variables and then manipulating those variables before putting them back into the structs. It makes for a lot of typing and it reduces readability.

Totally agree. It would also save a few temp vars for me as I often find I end up loading struct members into temp vars at start of a function as they get used in multiple paths of the code.

TTFN,
Jon

[Fox]

Trooper Dan, on 03 January 2016 - 04:47 PM, said:

I know this was covered a long time ago, but could someone explain why it would be prohibitively difficult to enhance CON language so that we can do things like this:

addvar sprite[THISACTOR].z 1024

A great deal of writing CON code involves getting struct members into variables and then manipulating those variables before putting them back into the structs. It makes for a lot of typing and it reduces readability.

Because it would be better to use Lua instead of rewriting the entire CON language to become more useful.

[Hendricks266]

Trooper Dan, on 03 January 2016 - 04:47 PM, said:

I know this was covered a long time ago, but could someone explain why it would be prohibitively difficult to enhance CON language so that we can do things like this:

addvar sprite[THISACTOR].z 1024

It has to do with how we represent parameters in bytecode when we parse the CONs. We no longer think it would be prohibitively difficult, but instead a matter subject to cost/benefit analysis on our development time--something which is starting to tilt toward benefit thanks to the Bombshell prequel!

The Mechanic, on 04 January 2016 - 01:58 AM, said:

But maybe something has changed - I noticed recently (r5499) that "set" can now be used to replace setvarvar, if it replaces setvar as well then excellent

Yes!

[Danukem]

The Mechanic, on 04 January 2016 - 01:58 AM, said:

But maybe something has changed - I noticed recently (r5499) that "set" can now be used to replace setvarvar, if it replaces setvar as well then excellent

Check out the list in the latest gamedef.c under "const tokenmap_t altkeyw"

[Zaxtor]

What is the code again for "Auto aiming/target"
Like when you shoot a mob that moves or you don't perfectly point at it, you will still hit it with your weapon.

[Mblackwell]

Afaik any actor flagged as an enemy will get autoaimed at.

[Zaxtor]

works only on actors or
Actors and user actor as long it has "enemy"
Not notenemy?

[Mblackwell]

Correct

Actors and Useractors as long as they are "enemy" type.

[Zaxtor]

You know we have setsector[THISACTOR].floorstat xxx and setsector[THISACTOR].ceilingstat xxx
That makes floor and ceiling blockable, unblockable etc (good for tror etc)
But is there a version for walls , especially redlines wall.
Like making a redline wall blockable, unblockable etc.
Example we put the number of the line so it doesn't change all redlines in the sector.
Only let say wall 9510 that I wanna block or unblock?

[Danukem]

Zaxtor, on 15 January 2016 - 10:40 AM, said:

You know we have setsector[THISACTOR].floorstat xxx and setsector[THISACTOR].ceilingstat xxx
That makes floor and ceiling blockable, unblockable etc (good for tror etc)
But is there a version for walls , especially redlines wall.

http://wiki.eduke32....Cstat%28wall%29

[Zaxtor]

Trooper Dan, on 15 January 2016 - 10:51 AM, said:

http://wiki.eduke32....Cstat%28wall%29

I saw that but do I use it the same as the ceiling and floor?