EDuke32 Scripting "CON coding help"
#3661 Posted 17 December 2024 - 09:35 AM
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.
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.
#3662 Posted 17 December 2024 - 10:38 AM
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.
#3663 Posted 17 December 2024 - 12:13 PM
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.
#3664 Posted 17 December 2024 - 12:34 PM
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.
#3665 Posted 17 December 2024 - 12:47 PM
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?
#3666 Posted 17 December 2024 - 02:10 PM
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.
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.
#3667 Posted 17 December 2024 - 05:37 PM
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.
#3668 Posted 17 December 2024 - 08:45 PM
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.
#3669 Posted 18 December 2024 - 06:37 AM
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.
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.
#3670 Posted 18 December 2024 - 07:46 AM
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.
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.
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.
#3671 Posted 19 December 2024 - 09:32 PM
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.
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.
#3672 Posted 19 December 2024 - 10:14 PM
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.
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.
#3673 Posted 20 December 2024 - 07:46 AM
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?
#3674 Posted 20 December 2024 - 01:08 PM
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.
#3675 Posted 20 December 2024 - 03:02 PM
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.
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.
#3676 Posted 20 December 2024 - 03:09 PM
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.
#3677 Posted 20 December 2024 - 09:42 PM
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).
#3678 Posted Yesterday, 09:01 AM
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.
#3679 Posted Yesterday, 10:05 AM
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.
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.
This post has been edited by Mark: Yesterday, 10:09 AM
#3680 Posted Yesterday, 10:23 AM
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.
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.
#3681 Posted Yesterday, 11:14 AM
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.
#3682 Posted Yesterday, 01:53 PM
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.
#3683 Posted Yesterday, 03:42 PM
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?
#3684 Posted Yesterday, 04:07 PM
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.
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.
#3685 Posted Yesterday, 04:33 PM
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.
#3686 Posted Yesterday, 10:25 PM
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:
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:
#3687 Posted Yesterday, 11:18 PM
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.