No trail bug: this bug will crash JonoF / all ports when playing 1.3/1.3d Grp, after the roids have been used approx 10 times. Looks like a very sporadic bug. This is because 3dr changed the FRAMEEFFECT1 for no reason in the con files. Took me a week to get it. Fix:
Locate all
FRAMEEFFECT1: and do a "or" with FRAMEEFFECT1_13CON:
FRAMEEFFECT1_13CON must take the value 3999.
Eg to "or" it:
case FRAMEEFFECT1:
#ifdef FIX13
case FRAMEEFFECT1_13CON:
#endif
Medkit Bug: it locks weapon change if using medkit at the same time. Fix:
Locate
loc.bits |= ACTION(gamefunc_MedKit)<<16;
Make it conditional to
if(sprite[ps[myconnectindex].i].extra < max_player_health && ps[myconnectindex].firstaid_amount) // avoid medkit overloading controls
Note that changing the
if( !(sb_snum&((15<<8)|(1<<12)|(1<<15)|(1<<16)|(1<<22)|(1<<19)|(1<<20)|(1<<21)|(1<<24)|(1<<25)|(1<<27)|(1<<28)|(1<<29)|(1<<30)|(1<<31))) )
p->interface_toggle_flag = 0;
to fix the medkit problem aint a good idea at all.
------------
Opponent sound in 1.5 code should be a toggle. Good players always play w/ the opponent sound on:
Blimp bug, (shot at blimp while in multi will crash) )This bug will crash JonoF networks games: I sent you an email a few months ago, The prob is related to a bug in the con files in both 1.3 official and 1.5 GNU con files (those released by 3DR) . 1.5 official con files are safe. I havent got any good fix for this... Pl lemme know if you find something better. I'll stick w/ Dave's fix for now with a
case 7:
insptr++;
#pragma message ("Blimp Bug here w/ 1.3 con files or 1.5 Gnu con (1.5 normal are fixed)")
-> if(*insptr == 2048)
-> printf("Will crash. insptr=%d \n", *insptr);
g_t[2] = 0;
g_t[3] = 0;
g_t[4] = *insptr;
insptr++;
break;
Its lame but it works pretty well.
----
Suggestion of standard Inter Duke ID in case we were to make cross netgames compatibility between the duke ports one day. Also quite usefull to detect noobs trying to play w/ different versions of the same port.
buf[0] = 131; // xDuke TAG ID
buf[1] = DUKE_ID;
buf[2] = XDUKE_REV_X; // version x
buf[3] = XDUKE_REV_DOT_Y 3; // version .y
buf[4] = 0; // reserved
buf[5] = 0; // reserved...
buf[9] = 0; // reserved.
// See below for single player mode.
for(i=connecthead;i>=0;i=connectpoint2)
if( i != myconnectindex )
sendpacket(i,&buf[0],10);
Its recovered through the net command 131.
---
Poda's fire bug (fire stuck in dumpster after awhile in 1.3/1.3d). Seems related to the con file. It only affects the fire so I don't think I'll change it.
Edited at
JonoF at
Re: How to improve Jonof stability
matt said
No trail bug: this bug will crash JonoF / all ports when playing 1.3/1.3d Grp, after the roids have been used approx 10 times.
Nice find. Thanks.
matt said
Medkit Bug: it locks weapon change if using medkit at the same time.
I want to get to know this bug better before I use the solution you suggest because I have some concerns about sync which I want to clear in my mind first. Still, thanks for the indication where to start looking.
matt said
Opponent sound in 1.5 code should be a toggle.
Quite true. I'm going to make this a master-selected option in the pursuit of fairness.
matt said
Blimp bug, (shot at blimp while in multi will crash)
I'm almost certain TerminX and I fixed this and related bugs when we added the define/action/state typing system to the label code, so I don't think it should crash JFDuke and EDuke anymore, but I will verify it.
matt said
Suggestion of standard Inter Duke ID in case we were to make cross netgames compatibility between the duke ports one day.
A nice idea, though I've been cooking up a slightly different idea on how I was going to identify JFDuke3D in a standard way with my other Build ports. The packet would look like:
char packetype;
char game[15]; // "JFDuke3D\0\0\0\0\0\0\0"
// "JFShadowWarrior"
// "JFKenBuild\0\0\0\0\0"
long version; // the same number saved into savegames etc to do version checks. useless mostly except for != testing
// and what follows is dependent on the game, but I plan on trying to keep it common so user messages can be given to tell them what sort of game they tried to join
long dataset; // 0 = registered, 1 = shareware
long dataver; // (major<<16)+minor
// Duke: maj=1,min=3: Standard, maj=1,min=5: Atomic
// SW: maj=1,min=2: Reg and share have same ver
The thing is, I'm pondering some ideas on networking and one of them involves a fairly dramatic overhaul of a bunch of operational things, so network compatibility of any sort would be shot. Plus, RancidMeat and JF* ports are already completely network incompatible because Ken's UDP transport protocol is entirely different to the UDP-wrapped DOS protocol RancidMeat uses. You can't send a RancidMeat game packet to JFDuke3D because Ken's network layer will throw it away since it'll be malformed. As a side note, an idea I was investigating last night in fact is to use the Zeroconf protocol, known as Bonjour/Rendezvous in its Apple implementation, for LAN discovery of games but I haven't read very far into things yet to have any idea whether it'd be suitable. I really don't think we'll ever get inter-port compatibility with network games with the way Build games are because things are just too different to guarantee synch.
matt said
Poda's fire bug (fire stuck in dumpster after awhile in 1.3/1.3d). Seems related to the con file. It only affects the fire so I don't think I'll change it.
TerminX has looked at this and apparently it's a CON problem, so it can stay broken for now IMO.
Jonathon
matt at
>Nice find. Thanks.
I want to get to know this bug better before I use the solution you suggest because I have some concerns about sync which I want to clear in my mind first. Still, thanks for the indication where to start looking.
This fix in located in the getinput(), Anything changed in this function will ensure a perfect synch since getinput() is the 'driver' collecting the user's control entries. The fix simulate the user controlling the medkit in fact. It means it will be even synch between a version using that fix and a version using the old medkit lock. That fix is a 10 years old wanted fix. We finnaly got it.
Opponent sound in 1.5 code should be a toggle.
Quite true. I'm going to make this a master-selected option in the pursuit of fairness.
In fact it's not a bug. 3DR changed the sound scheme from 1.3 to 1.5, Thats the main reason why good players hated 1.5 and only noobs were using the 1.5, 3DR never reverted to the 1.3 sound scheme, That's another 5 years old fix people wanted.
matt said
Blimp bug, (shot at blimp while in multi will crash)
I'm almost certain TerminX and I fixed this and related bugs when we added the define/action/state typing system to the label code, so I don't think it should crash JFDuke and EDuke anymore, but I will verify it.
version 20050531 was crashing. I have not tested the latest versions. To test, u need to issue say a /v3 /l8 /m /q2 (blow up the blimp at the stadium) or to be in true multiplayers mode. It won't crash in single player mode.
RancidMeat and JF* ports are already completely network incompatible because Ken's UDP transport protocol is entirely different to the UDP-wrapped DOS protocol RancidMeat uses. You can't send a RancidMeat game packet to JFDuke3D because Ken's network layer will throw it away since it'll be malformed.
True. The netcode can be arranged by either using the same protocol, or using a translator for one of the port to understand the other one. Then comes the synch problem, There is no simple way to synch them. Only way I see is to play the same demo on both ports, printout the randomseed or any parameter that is strictly synch, and check when/why/how it gets different between the 2 ports as the demo runs. Not an easy task at all.
matt said
Poda's fire bug (fire stuck in dumpster after awhile in 1.3/1.3d). Seems related to the con file. It only affects the fire so I don't think I'll change it.
TerminX has looked at this and apparently it's a CON problem, so it can stay broken for now IMO.
Jonathon
It is. Well, The old 1.3 code was able to handle the blimp con code w/o any problem. Not sure why. 2 possibles reasons: 1. the way watcom compiles doesnt trigger a crash (just luck) or 3DR updated some part of the 1.3d code to 1.5 without using #ifdef. So we tru to use 1.3d con code w/ 1.5 c code. (I'm sure we lost some 1.3d code that way, A good proof are 1.3d credits that are not in the 1.5 code nor in the 1.3 grp. There were in the true 1.3d code only and were removed from 1.5. I guess you unassembled the 1.3d code to add it back to ur port ...).
JonoF at
version 20050531 was crashing. I have not tested the latest versions. To test, u need to issue say a /v3 /l8 /m /q2 (blow up the blimp at the stadium) or to be in true multiplayers mode. It won't crash in single player mode.
In that case, we've fixed it.
True. The netcode can be arranged by either using the same protocol, or using a translator for one of the port to understand the other one. Then comes the synch problem, There is no simple way to synch them. Only way I see is to play the same demo on both ports, printout the randomseed or any parameter that is strictly synch, and check when/why/how it gets different between the 2 ports as the demo runs. Not an easy task at all.
And if you ask me, not worth the trouble. The only real way to have a reliable cross-port game is if you take the decision making out of the hands of each peer, ie. make it server-client in the true sense.
It is. Well, The old 1.3 code was able to handle the blimp con code w/o any problem. Not sure why. 2 possibles reasons: 1. the way watcom compiles doesnt trigger a crash (just luck) or 3DR updated some part of the 1.3d code to 1.5 without using #ifdef.
The blimp didn't crash in DOS for the same two reasons most other CON bugs don't crash the DOS game: blind dumb luck and an unprotected memory space. The fragment in the 1.3D CON that used to cause the crash is this one: "action BLIMPRESPAWNTIME", which is illegal because BLIMPRESPAWNTIME is not an action and the CON parser didn't have any idea that was the case. It's amazing more network sync problems weren't caused by errors like these.
So we tru to use 1.3d con code w/ 1.5 c code. (I'm sure we lost some 1.3d code that way, A good proof are 1.3d credits that are not in the 1.5 code nor in the 1.3 grp. There were in the true 1.3d code only and were removed from 1.5.
I imagine most if not all of the real important differences between 1.5 and 1.3D amount to a whole lot of additions and parameter tweaks, because to reclaim the 1.3D functionality we've really only had to comment bits out. I think all the big things happened in the CON code. The fire for instance got retooled as a useractor as I discovered yesterday.
I guess you unassembled the 1.3d code to add it back to ur port ...).
I actually took screenshots of each page of the DOS game and typed it back into the menu code, then screenshot mine and checked that it all lined up with the original using an image editor.
Jonathon
JonoF at
How to improve Jonof stability
Well, I've played with the cheatkeys() function to get each of the functions to work independently of each other rather than in the exclusive manner they have currently, and in my opinion it now works like it should have all along. This is how to do it:
in duke3d.h, make interface_toggle_flag into an unsigned long instead of a short as it is currently.
then, in the same function just below the previous edit, remove the line that reads: p->interface_toggle_flag = 1;
This now means you can press and hold down medkit, nightvis, and shotgun together and each function will activate as you press them, but each of them only once until you release the appropriate key and press it again. If you did it with the previous code, you would have only got the medkit to work until you released all the buttons.
The implication of the hack in getinput() is that as long as the medkit button is held down you will get healed as you get damaged until you release the button. This (a) goes against the historic behaviour of Duke which I want to try and preserve as much as possible in JFDuke, and (b) is so close to cheating without actually being so in my opinion. I believe my solution fixes the odd key characteristics without altering the original behaviour of the medkit function and that's what I'll stick with. If the medkit spammers want the auto-fire style of medkit operation, they can hack their own code and use the getinput() solution.
Jonathon
JonoF at
And BTW, my fix will screw net and demo sync so there'll be a version bump in the next release.
Seems very nice, thx! As you said that will break the demo (i.e makes an oos between someone using the fix and someone using the old toggle), Thats why I did not like to change the toggle function too much (see my 1st post).
But still it's true that it's a good trade off as this fixes all the simultaneous keypresses issues. I dont have time it look at it now, I'll check it lata. I guess the 0xf00 is related to the weapon change. Is the mask really necessary?
JonoF at
0xf00 is (15<<8). It was less parentheses and a bit clearer when I was working with that bit of code. The ((xxx&0xf00)?0xf00:0) is significant because you have to mask all the bits of the weapon selection field if any one of the four bits is set, because the weapon field is a number, not a bitfield.
For the curious, the algorithm works like this:
Get the current flags state.
Mask off any bits that were set last frame, leaving only those that have been set since. This prevents the same functions being activated every frame.
Update the mask to include the new bits that were set...
...and mask off the bits for the functions that were released.
Also, something I just noticed: for safety, I believe the interface_toggle_flag variable should be reset to zero on entry to a level, so in premap.c, in the resetprestat() function, I added "p->interface_toggle_flag = 0;" after the line "p->weapreccnt = 0;". My fear is that the state of the variable could be inconsistent in a network game which might cause sync to blow, so it's good to be safe.
Jonathon
SamSwashbuckler at
Is JFSW being worked on this actively? I certainly hope so! Thanks Jono.
matt at
SamSwashbuckler said
Is JFSW being worked on this actively? I certainly hope so! Thanks Jono.
gee EDF clan is still alive? I was in this clan on Kali maybe 5 years ago.
matt at
JonoF said
The implication of the hack in getinput() is that as long as the medkit button is held down you will get healed as you get damaged until you release the button. This (a) goes against the historic behaviour of Duke which I want to try and preserve as much as possible in JFDuke, and (b) is so close to cheating without actually being so in my opinion. I believe my solution fixes the odd key characteristics without altering the original behaviour of the medkit function and that's what I'll stick with. If the medkit spammers want the auto-fire style of medkit operation, they can hack their own code and use the getinput() solution.
Jonathon
Your solution doesnt alter the game play only if u use the CONTROL_ClearAction in getinput() for any of those action. If not you will have the same effect as an auto-fire. That's ok for the weapon but that will be an issue for all the toggle keys that need synch (holoduke, jetpack etc ..). They will keep going on and off.
edit: my bad ur toogle it's all good :-)
But why
p->interface_toggle_flag |= sb_snum | ((sb_snum&0xf00)?0xf00:0);
p->interface_toggle_flag &= j | ((j&0xf00)?0xf00:0);
instead of
p->interface_toggle_flag = j;
?
Edited at
matt at
another way is to add the clearkey fct in getinput for the function listed in the toggle, which will allow to keep the same toggle code.