
EDuke32 Scripting "CON coding help"
#1405 Posted 10 March 2014 - 06:03 AM
This post has been edited by James: 10 March 2014 - 06:03 AM
#1406 Posted 10 March 2014 - 11:00 AM
James, on 10 March 2014 - 06:03 AM, said:
I wasn't aware that projectiles stopped monsters, unless the monsters are CON coded to flinch from getting hit. So yeah, I would just code them to only flinch if the damage is over a certain percentage of their hit points.
EDIT: IIRC, the default game code actually makes monsters get pulled towards the player when they get hit. This is one of those things that can be changed in CON, and which you may have changed already, by messing with the monster's xvel or using movesprite on them after an impact.
This post has been edited by Trooper Dan: 10 March 2014 - 12:03 PM
#1407 Posted 10 March 2014 - 12:05 PM
This post has been edited by James: 10 March 2014 - 12:05 PM
#1408 Posted 10 March 2014 - 12:10 PM
James, on 10 March 2014 - 12:05 PM, said:
OK, I'm assuming that you have already verified that the newbeast isn't stopping because of its flinching. It could be that those little movements forward involve it's xvel constantly getting reset every time it is hit -- that would explain it. So what I would do is, save its xvel in a variable each tic when it is not getting hit. When it is hit, set the xvel to the stored variable. I hope that made sense.
#1409 Posted 10 March 2014 - 12:44 PM
#1410 Posted 10 March 2014 - 01:30 PM
and setting a watchpoint on sprite[number_known_from_the_map].xvel shows that the culprit is in sector.c:A_DamageObject().
This function is one of the things that could use some form of scripting interfacing, so that its effects could be selectively disabled.
#1411 Posted 10 March 2014 - 01:42 PM
Helixhorned, on 10 March 2014 - 01:30 PM, said:
and setting a watchpoint on sprite[number_known_from_the_map].xvel shows that the culprit is in sector.c:A_DamageObject().
This function is one of the things that could use some form of scripting interfacing, so that its effects could be selectively disabled.
Thanks for clearing it up, maybe a new spriteflag could be added to disabe that or something?
This post has been edited by James: 10 March 2014 - 01:43 PM
#1412 Posted 12 March 2014 - 06:04 PM
I'm using this as a little hack for a map effect in Link3D. Basically F7 is locked out and over the shoulder view is only accessible once the player has the map. My problem is that when I use the map in one level and switch back to another it doesn't work anymore. It's like it uses old coordinates from the previous level? maybe? Does anyone have any idea why this behaves like this? I've tried reading through some source code to no avail. I've run debug.exe it didn't provide anything useful either.
#1413 Posted 12 March 2014 - 06:29 PM
#1414 Posted 12 March 2014 - 06:38 PM
#1415 Posted 12 March 2014 - 06:56 PM
EDIT: Anyway, from what you have said, I would guess it has something to do with how you are using the loadmapstate command.
This post has been edited by Trooper Dan: 12 March 2014 - 07:07 PM
#1416 Posted 12 March 2014 - 07:12 PM
To answer your question, yes it is based off WGR2 code, but without the pdestination stuff and se 67s, you come back to the map at the point that you exited. The 64 count timer stops going straight back to reload the original map.
edit: added spoiler
This post has been edited by Drek: 12 March 2014 - 08:01 PM
#1417 Posted 12 March 2014 - 07:17 PM
Trooper Dan, on 12 March 2014 - 06:56 PM, said:
EDIT: Anyway, from what you have said, I would guess it has something to do with how you are using the loadmapstate command.
Exactly. What would the old mapstate have in it that I can manually edit to fix this?
#1418 Posted 12 March 2014 - 07:51 PM
Drek, on 12 March 2014 - 07:12 PM, said:
That's what's puzzling me. The code you posted doesn't change the player's position at all, so I don't see how the coords could get messed up.
Does the problem occur the moment the player reenters a map? And what exactly is happening? Did you try DNDEBUG and look at the results (e.g. where the player is on the map).
#1419 Posted 12 March 2014 - 07:58 PM
The maps in question are just different variations of themselves. Each has overworld and dungeons in same location, with starting points being what makes them different. I can plainly see that the over the shoulder on starts where I did it last in the previous map, it (the f7 camera) will "float" or "travel" to where I am now and eventually with many on / off switches begin to work properly again... sometimes, or gets stuck in level geometry, player never dies. I will see what DNDEBUG says.
#1420 Posted 12 March 2014 - 08:05 PM
Drek, on 12 March 2014 - 07:58 PM, said:
Well then it sounds like the crucial part of the code is probably the code associated with pressing alt fire, which you didn't post...
#1421 Posted 12 March 2014 - 08:24 PM
I made a quick video. The only way to describe it short of sharing the tc with you. Which I'm willing to do too. I can pack it up neat tomorrow.
https://www.mediafir...g4lf3j1sxxt5ljk here is my sample video, 4 mins 41 MB, shows off a few weapons and effects too.
#1422 Posted 12 March 2014 - 08:34 PM

But please, please increase Link's walking speed!
As for the bug....looking at the video, it's pretty clearly a problem with the camera positioning, and I don't think you have posted the relevant code. I think you are messing with the camera vars (camerax, cameray, cameraz, cameresect, camderadist). Perhaps you have saved values from a different map, and when you switch to the external cam it is starting from those saved values and the code isn't able to get the camera to a sane position.
EDIT: Try putting the camera vars in your savegamevar/readgamevar routines. Especially your own camera vars, since the ones I mentioned get updated automatically.
This post has been edited by Trooper Dan: 12 March 2014 - 08:41 PM
#1423 Posted 13 March 2014 - 06:15 AM
I'm looking into the camera vars today, but you assumed wrong, I never once manually setup a camera. It is all seen from the perspective of Dukes first person view, with [THISACTOR].ang, and .horiz being forced within certain limits. It's as if the world and link exist down at his feet, very hackish IMO, yet simple and effective.
I'm sure that by playing with the camera vars you mention I'll be able get this world map effect working proper. Still it doesn't explain why my F7 view hack is not working atm, which is irrelevant really.
Thanks again. And yes, Link will be faster.
Added:
I simply added a few lines to log the camera vars when the map gets turned off and on, definitely found the issue with those camera vars. It's logging camerasect as -1 when it's glitchy for me.
Added more: I gave up using over_shoulder_on and just manually coded the same effect by moving the camera. It's actually better this way because it is customizable now.
This post has been edited by Drek: 13 March 2014 - 03:51 PM
#1424 Posted 13 March 2014 - 04:18 PM
#1425 Posted 15 March 2014 - 06:24 AM
Drek, on 13 March 2014 - 06:15 AM, said:
When the third person view is in effect, 3072 is subtracted from the player's z position, after which a hitscan() is issued to determine the ultimate camera position. The initial subtraction may get the camera into void space in very cramped situations, like in the "appended" space ship in E2L1. With revision 4369, when this happens, we try to determine the camera position a second time without the subtraction. This may or may not be the cause for your trouble, but my experiments in said space ship have shown that under Polymer, the outside view tends to be drawn less frequently then (still remaining possible though).
#1426 Posted 15 March 2014 - 06:33 AM
James, on 10 March 2014 - 01:42 PM, said:
Added with r4371.
For actors that you define yourself, usage from CON would be with the spriteflags directive. If you want to modify existing actor's behavior, it gets a little tricky though. The spriteflags directive (i.e. translation-time command) is "destructive" in the sense that it overwrites the previous actor flags with the passed value. This is in contrast to other sprite* directives like spritenoshade, which bitwise-OR them in. So if you wanted to remove the damage-pushing behavior for the newbeast, you'd have to issue "spriteflags 4610 SFLAG_NODAMAGEPUSH" before its definition in GAME.CON. This rules out its usage with mutators, as these get translated after the regular CON files.
In Lunatic, we can have this:
-- Add NODAMAGEPUSH flag to NEWBEAST. gameactor { D.NEWBEAST, AF.chain_end + AF.NODAMAGEPUSH, function() end }
Edit: corrected "spriteflags SFLAG_NODAMAGEPUSH" --> "spriteflags 4610 SFLAG_NODAMAGEPUSH"
#1427 Posted 15 March 2014 - 01:56 PM
onevent EVENT_PREGAME ifactor NEWBEAST { getactor[THISACTOR].htflags temp orvar temp SFLAG_NODAMAGEPUSH setactor[THISACTOR].htflags temp } endevent
#1428 Posted 15 March 2014 - 02:01 PM
How can I script "load last save y/n?" for my TC like eduke32 does running Duke3D?
#1429 Posted 15 March 2014 - 02:02 PM
Drek, on 15 March 2014 - 02:01 PM, said:
How can I script "load last save y/n?" for my TC like eduke32 does running Duke3D?
I think you need to use resetplayer command. Keep in mind it works differently in multiplayer, and ti simply respawn the player...
This post has been edited by Fox: 15 March 2014 - 02:04 PM
#1430 Posted 15 March 2014 - 02:11 PM
This post has been edited by Drek: 15 March 2014 - 05:30 PM
#1431 Posted 16 March 2014 - 04:30 AM
Hendricks266, on 15 March 2014 - 01:56 PM, said:
onevent EVENT_PREGAME ifactor NEWBEAST { getactor[THISACTOR].htflags temp orvar temp SFLAG_NODAMAGEPUSH setactor[THISACTOR].htflags temp } endevent
For reasons of minimality. Having it set "statically" once is preferrable to running the check every game tic * every sprite. Personally, I'm not a big fan of EVENT_{PRE}GAME. First, they tend to spread code belonging together across one more location. For example, your snippet would really belong into the NEWBEAST actor [*]; alas, there's no way to chain actor code in CON. Second, their names suggest that they're run every game tic (which seems more logical as well), whereas it's that times every sprite! This misunderstanding has lead to performance issues in the past, such as with Darkus' flashlight mod, and has also bitten me once.
[*] OK, this argument really applies to code that you wrote yourself in the first place. For NEWBEAST, if you prefer to stay away from modifying the original GAME.CON, there's no difference.
Fox, on 15 March 2014 - 02:02 PM, said:
EVENT_SPAWN should run for both sprites present in the initial map state as well as those spawned during the game. Again, if a particular actor-tile is supposed to have some htflags bit set at any time, it's cleaner to specify that via the spriteflags directive.
#1432 Posted 23 March 2014 - 06:37 PM
#1434 Posted 24 March 2014 - 05:28 AM
I already set the visibility low using .const_visibility, I want to combine the two to get this fade to black effect for Link3D. It only works nice when the ambient light is set low, 0.25.
pic in spoiler