ZScript Discussion
Moderator: GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
-
- Posts: 598
- Joined: Sun Feb 24, 2013 4:07 pm
- Location: United Kingdom
Re: ZScript Discussion
That's a shame. I was hoping to change hitscan attacks into projectile attacks without having to replace the monsters themselves (mostly for DeHackEd compatibility).
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
By the way Graf you said that CustomSprite "is not used by anyone", but that's before it was zscriptified
Now it's basically a way to assign ARBITRARY graphic to an actor, from what I can see. Without it needing to be a sprite. Although not sure if such actor should derive from CustomSprite or setting picnum works everywhere.
In practice, this means that we can now (especially with my pull request) do an arbitrarily positioned clipped and postprocessed (using shader) cameratexture! HL2-like portals confirmed? Time to update portal gun mod.
Oh, also if I understand it correctly, we can now also use shaded cameratexture that refers to own actor and relates to player[consoleplayer].camera, in order to for example create air flickering near hot surfaces effect, or zoom stuff.
Now it's basically a way to assign ARBITRARY graphic to an actor, from what I can see. Without it needing to be a sprite. Although not sure if such actor should derive from CustomSprite or setting picnum works everywhere.
In practice, this means that we can now (especially with my pull request) do an arbitrarily positioned clipped and postprocessed (using shader) cameratexture! HL2-like portals confirmed? Time to update portal gun mod.
Oh, also if I understand it correctly, we can now also use shaded cameratexture that refers to own actor and relates to player[consoleplayer].camera, in order to for example create air flickering near hot surfaces effect, or zoom stuff.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
Customsprite had been able to do that for all those years it existed. I changed nothing about it. Its purpose has been to give it a texture number and use the Build texture with the given name as its sprite image. It's just that apparenly nobody ever did.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
Well multiple other features did not exist, namely shaders on cameratextures and proper flatsprites.Graf Zahl wrote:Customsprite had been able to do that for all those years it existed.
Also, any reason why this wouldn't work?
Spoiler:It spawns, but doesn't log anything (i.e. it's a success), but the sprite is not visible.
Does it explicitly check for Build type? If so, why?
Last edited by ZZYZX on Sat Jan 21, 2017 2:58 pm, edited 1 time in total.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
Changed to this
According to GZDoom source code, whenever picnum is valid, it should be applied instead of sprite.
The picture is still not displayed though.
Spoiler:It logs "ok" after creation, and it logs picnum>=0 in both tick and beginplay.
According to GZDoom source code, whenever picnum is valid, it should be applied instead of sprite.
The picture is still not displayed though.
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
Perhaps you need to define a spawn state. I tried doing something similar and assigning a sprite/frame using (post)beginplay via experimentation but it never gave me anything but a missing symbol.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
Actually, for that you do not even need CustomSprite, you can inherit directly from Actor.
All CustomSprite does is setting picnum and a few renderflags from the args, it has nothing built in to display the sprite. Picnum works for any actor.
What I can't say is if I ever implemented handling for this in the GL renderer, because it's such an obscure feature.
All CustomSprite does is setting picnum and a few renderflags from the args, it has nothing built in to display the sprite. Picnum works for any actor.
What I can't say is if I ever implemented handling for this in the GL renderer, because it's such an obscure feature.
Last edited by Graf Zahl on Sat Jan 21, 2017 3:02 pm, edited 1 time in total.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
Hahahah! It works in software renderer. Apparently OpenGL renderer ignores picnum altogether. Bug confirmed? (if yes, I can try to go and understand what causes this and make a PR, as pretty much the only person that's interested)
Last edited by ZZYZX on Sat Jan 21, 2017 3:06 pm, edited 1 time in total.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
Looks like picnum is never checked indeed.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
This can almost be used to avoid the archaic 8-character sprite naming convention, except the problem is calculating the rotation angle and have it affect only the camera who's viewing it...ZZYZX wrote: Now it's basically a way to assign ARBITRARY graphic to an actor, from what I can see.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
It's will be broken with portals, because for doing it properly you have to calculate camera position during exact rendering step, not using playsim camera position/angles.
i.e. in portals camera is warped around, it's angle changed, etc. Will break.
Another use for my event system — preprocess the actor before rendering, say, set picnum or move around shadow actors so that they are always exactly behind the main actor
If for example we need that actor is drawn in a special way depending on where it is viewed from, OR FOR CUSTOM INTERPOLATION, since it's called on each frame.
Since portals and cameratextures are always using almost full rendering pipeline, it should be possible to move actors around before rendering something in a portal, without breaking BSP stuff.
This is probably what I'm going to do as a proof-of-concept implementation.
i.e. in portals camera is warped around, it's angle changed, etc. Will break.
Another use for my event system — preprocess the actor before rendering, say, set picnum or move around shadow actors so that they are always exactly behind the main actor
If for example we need that actor is drawn in a special way depending on where it is viewed from, OR FOR CUSTOM INTERPOLATION, since it's called on each frame.
Since portals and cameratextures are always using almost full rendering pipeline, it should be possible to move actors around before rendering something in a portal, without breaking BSP stuff.
This is probably what I'm going to do as a proof-of-concept implementation.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ZScript Discussion
Documentation says arg1 can be used as the high byte and that doesn't seem to be true anymore.Graf Zahl wrote:Customsprite had been able to do that for all those years it existed. I changed nothing about it. Its purpose has been to give it a texture number and use the Build texture with the given name as its sprite image. It's just that apparenly nobody ever did.
Looking into the file's history, that was changed back in 2014. Well I don't think anybody ever used them with a number greater than 255 in a Hexen map, so I suppose the simplest is to update the documentation to remove the bit about arg1.
-
- Posts: 265
- Joined: Wed Mar 28, 2012 2:27 am
Re: ZScript Discussion
I've looked over the code multiple times but I can't figure out how it all functions and how I can apply it to my game. Could you perhaps break it down for me so I can learn what to do? Thanks for your help.Major Cooke wrote:Soon.ZZYZX wrote:UINever.ZZYZX wrote:networkingbase_player.zs, function UpdateLegsAndBody, line 61. This code smooths player movements and compensates for whenever the player tries to move into an unreachable place.Agentbromsnor wrote:What should I be looking for there? Sorry, but I haven't followed any of the discussion up till now, so I don't have any idea about the context of what tackles this issue.
-
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
Re: ZScript Discussion
Makes sense. Guess I'll keep doing the brute-force method for now.Graf Zahl wrote:No. Once a function is defined it cannot be changed. That would be far too dangerous because its injecting foreign code into existing classes without their knowledge.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
Your custom event idea sounds very promising. I've made a modular character system for my project, which naturally requires a TON of graphics. This is the atrocity I had to come up with to work with 8 letters for sprite frames...ZZYZX wrote:It's will be broken with portals, because for doing it properly you have to calculate camera position during exact rendering step, not using playsim camera position/angles.
i.e. in portals camera is warped around, it's angle changed, etc. Will break.
Another use for my event system — preprocess the actor before rendering, say, set picnum or move around shadow actors so that they are always exactly behind the main actor :)
If for example we need that actor is drawn in a special way depending on where it is viewed from, OR FOR CUSTOM INTERPOLATION, since it's called on each frame.
Since portals and cameratextures are always using almost full rendering pipeline, it should be possible to move actors around before rendering something in a portal, without breaking BSP stuff.
This is probably what I'm going to do as a proof-of-concept implementation.
Code: Select all
Player Part Documentation
-------------------------
SPRITE NAMING CONVENTION:
xxxyza
All parts' class names must be 3 words max.
xxx
----------
3-letter ID; the abbreviated name of the part. Please use UPPERCASE.
Eg:
CMB = Caucasian Male Body
UPF = Under Pants Female
WCB = Weapon Crowbar
SHM = Shirt Male
... etc etc etc
yz
----------
Animation ID. Can be A to Z, 0 to 9, and [ ^ ], giving each part a total of 1521
frames of animation. (26 + 10 + 3)². Please use lowercase.
a
----------
Direction/angle value. Follow standard ZDoom convention (see Angles, middle ring
at http://zdoom.org/wiki/Sprite for details).