[eniojr]

Well, since I started trying to add things to the game months ago, I've come to understand it a lot more than I did before, which is already good progress. What makes it all harder is the fact that I don't know any programming language beforehand, like C/C++, and I'm starting CON from scratch. This programming thing is still very complex for me.

Yes, I still can't create something new from scratch without some consultation or without seeing how the codes were put together like many people here can. But for me, each new thing I manage to add to the game is a step forward and I'm proud of that. If my understanding of the CON language was 0%, I wouldn't have been able to add anything to the game. Maybe my understanding of this language is around 25% in total, or less than that. The basics of the basics.

Having an initial notion of how the codes should be organized is part of the initial learning process and I'm still learning that.

I don't just copy and paste codes! I had to make changes on my own to make it work. If I had just copied and pasted it, it wouldn't have worked at all, because I've tried that myself. Once I simply copied and pasted it into a new CON file and what did it result in? Compilation errors, missing definitions or missing states and events! I thought that just copying and pasting would solve the problem, but on several occasions I had to make adjustments so that the codes would load without compilation errors.

That image of the cards in the HUD, for example, I was the one who put that together, I was the one who specified the position of the icons in the HUD according to the color of the card. It was a little different from the original mod, but it worked and I liked it. Regarding the babes, I added codes so that they would say a line after attacking me, as well as making some of them use lasers and coolexplosion1.

The next step will be to understand how to create civilians that walk around the map and I'll also research that in the mods, but as in the previous cases, I'll also have to make changes so that it's compatible with the Legacy mod. Still in the case of babes, I created definitions for each of them, so that it wouldn't result in conflicts and I'll do the same with the walking civilians. Just like I did with the accesscard.

Creating specific definitions and variables for something helps to avoid conflicts. For example, if you keep using temp, temp1, temp2, etc. for everything, this can end up causing conflicts between several things. I say this because I've tested this several times and it really did end up resulting in conflicts. I've had several problems regarding timer conflicts, among other things of the sort.

Don't forget the fact that I'm still adding effects to an existing mod, which increases the challenge even more, the effort needed to avoid possible conflicts with the mod. So it's no small thing that I'm doing. Days and days trying to make new things work with patience isn't for everyone. At least I had the perseverance and stubbornness to do so.

I still have several other things to do, like creating new objects that explode when hit, for example, or others that emit sound. I've already managed to create code to create new water sources that restore HP, and I also intend to create code so that when you touch an object like plasma you will suffer damage (like an electric shock), with sound, maybe even with some visual effect if it's possible.

I've also added new experimental items. But these items will be more like powerups and medicines than something to be stored in the inventory. But this is still in the early stages of testing. I may be able to create some inventory items, since I managed to do this with cards, although this is a different category of inventory.

I'm really still getting started with the syntax, but at least now I have a better understanding of how codes should be organized in a script, which is certainly an important step. For example, I've already done several tests with cstat, as well as with ifpdistl, ifrnd, ifhitspace, soundonce, define, gamevar, action, ai, ifhitweapon, spawn, spritepal, ifactioncount, picnum and a few others.

As I test code by code and syntax by syntax, I learn more about the syntaxes. Little by little. I am absolutely certain that I can already understand something in this language, that's for sure.

The whole point is that many in this community who deal with CON programming have prior programming knowledge and therefore can better understand the structure of the CON language, and I do not.

I have no technical or academic training in game programming!

The little I understand about CON language is from scratch.

[VGames]

Yes this is where my excess gamevar definitions came from in the beginning of my mod when I was still learning and using code from other mods. They had their own gamevars and so I added them to my defs to make the code snippet work. I need to go back and cut down these extra useless vars.

[Danukem]

VGames, on 17 December 2024 - 06:44 AM, said:

Don’t jump to conclusions. I never said anything like that. I was merely telling you some drawbacks that I’ve seen. I’ve cleaned up the code even further and now have about a 25% increase in performance with noticeable reductions in fps spikes. So far I’ve got all the gibs and gore effects set up on timed releases and I’m currently implementing the same for debris and effects created by explosions. It’s getting better for sure. I’ll do the same for other effects as well to reduce the chances of them being spawned at the same time as much as possible. Then I’m going to look into giving as many actors as possible a custom stat to further reduce fps spikes. This is going very well.

I wasn't jumping to conclusions, I was referring to the specific thing that you told us about. You said you made a separate actor to spawn the jibs so they could be spawned over time, but that it would stop before spawning all of them. Then evidently you gave up on that approach. That indicates that your code didn't work and you didn't know how to debug it. What's puzzling to me is why didn't you present *that* problem and try to get help solving it. I'll bet that could be fixed pretty easily.

[VGames]

I didn’t stop using that actor. I just changed it up by having the actor control the gib spawning directly in its actor code and not in a separate statement. It works fine now.

[Danukem]

VGames, on 17 December 2024 - 12:34 PM, said:

I didn’t stop using that actor. I just changed it up by having the actor control the gib spawning directly in its actor code and not in a separate statement. It works fine now.

Oh you didn't mention that before. The point of that actor was to mitigate the issue of too many jibs spawning at once. So it works fine now and the problem is solved?

[eniojr]

Regarding the codes for the things I managed to make work in the Legacy mod, what remains to be done now is to explore better what each code and syntax can do, in addition to trying some refinements as long as this does not affect the desired effect. Maybe with this I will end up being able to create new variations of effects, who knows? For example, in relation to the jumpad, I could create another variation of jump height or even in relation to the horizontal impulse.

The code is practically ready, I just need to create new definitions, copy the code that already exists and establish a new name for the effect, as well as different values ​​for vertical and horizontal impulse and that's it, I will have a new variation of the jumpad effect. I noticed that there may still be unnecessary codes that I should remove. Some unnecessary lines or words. What is missing is a kind of cleaning up of the codes, so to speak, as well as some simplifications.

But before I start trying to add walking civilians to Duke Nukem Legacy, I'm going to go back to working on breakable objects, because I only added a few more to the total textures related to that, as well as more button effects for new textures, because I only tested that on one texture. In other words, I'm going to focus on the simple stuff for now, and then come back to the complex stuff when I feel more confident with the codes. Because that's when it's going to be for real.

[Reaper_Man]

VGames, on 17 December 2024 - 12:34 PM, said:

I didn’t stop using that actor. I just changed it up by having the actor control the gib spawning directly in its actor code and not in a separate statement. It works fine now.

That doesn't make any sense. An actor running code in a state is not fundamentally any different than running it directly in the actor.

// This code...
useractor notenemy WHAT
{
    [ do some stuff ]
}
enda


// ... Is the exact same as this code.
defstate dosomestuff
{
    [ do some stuff ]
}
ends

useractor notenemy HUH
{
    state dosomestuff
}
enda

If this is actually what you have going on, then you have some other issue somewhere causing problems.

[Danukem]

Reaper_Man, on 17 December 2024 - 05:37 PM, said:

That doesn't make any sense. An actor running code in a state is not fundamentally any different than running it directly in the actor.

It doesn't make sense if that was the only thing he changed, but he must have made changes to the code while moving it out of the state. Maybe the state changed some additional vars because it was made for some other purpose, calling that state changed a var he was using in the spawning loop causing it to end early but he didn't realize the state was changing a var needed to keep the loop going.

[VGames]

If you have Explosion2 call on a state that has timed spawning intervals using count or even some kind of var that you use as a counter it won’t continue after like 1 or 2 counts. It stops for some reason. I haven’t moved that code into the explosion2 code body yet for testing purposes. This was the issue I was having with the new actor I made to handle the gibbing system. I wanted it to use a statement similar to the original standard jibs statement but it would not continue after 1 or 2 counts. There was nothing wrong with the code. I made sure nothing was causing an interruption. It was a very simple setup. Once I moved the code into the actor code body it worked just fine. I ended up splitting up the actor into multiple actors as well to have even more control over the gib spawning times.

I did notice something odd. Doing this timed release for spawning explosion effects, not debris, during an explosion causes more unstable fps then simply having the explosions produce the effects all at once. Why is this? I expected better performance with a timed release system but instead going about having explosions create their effects the old fashioned way keeps performance more stable. It works great for creating gibbed enemy effects but not explosion effects.

[Reaper_Man]

Again, that doesn't make a lot of sense. EXPLOSION2 doesn't have unique properties. Simply spawning sprites wouldn't cause performance issues. I suspect you have some sort of issue beyond the immediate code you're working with.

VGames, on 18 December 2024 - 06:37 AM, said:

It stops for some reason.

There has to be a reason, though. You should try to identify the reason and resolve it. Sure, spawning a new actor and having it do what you need "just works". But like I said before, "just works" is not actually fixing anything or identifying what the problem is.

Without seeing code I can't help you. I suspect the issue lies somewhere beyond the immediate actor code. As I said last time... Isolate the "problem code" into a new clean project. Add some logging. You need to add some debugging outputs to see what the code is actually doing under the hood.

[eniojr]

One thing I learned by observing the codes and their huge blocks full of certain logic that only experienced modders in CON language understand is that the one event EVENT_GAME should always be at the end of a custom file and that there should only be one for each mod, otherwise one could interfere with the other. Furthermore, it seems to me that for those who want to make a new mod or add something to an existing mod for fun, the one event EVENT_GAME is the most complicated part to extract codes to add effects or anything from other mods that depends on it to work.

I've been exploring Dukeplus' EVENT_GAME and now I can get a better idea of ​​how it works and how it should be organized, although there are still codes that I still don't fully understand how they were organized. Knowing how the codes are organized and the reasons for this is an important step for those who want to better understand how the structure of the language for Duke Nukem works. Some people focus on understanding the syntax in more depth first, but in my case, I realized that I first have to understand how the codes should be organized in a script. That way it's easier for me.

Because I learn better by observing patterns first!

Because once I understand more deeply how the codes should be organized in a script, then I'll be able to dedicate myself to studying the specific syntaxes, since by then I'll have a better understanding of the general formatting of the scripts.

I'm currently trying to add some more Dukeplus effects like underwater and some other simpler ones (I think) for Legacy. From what I've edited in the codes inside EVENT_GAME, I've already been able to discard several codes for things I won't use, leaving only those relevant to the effects that I may or may not add later.

I think that most people who start learning how to deal with CON scripts are those who start by creating mods from scratch, while in my case it's a bit more complex, since I'm adding things to an existing mod for fun and because I still intend to create a custom episode for Legacy, containing this extra content...

Who knows, maybe one day I'll release it as a new custom episode for this mod (with the authorization of the Legacy author, of course). When everything is ready, I might give him my episode so he can see whether or not he'll publish it for download.

So that's it, I'm doing my best to better understand the organization pattern of a script in this language, even though I already have some knowledge about how some syntaxes work and what they're for.

[Danukem]

Not an ideal mod for learning how to organize a project. I started DukePlus pretty early on in my modding career in 2007. The original aim was to add some useful effects for mappers. At the time, many of the events such as EVENT_WORLD didn't exist, so of course I used EVENT_GAME for a lot of stuff. The scope of the mod expanded greatly over several years in many different directions. Code added later on tended to be better as I learned and I took advantage of more recent features, but for the most part I stuck with sub-optimal organizational decisions made early on in order to avoid a lot of tedious reworking.

In my estimation, looking at DukePlus as a whole is largely a waste of time, although it does contain many different specific examples of how to achieve certain things -- the catch is you need to already have some idea of what you are looking at before you can learn from it.

[eniojr]

Do you have any suggestions for mods that I can learn from to add new gameplay effects and that might have easier to understand code?

[Danukem]

eniojr, on 20 December 2024 - 07:46 AM, said:

Do you have any suggestions for mods that I can learn from to add new gameplay effects and that might have easier to understand code?

I can't answer that because your understanding depends on skill level, so I'm going to answer a somewhat different question which is: What EDuke32 projects have good CON organization and practices?

That calls for speculation because I don't really look at other CON code bases, but I think Ion Fury likely has very good organization and uses good practices. Mblackwell has been coding in CON for as long as anyone and is about as knowledgeable as can be in that area, and from his posts it seems very likely that would be a well organized codebase using good and efficient techniques. Much the same can be said for Reaper_Man so I would expect the AWOL code to be similarly tidy and up to date using good practices and so on.

My projects tend to suffer from workarounds, bloat, and other issues. That's not to say that I don't have a lot of good code in them to do various things, but you will have a needle in haystack problem if you go in blind.

[eniojr]

I managed to add a sectoreffector effect in Legacy, that Dukeplus effect with a value of 666 in which the player dies when he passes a certain height downwards. It wasn't hard to add such an effect, since it's very simple and doesn't have much code related to other things. But to do that, I had to add the SECTOREFFECTOR case to EVENT_GAME with an "ifvare lotag 666", and then, before EVENT_GAME, a SECTOREFFECTOR eventloader.

The SECTOREFFECTOR eventloader still has all the Dukeplus effects, but since I won't be using them all, once everything is set up I'll remove the unnecessary code. But even so, the game is running well, with a high FPS, without performance problems, perhaps because of my PC's settings.

The underwater effect is too complicated, because it's not just about the effect itself, but because it's necessary to make several objects and actors behave in a certain way, which I couldn't do. To create an underwater effect, I would have to do it myself, based on how the original game's codes related to this are. But I think that for this I would have to transcribe the game's source code into the CON language.

But still, for the first time I managed to add a new sector effect to a mod on my own.

[eniojr]

One question... Could the codes in Ion Fury be used in Duke Nukem or would I have to make an adaptation, that is, in relation to the syntax? The thing is that Ion Fury uses a more recent version of Eduke32 and since it is a much more recent game, it may have a more refined code system. If that is the case, these codes would have to be simplified to be used in Duke Nukem.

[Danukem]

eniojr, on 20 December 2024 - 03:09 PM, said:

One question... Could the codes in Ion Fury be used in Duke Nukem or would I have to make an adaptation, that is, in relation to the syntax? The thing is that Ion Fury uses a more recent version of Eduke32 and since it is a much more recent game, it may have a more refined code system. If that is the case, these codes would have to be simplified to be used in Duke Nukem.

It sounds like you are confusing game engines with games. EDuke32 is the game engine we are using here. Ion Fury is a game that runs on it. Duke 3D is another game which was ported to it long ago. The CON language of EDuke32 is the same regardless of which game. The exe used for Ion Fury is slightly different from mainline but not in any ways that impact syntax. I think the main difference is it doesn't have most of the hardcoded Duke 3D specific stuff (e.g. certain tile numbers being hardcoded to make certain sounds when they spawn).

[Reaper_Man]

eniojr, on 20 December 2024 - 07:46 AM, said:

Do you have any suggestions for mods that I can learn from to add new gameplay effects and that might have easier to understand code?

The problem is how you are approaching problems, logically I mean.

The questions you're asking are "How do I add new Sector Effector effects" or "How do I add ladders" or things like that. Asking about specific effects or specific outcomes.

If you really want a deeper understanding you need to think about WHAT you want in more abstract terms. Your mind needs to think in terms of like "How do I make one sprite communicate with another", for example.

[Mark]

After way too long without it I finally discovered and used a damage event.

damageeventtile 5269
onevent EVENT_DAMAGEWALL
ife wall[RETURN].picnum 5269 setw[RETURN].picnum 5500
endevent

How would I go about chaining another one after that to change 5500 to tile XXXX for multiple levels of damage with every weapon hit? Or is there a better way to go about this?
I'm looking for a smart alternative to my usual useractors and cstats. I want to keep it simple. No complicated
locational damage like used in AWOL. ( I know, poorly worded since wall aren't useractors I meant for sprites and models )

I'm assuming that since 3d models are treated as "sprites" that I could use EVENT_DAMAGESPRITE on them. I might have a question on that later when I tackle it.

And last, probably a simple one but off the top of my head I'm not sure how to do it. I have some 3d model light sources that I am making breakable. I need their accompanying Polymer light SE to get killed along with the model. And I hope the light does indeed stop shining with it's removal. I'm not sure how that works.

[Reaper_Man]

You're on the right track. You can make "progressive" damaging tiles simply by making the picnum you change it to also be a damageeventtile. So in your example, tile 5269 is the starting damage tile that changes to 5500, you then also make 5500 a damage tile and give it logic to change to a third tile ID.

You may need to play around with giving them a "health" or giving them some sort of delay after changing before they will try and cycle damage again, otherwise you may skip tile stages.

In AWOL we only had locational damage for headshots on enemies. Unless you're talking about the "hitpoints per texel" damageable surface stuff. You don't need that to make progressive damage tiles.

3D models are sprites so they should trigger EVENT_DAMAGESPRITE.

Deleting an SE light source should be easy. Figuring out which SE to delete is where it gets hard. You could do something like setting it up so they share a lotag/hitag, and when the map loads you move the tag to a per-actor gamevar. Then when the model/sprite is destroyed, search for SEs with a matching gamevar value and delete it. That's probably the best way to do it.

[Mark]

I did what you said with the damage event but on the first hit it just went from 1st texture to the last and skipped the middle. Just like you said it might. I'll deal with that first and then look into the SE killit. Thanks.

[Danukem]

btw to have additional keycard colors doesn't require all that code that was posted from Nuclear Showdown, or anything similar. You can simply hack the got_access struct by adding new bits for different colors, setting them when the cards are picked up. Then you add a little code for the accessswitches so they know to start activation depending on their color and which bits are set when the player is trying to use them. The card display color when Duke uses the card is "free" because the color of the keycard hand is set by the accessswitch sprite. The only hud thing you have to do is recode the keycard inventory display to show the colors the player is holding.

[VGames]

Is there a way to stop the explosion sound effects that play when the "Duke Nukem", "3D", and "Plutonium" logos fully appear on the title screen without using "stopsound" commands in EVENT_LOGO?

[eniojr]

The way I did (altered and reorganized the codes of Nuclear Showndown) allow 2 Duke's speech for when switch is locked and 2 more Duke's speech for when access granted. I did for all colors including blue, red and yellow, so in my maps, I will only use my custom card and accessswitch system. This means that if you play my maps on Legacy when it's all done, the keycard slot in status bar will always remain empty, because the original accesscard tile won't be used. But it might also be useful if I decide to put the custom card icons in that part of the status bar, but then the card icons would have to be very small to fit all 11 card colors in total.

Is there a way to change the status bar by CON coding or I'll have to hack the source code? Because if it's possible by CON coding I would put something else instead the keycard slot, maybe something for a custom item or different type of key.

[Reaper_Man]

VGames, on 21 December 2024 - 03:42 PM, said:

Is there a way to stop the explosion sound effects that play when the "Duke Nukem", "3D", and "Plutonium" logos fully appear on the title screen without using "stopsound" commands in EVENT_LOGO?

Try EVENT_SOUND to disable the sound entirely, you can check the player.gm property to check if the player is in-game.

eniojr, on 21 December 2024 - 04:07 PM, said:

Is there a way to change the status bar by CON coding or I'll have to hack the source code? Because if it's possible by CON coding I would put something else instead the keycard slot, maybe something for a custom item or different type of key.

You'll likely want to disable the default status bar entirely and start drawing your own.

[eniojr]

Does Ion Fury has that portal renderization effect (to see other rooms through walls with tiles not associated with a texture) such as in Dukeplus or WGrealms2 (in which many effects were copied from Dukeplus)? I'm not even interested in the teleportation effect, but only in that portal visualization effect. That effect in Dukeplus involves "eventloadactor SECTOREFFECTOR" (to allow loading of new custom effects) and "ifvare lotag 88" inside "onevent EVENT_GAME", but there are other codes in which I'm not managing to organize. I would like to know if there is something like this in Ion Fury. If there is, perhaps the codes will be easier to identify.

Additionally, I would like to know how to add the loading of a new state or other changes to the APLAYER actor without having to modify what is in GAME.CON, such as code within a custom CON file associated with APLAYER.


The effect I'm referring to is this:

[Danukem]

eniojr, on 21 December 2024 - 10:25 PM, said:

(in which many effects were copied from Dukeplus)

Hey I'm allowed to copy my own code. But I'm fairly certain that the first version I did was in WGRealms2, then that was ported to DukePlus.

[eniojr]

Oh well, I didn't knew that you did WGrealms. I'm playing that now and it's really good!

From what I understood about the portal renderization:

I tried to get the codes from both Wgrealms and Dukeplus, but something seems to be missing for the effect to work. The way I did on my map was similar to the way you did on yours. The sector effector with lotag 88 acts as a camera, so you have to adjust the sprite angle in direction to where you want the room to show from a wall. The portal wall needs to have a tile without a texture, and that I made it too. Here's how is in my map:


This portal leads to...


this room!


Now this portal leads to the previous room...


That same room with the first part of the portal!


In the 2D section, the direction of the angle of the SE lotag 88 seems correct. The upper part is the brick room and the lower part is the futuristic room.

Now, the codes:

eventloadactor SECTOREFFECTOR 

	getactor[THISACTOR].extra monstflags
	ifvare monstflags -1 setvar monstflags 0
	getactor[THISACTOR].lotag lotag
	getactor[THISACTOR].hitag hitag
	getactor[THISACTOR].xvel initx 
	ifvarg lotag 115 ifvarl lotag 120 
	{
		shiftvarl initx 6
		ifvare scaled YES shiftvarl initx 1
	}
	getactor[THISACTOR].yvel activator
	getactor[THISACTOR].z initz
	ifvare lotag 102 nullop
	else
	getactor[THISACTOR].zvel topladder
	ifvarg lotag 115 ifvarl lotag 120
	ifvare scaled YES mulvar topladder 2
	setvarvar peractor2 topladder // saves value for elevators
	getactor[THISACTOR].shade initshade
	getactor[THISACTOR].pal playerally // for storing fog pal in water sectors
	getactor[THISACTOR].sectnum mysector
	ifvarg mysector -1 ifvarl mysector 4095
	{
		getsector[mysector].floorpal pal
		getsector[mysector].ceilingpal peractor7
		// search for light models with glow maps
		ifspritepal 1 ifvare lotag 49 
		{
			headspritesect spriteid mysector
		   	whilevarn spriteid -1
		   	{
			   	ifvare sprite[spriteid].extra 4911
			   	{
				   	getactor[spriteid].hitag mtype
				   	setactor[spriteid].hitag 0
				   	setactor[THISACTOR].hitag 0 // light starts OFF
				   	setactor[spriteid].extra 0
				   	setvarvar target2 spriteid
				   	setvar spriteid -1
			   	}
			   	else
			   	nextspritesect spriteid spriteid
	   		}
		}
		ifvarg lotag 48 ifvarl lotag 51 // light
		{
			setvarvar intensity hitag
			headspritesect spriteid mysector
		   	whilevarn spriteid -1
		   	{
			   	ifvare sprite[spriteid].picnum SECTOREFFECTOR
			   	ifvare sprite[spriteid].lotag 150
			   	{
				   	getactor[spriteid].hitag activator
				   	ifvare activator 0 getactor[spriteid].yvel activator
				   	getactor[spriteid].extra temp
				   	ifvare temp 1 // light starts off
				   	{
					   	setvar hitag -1
					   	setactor[THISACTOR].hitag 0
				   	}
				   	setvar spriteid -1
			   	}
			   	else
			   	nextspritesect spriteid spriteid
	   		}
	   		ifvarn activator 0 // search for light models with glow maps
	   		ifvare target2 -1
	   		{
		   		headspritesect spriteid mysector
			   	whilevarn spriteid -1
			   	{
				   	ifvare sprite[spriteid].extra 4911
				   	{
					   	getactor[spriteid].hitag mtype
					   	setactor[spriteid].hitag 0
					   	ifvare sprite[spriteid].lotag 1
					   	{
						   	setactor[spriteid].lotag 0
						   	setactor[THISACTOR].hitag intensity
						   	setvarvar hitag intensity // light starts ON
					   	} else
					   	{
					   		setactor[THISACTOR].hitag 0 // light starts OFF
					   		setvar hitag -1
				   		}
					   	setactor[spriteid].extra 0
					   	setvarvar target2 spriteid
					   	setvar spriteid -1
				   	}
				   	else
				   	nextspritesect spriteid spriteid
		   		}
	   		}
		}
	}

	ifvarg lotag 115 ifvarl lotag 120
	  ifvarl topladder 0 mulvar initshade -1 // correctly sets destination position of elevator
	  
	ifvarg lotag 87 ifvarl lotag 90 // portal cam; find other cam
	{
		getactor[THISACTOR].extra countvar
	
		setvar spriteid 0
		whilevarn spriteid 16384
		{
			ifvarn sprite[spriteid].statnum 1024
			ifvare sprite[spriteid].picnum SECTOREFFECTOR
			ifvarvare sprite[spriteid].lotag lotag
			ifvarvare sprite[spriteid].hitag hitag
			ifvarvarn spriteid THISACTOR
			{
				setvarvar myspawner spriteid
				setvar spriteid 16383
			}
			addvar spriteid 1
		}
		ifvare myspawner -1 { cactor SMALLSMOKE cstat 32768 seta[].statnum 1 }
		ifvare activator 0 setvar peractor1 1
	}

enda

This is exactly what is in Dukeplus, so there are no errors here.

onevent EVENT_GAME
{
    getactor[THISACTOR].picnum picnum
    switch picnum
{

        case LADDER
        {
            ifvare monstflags 1
            {
                ifvare monstatus 0
                {
                    setvar monstatus 1
                    setvar temp 0
                    whilevarn temp 16384
                    {
                        getactor[temp].picnum picnum
                        ifvare picnum LADDER ifvarvarn temp THISACTOR
                        {
                            getactorvar[temp].monstflags tempb
                            ifvare tempb 1
                            {
                                getactorvar[temp].hitag tempc
                                ifvarvare hitag tempc
                                {
                                    setvarvar myspawner temp
                                    setvar monstatus 1
                                    setvar temp 16383

                                    getactor[THISACTOR].z z
                                    getactor[myspawner].z mz
                                    ifvarvarg z mz 
                                    {
                                        setvar mtype 1
                                        setvarvar topladder mz
                                    }
                                }
                            }
                        }
                        addvar temp 1
                    }
                }

                ifvare mtype 1 ifvare dodge 0
                {
                    getplayer[THISACTOR].posz mz
                    ifp pducking subvar mz 4096
                    getactor[THISACTOR].z z
                    addvar z 1024

                    ifvarvarg mz topladder ifvarvarl mz z
                    {
                        getplayer[THISACTOR].i target
                        ldist xydist THISACTOR target

                        ifangdiffl 384 ifvarl xydist 384
                        {
                            ifvare onladder 0
                            {
                                getplayer[THISACTOR].posx lastladderx
                                getplayer[THISACTOR].posy lastladdery
                            }
                            setvar onladder 3

                            ifvarn lotag 0 setvarvar laddersound lotag else setvar laddersound -1
                        }
                    }
                }   
            }
        else
		}

case SECTOREFFECTOR

ifvare lotag 666
{
	headspritesect spriteid mysector
	whilevarn spriteid -1
	{
		getactor[spriteid].picnum picnum
		setvar temp 0
		ifvare picnum APLAYER
		{
			getuserdef[THISACTOR].god tempb
			ifvare tempb NO
			{
				getactor[spriteid].yvel tempb
				getplayer[tempb].dead_flag tempc
				ifvare tempc 0 setvar temp 1
			}
		}
		else setvar temp 1
		ifvare temp 1
		{
			getactor[spriteid].z mz
			ifvarvarg mz initz
			{
				ifvarg topladder 0
				{
					subvarvar mz initz
					setvarvar tempb topladder
					shiftvarl tempb 3
					ifvarvarg mz tempb setvar temp 0
				}
				ifvare temp 1
				{
					setactor[spriteid].htextra 140
					setactor[spriteid].htpicnum RADIUSEXPLOSION
					setactor[spriteid].htowner player[THISACTOR].i
					getactor[spriteid].picnum picnum
					ifvare picnum SAWBLADEGROUND { setactor[spriteid].xrepeat 0 setactor[spriteid].yrepeat 0 }
				}
			}
		}
		nextspritesect spriteid spriteid
	}
}
else ifvare mirrored NO setvar NOCODE 1
else

/// Portal effector
ifvare lotag 88
{
	ifvare peractor1 1
	{
		ifpdistl 32768 // 16384
		{
			ifcansee
			{
				ifvarn portalcam -1 ifvarvarn portalcam THISACTOR
				{
					findplayer xydist
					dist xydist2 portalcam player[THISACTOR].i
					ifvarvarl xydist xydist2
					{
						setvarvar portalcam myspawner
						setvar portalview 52
					}
				} 
				else
				{
					setvarvar portalcam myspawner
					setvar portalview 52
				}
			}
			else ifpdistl 8192
			{
				setvarvar portalcam myspawner
				setvar portalview 52
			}
		}
	}
	else
	{
		checkactivatormotion activator
		ifvare RETURN YES setvar peractor1 1
	}
}
break
}
	case APLAYER // Verifica se é o ator APLAYER
        {
        ifvarn portalcam -1 state kludges
	ifvarg onladder 0 state ladderinteraction
        break
        }
endswitch
}
endevent

Here is how I edited the onevent EVENT_GAME and all the effects in it. The ladder effect works perfectly. The death effect related to lotag 666 also works perfectly. This means that the way I set up the onevent EVENT_GAME is correct, since such effects are occurring.

But the problem is in making "ifvare lotag 88" work. The code is exactly as I got it from the mod, so theoretically there should be no way it could go wrong. In other words, it is as it should be. Then there is an APLAYER case that I set up to load a custom state that I set up for the ladder effect, while for effect 666 it was not necessary.

That's the thing, because what is inside the SECTOREFFECTOR case is not the only block needed to make such a portal effect work. In addition to this, I also found in PLAYERPLUS.CON the "state kludges", which contains:

ifvare rendmode 4 
	{ 
		setvar pal 26
		setvar tempd 2 // 514
		setvar intensity 4096 
		state spawnpointlight 
	}
	setvarvar raining rainstart
	setvar portalview 0
	setvar portalcam -1
	setvar perplayeronbike -1
	setvar triphack -1
	setvar rainstart 0
	setvar temp 99
	whilevarn temp -1
	{
		setarray ptrails[temp] -1
		subvar temp 1
	}

and then

ifvarg portalview 0
{
	subvar portalview 1
	ifvare portalview 0 setvar portalcam -1
}

This seems to be the only relevant part of the portal code and seems to play an important role in loading the effect, although I don't know exactly what it is. So, I did this:

state kludges

	ifvare rendmode 4 
	{ 
		setvar pal 26
		setvar tempd 2 // 514
		setvar intensity 4096 
		//state spawnpointlight 
	}
	// setvarvar raining rainstart
	setvar portalview 0
	setvar portalcam -1
	//setvar perplayeronbike -1
	//setvar triphack -1
	//setvar rainstart 0
	setvar temp 99
	whilevarn temp -1
	{
		setarray ptrails[temp] -1
		subvar temp 1
	}
	ifvarg portalview 0
	{
	subvar portalview 1
	ifvare portalview 0 setvar portalcam -1
}	
ends

Yes, I created a custom state kludges before eventloadactor SECTOREFFECTOR, disabling code not related to that effect.

Still on PLAYERPLUS.CON, further on, there is:

actor APLAYER MAXPLAYERHEALTH PSTAND 0 0

setvar playerally -1

ifvare steroidkicks YES
{
 setvarvar temp gamespeed
 mulvar temp 2
 divvar temp 3
 ifp ponsteroids
 initimer temp
 else
 initimer gamespeed
}
else initimer gamespeed

state checkhitscan
ifvarn botselected -1 state botcommandcode
state kludges

But then I ran out of clues on how to put it in my custom file. All I did was put "state kludges" inside the APLAYER case, but it didn't work.

        case APLAYER // Verifica se é o ator APLAYER
        {
        state kludges
	ifvarg onladder 0 state ladderinteraction
        break
        }

There are also the definitions, that are "gamevar portalcam -1 1" and "gamevar portalview 0 1", but these are already at the beginning of my custom .CON file for additional effects.

These were all the codes I found related to this specific effect in the mod files, unless there is something else that I have no clue what it could be.


By the way...


I managed to replicate the effect of partially shattered glass. Easy! I even did this effect on another glass texture, which also worked, see the code:

gamearray glassarray 2048

useractor notenemy GLASS 50
ifvare lotag 0 break
ifaction 0 ifvare lotag 2 action GLASS4

ifaction GLASSBREAK
{
    ifactioncount 5 
    {
        lotsofglass 10
        setarray glassarray[position] -1
        ifvarvare position highglass subvar highglass 1
        killit
    }
    break
}

ifvarg sprite[THISACTOR].htextra 0 ifvarg hitag 0 ifvare mtype 0
{
    getactor[THISACTOR].htpicnum picnum
    getactor[THISACTOR].htowner myspawner
    setvar spriteid 0
    setvarvar tempb highglass
    addvar tempb 1
    whilevarvarn spriteid tempb
    {
        setvarvar tempc glassarray[spriteid]
        ifvarn tempc -1 ifvarvarn tempc THISACTOR
        {
            getactorvar[tempc].hitag tempd
            ifvarvare hitag tempd
            {
                getactor[tempc].htextra digx
                ifvarl digx 1
                {
                    setactor[tempc].htextra sprite[THISACTOR].htextra
                    setactor[tempc].htpicnum picnum
                    setactor[tempc].htowner myspawner
                    setactorvar[tempc].mtype 1
                }
            }
        }
        addvar spriteid 1
    }
}

ifaction GLASSCRACK strength 0

ifhitweapon
{
    setvar mtype 0
    ifaction GLASS4 { action GLASSCRACK soundonce GLASSCRACKSND } else
    ifaction 0 { action GLASSCRACK soundonce GLASSCRACKSND } else
    ifaction GLASSCRACK { action GLASSBREAK soundonce GLASS_BREAKING }
    ifdead { action GLASSBREAK soundonce GLASS_BREAKING }
    ifaction GLASSBREAK
    {
        getactor[THISACTOR].cstat temp
        ifvarand temp 1 xorvar temp 1
        ifvarand temp 256 xorvar temp 256
        setactor[THISACTOR].cstat temp
    }
}
enda

/////////////////////////////////////////////////////////////////////////////////
///////////////////
/////////////////////////////////////////////////////////////////////////////////
///////////////////
/////////////////////////////////////////////////////////////////////////////////
///////////////////

useractor notenemy GLASS2 50
ifvare lotag 0 break
ifaction 0 ifvare lotag 2 action GLASS4

ifaction GLASSBREAK
{
    ifactioncount 5 
    {
        lotsofglass 10
        setarray glassarray[position] -1
        ifvarvare position highglass subvar highglass 1
        killit
    }
    break
}

ifvarg sprite[THISACTOR].htextra 0 ifvarg hitag 0 ifvare mtype 0
{
    getactor[THISACTOR].htpicnum picnum
    getactor[THISACTOR].htowner myspawner
    setvar spriteid 0
    setvarvar tempb highglass
    addvar tempb 1
    whilevarvarn spriteid tempb
    {
        setvarvar tempc glassarray[spriteid]
        ifvarn tempc -1 ifvarvarn tempc THISACTOR
        {
            getactorvar[tempc].hitag tempd
            ifvarvare hitag tempd
            {
                getactor[tempc].htextra digx
                ifvarl digx 1
                {
                    setactor[tempc].htextra sprite[THISACTOR].htextra
                    setactor[tempc].htpicnum picnum
                    setactor[tempc].htowner myspawner
                    setactorvar[tempc].mtype 1
                }
            }
        }
        addvar spriteid 1
    }
}

ifaction GLASSCRACK strength 50

ifhitweapon
{
    setvar mtype 0
    ifaction GLASS4 { action GLASSCRACK soundonce GLASSCRACKSND } else
    ifaction 0 { action GLASSCRACK soundonce GLASSCRACKSND } else
    ifaction GLASSCRACK { action GLASSBREAK soundonce GLASS_BREAKING }
    ifdead { action GLASSBREAK soundonce GLASS_BREAKING }
    ifaction GLASSBREAK
    {
        getactor[THISACTOR].cstat temp
        ifvarand temp 1 xorvar temp 1
        ifvarand temp 256 xorvar temp 256
        setactor[THISACTOR].cstat temp
    }
}
enda

/////////////////////////////////////////////////////////////////////////////////
///////////////////
/////////////////////////////////////////////////////////////////////////////////
///////////////////
/////////////////////////////////////////////////////////////////////////////////
///////////////////

eventloadactor GLASS
getactor[THISACTOR].lotag lotag
setactor[THISACTOR].lotag 0
getactor[THISACTOR].hitag hitag
setactor[THISACTOR].hitag 0

ifvare clearglassarray 1
{
    setvar clearglassarray 0
    setvar spriteid 0
    whilevarn spriteid 2048
    {
        setarray glassarray[spriteid] -1
        addvar spriteid 1
    }
}

ifvarn lotag 0
{
    setvar spriteid 0
    whilevarn spriteid 2048 // max number of breakable glass sprites
    {
        setvarvar temp glassarray[spriteid]
        ifvare temp -1
        {
            setvarvar position spriteid
            setarray glassarray[spriteid] THISACTOR
            ifvarvarg position highglass setvarvar highglass position
            setvar spriteid 2047
        }
        addvar spriteid 1
    }
}
enda

/////////////////////////////////////////////////////////////////////////////////
///////////////////
/////////////////////////////////////////////////////////////////////////////////
///////////////////
/////////////////////////////////////////////////////////////////////////////////
///////////////////

eventloadactor GLASS2
getactor[THISACTOR].lotag lotag
setactor[THISACTOR].lotag 0
getactor[THISACTOR].hitag hitag
setactor[THISACTOR].hitag 0

ifvare clearglassarray 1
{
    setvar clearglassarray 0
    setvar spriteid 0
    whilevarn spriteid 2048
    {
        setarray glassarray[spriteid] -1
        addvar spriteid 1
    }
}

ifvarn lotag 0
{
    setvar spriteid 0
    whilevarn spriteid 2048 // max number of breakable glass sprites
    {
        setvarvar temp glassarray[spriteid]
        ifvare temp -1
        {
            setvarvar position spriteid
            setarray glassarray[spriteid] THISACTOR
            ifvarvarg position highglass setvarvar highglass position
            setvar spriteid 2047
        }
        addvar spriteid 1
    }
}
enda

Next I'll try to see if I can add the slippery floor effect, which shouldn't be too difficult either.


And here is the little room of death of the SE 666 effect that is working!