[VGames]

 Reaper_Man, on 16 December 2024 - 07:53 AM, said:

For testing purposes, can you instead spawn a non-actor sprite or something else that doesn't run code and see if you still get the on-spawn hitching? Or isolate the spawning code into a clean project and test just that. Basically try to rule out whether the problem is spawning stuff in general (as Dan said, spawning is expensive), or if the problem is within the context of the rest of the mod and other code running at-spawn.

Another way you can get around the "spawning is expensive" problem by recycling debris/gibs. This is a concept known as object pooling. Say you have a pool of 100 persistent debris objects, another pool for dibs, and so on. When it comes time to spawn one, you would check how many objects are in your pool. If you have room for more (IE less than 100) you spawn in a new one like normal. But if you have a full pool of objects, rather than spawning a new one, you'd find the oldest debris object and recycle it. Move it into position, re-initialize its animation, movement, etc. just like you would for a new one. This way you skip all of the on-spawn overhead, and you have a finite amount of those objects.

As far as it not spawning enough, add some logging to output something every time it's supposed to be spawning something. It's impossible to say what the issue is there without more context of the entire project or what else is going on.

That pool idea sounds like something that I can work towards. Only allow so many to spawn within a given pool allowance. Thanks for the great tips guys. I’ll try and put this to use and work at it some more.

[Danukem]

 VGames, on 16 December 2024 - 06:25 AM, said:

no matter what I do they never run through the entire list of gibs that are to be spawned. Usually the gibs that are to be spawned at like 4 or 5 tics don’t spawn at all no matter how long I have the gib spawning actor wait to kill itself. And in general the amount of gibs that are spawned with this method are lackluster.

So in other words your code doesn't work as intended and you don't know why. You don't seem to know how to debug it.

[eniojr]

One of the parts I was having the most difficulty with was the EVENT_GAME onevent. At first I still didn't understand that it was necessary to have an associated switch, as well as a specific code to activate the effect inside the case. Here is my EVENT_GAME onevent:

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
                        }
                    }
                }   
            }
            break
        }
		case APLAYER 
        {
        ifvarg onladder 0 state ladderinteraction
        break
        }
    }
    endswitch
}
endevent

And here were the missing codes for the effect to work:

state ladderinteraction
{
    // Lógica de interação com a escada
    ifvarg fpress 0 subvar fpress 1
    ifvarg bpress 0 subvar bpress 1
    ifvarl onladder 0 addvar onladder 1

    ifvarg onladder 0 state laddercode

    ifp ponground setvar nofalldamage 0
    ifvarn nofalldamage 0 setplayer[THISACTOR].falling_counter 0

    ifvarg bhold 7 { setvar btap 0 setvar bhold 0 }
    ifvarg fhold 7 { setvar ftap 0 setvar fhold 0 }
    ifvarg lhold 7 { setvar ltap 0 setvar lhold 0 }
    ifvarg rhold 7 { setvar rtap 0 setvar rhold 0 }

    ifvarvarn timer fpresstime setvar fhold 0
    ifvarvarn timer bpresstime setvar bhold 0

    setvarvar tempb timer
    subvarvar tempb fpresstime
    ifvarg tempb 4 setvar ftap 0

    setvarvar tempb timer
    subvarvar tempb bpresstime
    ifvarg tempb 4 setvar btap 0

    setvarvar tempb timer
    subvarvar tempb lpresstime
    ifvarg tempb 4 setvar ltap 0

    setvarvar tempb timer
    subvarvar tempb rpresstime
    ifvarg tempb 4 setvar rtap 0
}
ends

These codes that I put in the "state ladderinteraction" were inside "onevent EVENT_GAME", but were outside the "case LADDER". I had to do this, put them inside a separate state, otherwise I wouldn't have been able to make it work. And the effect is working just like in the Dukeplus mod. My modification now uses 3 specific sounds for when the player climbs the ladder, which gives a bit more realism.

It's true that my codes don't have a more simplified format or shortcuts yet, but at the moment I'm more concerned with knowing the basics of how to add new effects and other things to the game. As I learn more about the CON language and become more familiar with it, I'll feel more confident in dealing with the game's performance.

[Danukem]

Congratulations, you found the last block of missing code from DukePlus relating to the ladder and pasted it in. I'm not sure what you "learned" about CON from this, other than being more careful to copy all of the relevant code before pasting.

[Danukem]

Why do we have such incredibly low standards in our community for people trying to code? Imagine if someone was posting about learning to map and all they did was talk about how they had a hard time copying and pasting parts of different released maps together. They would be a laughing stock. And yet I have seen essentially the same thing around here but with code many times.

[Reaper_Man]

Because the language is opaque and questionably documented, and the plaintext distribution of any project's scripts means that every mod and Total Conversion is effectively open source.

Sure, everyone has to start somewhere, and CON scripting being someone's entry point into the world of programming is always an interesting choice. But for every Dan Douglas who brings in fresh and genuine creativity, you have a dozen people who think "it works and that's all I care about" and just swim in the wake of those more motivated. Why bother learning to be better at something when one of a handful of people will just do it for you if you pester them enough?

Same as it ever was, though. There's always been a culture of reliance, rather than learning. Again, most people don't actually care to learn, they want it to "just work". Programming has always been the least-represented discipline in "the community" even in the 1.5 days. For whatever it's worth, in my observation, the hangers-on will eventually get bored and move on and never finish their projects because - it turns out - making a whole game is a lot of work.

Why "the community" is small and stagnant is a not-so-separate topic, but there's clearly no lack of broad interest in working with old game engines. Why new people gravitate towards other game communities rather than this one should be a source of introspection, but experience tells me it won't be.

[VGames]

Danukem, on 16 December 2024 - 12:16 PM, said:

So in other words your code doesn't work as intended and you don't know why. You don't seem to know how to debug it.

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.

[Reaper_Man]

IMO Vgames I do think you have improved a lot in the past few years I've been seeing you post. I don't know if you've released something, like I haven't seen a full script or project to review, but you do seem to be understanding the language as well as "what is a programming".

[eniojr]

What I learned was to create a custom state and had it to load inside onevent EVENT_GAME. Don't forget that before I didn't knew about that switch thing related to case syntax. Back then I was lost about it.

I also did some improvements related to the accesscard and accessswitch codes. For example, now when the switch is locked, there are 2 variations of Duke's speech (something the AI wasn't capable to do). And I also added more colors to cards compared to Nuclear Showndown. I had to write codes manually in many occasions. The same thing for the ladder and jumpad effects.

It's just those var and varvar things that still confuses me.

For those who are just starting out in CON, it can be confusing and you end up getting lost. And the documentation regarding these syntaxes is not very intuitive. This is because most of these syntaxes are explained separately. Furthermore, the best way to understand how these syntaxes work within a specific context is through sample models for different purposes, which is limited on the Eduke32 website.

And so you end up having to poke around in mod codes if you want to add or change something that is not documented on that website. Because what is there, for someone who is not a programming expert, does not seem to be enough. More explanatory models are needed, for example, to create new buttons, add effects, new card colors, models that you only find in mods, and even spread across files.

It took a lot of effort, because I had to look for codes in different files related to something specific and organize everything in a single file related to that thing, which was not easy at all. So much so that I had to add lines of code that I ended up having to write myself, even though they were simple. There is also the issue of having a correct order for the codes to work properly.

For example, regarding the ladder codes, I had to test the order of the codes, until I saw that first it should be in this sequence: state pythagoras > state laddercode > state checkwall > state ladderinteraction > eventloadactor LADDER > onevent EVENT_GAME > onevent EVENT_MOVEFORWARD > onevent EVENT_MOVEBACKWARD > onevent EVENT_JUMP > onevent EVENT_PROCESSINPUT and finally, separate the codes for JUMPAD, so there would be no conflict in the loading order. And then it finally worked.

Because of these limitations of explanatory models on the website, I end up not understanding everything that is in the codes for mods and effects and other things that I end up wanting to incorporate into the game. But at least there are certain syntaxes that I already have a certain understanding of, precisely because I had to test codes and their values ​​on several occasions.

That's why I say that what is documented in Eduke32 is more for those who already have a prior understanding of programming language, but for those who are starting from scratch... Unless it's to do simpler things that don't require a lot of code, like breakable objects and simple monsters and babes or simply change something that is already in the game.

So yes, I ended up learning new things that weren't explained on the official website.

Everyone has a different way of starting to learn programming from scratch...

And my way of starting to learn this is by starting to learn the coding patterns, and not specific syntaxes. Once I understand the coding pattern better, I start to understand the use of the syntaxes a little better. In other words, my way of learning this depends a lot on the context the codes that are used.

Maybe that's why I end up having more difficulty with these syntaxes.

[Reaper_Man]

eniojr, on 17 December 2024 - 07:17 AM, said:

For those who are just starting out in CON, it can be confusing and you end up getting lost. And the documentation regarding these syntaxes is not very intuitive. This is because most of these syntaxes are explained separately. Furthermore, the best way to understand how these syntaxes work within a specific context is through sample models for different purposes, which is limited on the Eduke32 website.

Sure, but that isn't what you've done here. Or at very least that's not the way you've presented yourself.

You are correct that seeing working examples, or even real-world usage, of specific commands is a good way to learn how to use them. But you didn't use the DukePlus ladder code as a jumping off point, or a way to learn about syntax and usage. You copied it wholesale into your own mod, because you want ladders, and you want it to "just work". And then to make it worse, you came here proud of your "accomplishment" and seem to want others to commend you.

You didn't have difficulty understanding syntax. You had difficulty knowing what code to copy and paste. You literally said as much.

[Mark]

I'll take a different approach and admit I'm too lazy to learn some of the basics and it makes things tough. Nobody to blame but me. I've done a lot of my own coding from scratch over the years and have had many successes and my fair share of failures. But I could be much further along if I buckled down and learned more instead of floundering as I do. The previously mentioned "its good enough" mentality.

I also learned a lot in the beginning from copy/pasting code from mods and having to figure out what it took to get rid of the 26 errors that popped up along the way along with adding my own tweaks. These days I often hesitate to ask for help because I know I'm lacking in basics and when I get a helpful reply I can't make heads or tails of the technical response I receive and can be too embarassed to admit it. I'll make attempts to figure it out but it doesn't always end in success so I move on to something else. I feel bad because I wasted the time of the helper in that instance. I apologize.

And thanks for all the help you people have given to the community. I did what little I could by bundling together a lot of little code snippits from posts over the years into a "con code tricks" file and have posted it here and elsewhere and sent it to a few who requested it. I still refer to it for ideas.

[VGames]

Reaper_Man, on 17 December 2024 - 07:02 AM, said:

IMO Vgames I do think you have improved a lot in the past few years I've been seeing you post. I don't know if you've released something, like I haven't seen a full script or project to review, but you do seem to be understanding the language as well as "what is a programming".

Thank you. With help from here and loads of examples in existing mods I definitely have a good understanding of Con coding now and I’m trying to get more advanced with it. I use to mess with a lot pre eduke con coding a long time ago but it was never this in depth. Here’s a link to my mod since you didn’t know of it:

https://www.moddb.co...savior-of-babes

It’s doing well and has cut a nice little niche for itself in the duke modding community because of its gameplay style and mass carnage.

Would reducing the number of gamevars to the bare minimum needed help with performance? I’ve got lots of gamevars that I could probably reduce and just use the same ones for different situations instead of making one for each situation. But I wanted to know how taxing gamevar definitions are on the overall performance before I go about doing this because I’m sure I’m gonna run into things I’ll have to fix.

[Reaper_Man]

I did know about that, but I guess I didn't realize it was "out". Whenever I have some time to kill I'll take a look over whatever code you have in there.

VGames, on 17 December 2024 - 08:41 AM, said:

Would reducing the number of gamevars to the bare minimum needed help with performance? I’ve got lots of gamevars that I could probably reduce and just use the same ones for different situations instead of making one for each situation. But I wanted to know how taxing gamevar definitions are on the overall performance before I go about doing this because I’m sure I’m gonna run into things I’ll have to fix.

Reducing gamevars is both less about performance and more about memory, but also about performance. If you have any that are declared and never used, it would be a good idea to get rid of them. If you have 2 (or more) that get used for the same thing then you should refactor your code to just use 1. As a general rule, I have a handful of recurring per-actor vars that I use for all sorts of temporary math and checks: ACTORTEMP / ACTORTEMP2 / ACTORCHECK / ACTORCHECK2 . The "check" ones I try and reserve for anything that returns 0 or 1, and the "temp" ones I try and reserve for math related stuff. But I'll use them whenever necessary. There are very few instances where I need more than 4 temporary vars to accomplish a task.

The poor code pattern I see most often is declaring these sort of per-actor vars, for every actor or enemy or effect. A new "TEMP1" thru "TEMP4" for every enemy. You don't need 4 temporary per-actor vars for an enemy, 4 others for particles, so on. They're per-actor, which more accurately is per-sprite. They're individual to whoever is using them. Similarly, you probably don't need multiple global gamevars for common screen drawing effects. I'll see multiple different X/Y position gamevars to calculate screen drawing, but these can likely all be condensed down too.

I see these poor code patterns most often because A.) the gamevars are declared within the context of some sort of self-contained code snippet that was recycled, and B.) a bunch of code snippets get mushed together with no consideration for the larger project. As Dan said a few pages back, it's common for individual programmers or developers to maintain an internal library of functions, and therefore (at least in my personal scenario) only ever reusing the same handful of named global and per-actor vars.

A project should probably be more than a collection of random effects and disparate code.

[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).