EDuke32 Scripting "CON coding help"
#751 Posted 12 March 2012 - 08:55 AM
#752 Posted 12 March 2012 - 01:41 PM
Diaz, on 12 March 2012 - 08:55 AM, said:
Well it's important insofar as players that don't exist can't activate shit.
#753 Posted 12 March 2012 - 02:07 PM
#754 Posted 18 March 2012 - 07:00 AM
Thanks for helping me out
#755 Posted 18 March 2012 - 08:46 AM
320x240 = 4:3
Duke actually uses 320x200 which is 16:10. Then it does some weird crap and stretches that to fit in various 4:3 resolutions.
So first start there, make your graphic the correct 320x200 resolution and that will "fill the screen" on a 4:3 res. Then in rotatesprite (or myospal or whatever) set your orientation to 1024. Note that this will distort the image, but it WILL cover the screen.
Setting widescreen has no effect on graphics that weren't displayed with orientation 1024 set.
#756 Posted 18 March 2012 - 09:44 AM
#757 Posted 25 March 2012 - 04:46 AM
Is it possible to make it so enemies (hardcoded and useractor enemy) do NOT light themselves up when firing projectiles?
Right now I'm making them notenemy but ofcourse there are some drawbacks, like autoaim not working on them...
#758 Posted 25 March 2012 - 06:28 AM
Diaz, on 25 March 2012 - 04:46 AM, said:
Is it possible to make it so enemies (hardcoded and useractor enemy) do NOT light themselves up when firing projectiles?
Right now I'm making them notenemy but ofcourse there are some drawbacks, like autoaim not working on them...
For the polymer lights Htflags should theoretically do it.
Also... I'm not sure how not being able to autoaim at enemies is a drawback
#759 Posted 25 March 2012 - 06:35 AM
#760 Posted 25 March 2012 - 06:45 AM
James, on 25 March 2012 - 06:35 AM, said:
Shooting a projectile doesn't light anything up though (at least if it's notenemy). The exception to this is polymer, because things like SHOTSPARK1 are coded to cause a light to spawn.
#761 Posted 25 March 2012 - 06:53 AM
Mblackwell, on 25 March 2012 - 06:45 AM, said:
Yeah an enemy actor does become fullbright if they're firing a shotspark weapon, I thought that was what he meant.
#762 Posted 25 March 2012 - 06:53 AM
#763 Posted 25 March 2012 - 07:05 AM
Plagman, on 25 March 2012 - 06:53 AM, said:
Setting the shade manually would be the only way to do it then afaik.
#764 Posted 25 March 2012 - 07:25 AM
This post has been edited by Diaz: 25 March 2012 - 07:26 AM
#765 Posted 25 March 2012 - 08:18 AM
Diaz, on 25 March 2012 - 07:25 AM, said:
Are these enemies you are having the problem with on the regular enemy tile numbers (like PIGCOP, LIZMAN, etc.)?
#766 Posted 25 March 2012 - 01:31 PM
Some enemies are regular tile numbers, and others are useractors. Behavior seems to be the same.
By the way, setting the shade of the sprite to current sector's floorshade in the actor code doesn't seem to work (I guess the hardcoded shading is applied after my code so it has no effect)
EDIT: Nevermind, setting the shade in EVENT_GAME does work. Marvelous!
This post has been edited by Diaz: 25 March 2012 - 01:38 PM
#767 Posted 27 March 2012 - 09:13 AM
onevent EVENT_DISPLAYREST .... setvarvar temp ydim divvar temp 5 mulvar temp 524288 divvarvar temp xdim setaspect 32768 temp // or setaspect 32768 78644 // being 78644 the right value for 4:3 ... for my 5:4 screen it's 83866 but it doesn't change anything. endevent
What is wrong ?
This post has been edited by RichardStorm: 27 March 2012 - 11:13 AM
#768 Posted 27 March 2012 - 09:29 AM
#770 Posted 27 March 2012 - 09:32 AM
#771 Posted 27 March 2012 - 11:14 AM
Quote
Hell yeah! It works... tks
#772 Posted 28 March 2012 - 07:21 PM
marcolino123, on 27 March 2012 - 09:31 AM, said:
This command is useful in other display events as well if you want to stretch things shown via rotatesprite and similar commands. For instance, setaspect 32768 65536 removes the unwanted vertical stretching what is crucial for proper rotation.
#773 Posted 28 March 2012 - 07:28 PM
CraigFatman, on 28 March 2012 - 07:21 PM, said:
That's good to know. I HATE that vertical stretching; it has ruined so many graphics for me. But does that work in all renderers?
#774 Posted 03 April 2012 - 04:20 AM
This post has been edited by Superthijs: 03 April 2012 - 04:53 AM
#775 Posted 03 April 2012 - 04:55 AM
#776 Posted 03 April 2012 - 05:00 AM
I actually mean that, if the cstat is 14, 52 or 25, or something like that, I want to subtract 1 of the cstat.
So I need to check if the sprite is blocked or not.
This post has been edited by Superthijs: 03 April 2012 - 05:00 AM
#777 Posted 03 April 2012 - 05:10 AM
andvar X 0xFFFFFFFE
This is proposed by CraigFatman, but I find the "obvious" version easier to read (and unlikely to be different performance-wide unless used in a tight loop):
ifandvar X 1 subvar X 1
#778 Posted 03 April 2012 - 03:12 PM
Helixhorned, on 03 April 2012 - 05:10 AM, said:
andvar X 0xFFFFFFFE
This is proposed by CraigFatman, but I find the "obvious" version easier to read (and unlikely to be different performance-wide unless used in a tight loop):
ifandvar X 1 subvar X 1
DT suggested:
ifandvar X 1 xorvar X 1
It would be easier if we had nandvar, I think.
This post has been edited by Hendricks266: 03 April 2012 - 03:14 PM
#779 Posted 03 April 2012 - 09:44 PM
Superthijs, on 03 April 2012 - 05:00 AM, said:
I actually mean that, if the cstat is 14, 52 or 25, or something like that, I want to subtract 1 of the cstat.
So I need to check if the sprite is blocked or not.
Use getactor[THISACTOR].cstat CSTAT to get the cstat into a variable called CSTAT. Then you can check if it's already blocking or not by using ifvaror CSTAT 1.
If not, just add 1 to the variable and use setactor[THISACTOR].cstat CSTAT to set the updated value.