#3 Closed Beta 3xP' CoDJumper mod (Only for CJ members) [TODAY 17:00 UTC+1]

  • Jo Guys,


    Mod is close to be released and now we will start doing closed beta sessions from time to time for cj team members!

    This thread is to report any bugs and ideas!


    if i didnt contact you, contact me in steam when u want to participate todays beta session starting now!


    EDIT: Another closed beta test will take place tomorrow @ 15:00 UTC+1!


    This time i want to test through all gsm commands and check out if the speedrun caster system is working properly
    Also we will search for new bugs as usual

  • Bugs:
    1. I don't know if it's a bug or that you put it to see more information on what's happening but on the left buttom corner of the screen where you see the save position and load position etc. I can also see other peoples loads (and saved?). Anyway, I know you ever put that there just to see extra information on what's happening during actions when the mod is used during a test but I think I'll just point it out.
    2. the sustain ammo has a delay but the animation looks weird (not very bothering imo, just pointing out)


    Ideas:
    1. having a mode where you can enable the 3xp-walkthroughfps-layout for when making a walkthrough. I know Drizzjeh had a '3xP walkthroughmod' but maybe you can add that into this one.
    2. having a shop with a 3xP currency where you can buy certain skins, maybe also where you can buy something where you can send in a skin? (make that a very high price ofcourse so the mod won't get spammed with hundreds of skins) (We both talked about this on Steam before but maybe worth to point the idea-outcome of that conversation out here plus some extra ideas), where you can buy more stuff.
    3. a votingsystem to prevent overplayed maps, as pointed out in a recent other topic. (I know, I don't give a lot of detail, but just worth to think about a system, I don't know if it's possible but is the server able to track how much time a map has been on/played? that could help thinking about a system)


    I understand that those ideas are very timeconsuming to realise them, but the beautiful thing about ideas is that they don't neccesarely need to be realised, it's also okay if it stays by just pointing them out. :>
    Those are the ideas that just came up my mind.

  • 1. I don't know if it's a bug or that you put it to see more information on what's happening but on the left buttom corner of the screen where you see the save position and load position etc. I can also see other peoples loads (and saved?). Anyway, I know you ever put that there just to see extra information on what's happening during actions when the mod is used during a test but I think I'll just point it out.


    yea. It's debug stuff and will be removed. When we started with the menu, we had some trouble with the menu responses. Atm. every /openScriptMenu call will be dumped in the killfeed


    1. having a mode where you can enable the 3xp-walkthroughfps-layout for when making a walkthrough. I know Drizzjeh had a '3xP walkthroughmod' but maybe you can add that into this one.


    I would have packed the walkthrough stuff into an extra gametype, but I'm only the guy who edits the script files. Here you have to ask Drizz, Noob or Viruz


    3. a votingsystem to prevent overplayed maps, as pointed out in a recent other topic. (I know, I don't give a lot of detail, but just worth to think about a system, I don't know if it's possible but is the server able to track how much time a map has been on/played? that could help thinking about a system)


    Atm. I added a cooldown buffer which holds the last 5 played maps. This map won't be in the random maps atm (nominating is still possible). I also know from GSM which map is played how often but not how long. So if you want, you could develop a concept how we could implement a weighted vote.

  • Zitat

    (nominating is still possible).


    It shouldnt be possible :P


    And i dont like forcing player to not play overplayed maps, overplayed maps gets played because they are good :P maps like shade descent_v2 n similar are just running because they are way more fun then other maps, i think the map cooldown of 5 maps is enough

  • Afaik the walkthrough overlays will be in the menus too. Ill talk with viruz today and make some overlays. Anyone is free to bring up own overlays which we can choose from then cuz the more stuff we have to choose from, the sexier the overlays will look like. About the maprotation stuff i agree with viruz in that point. The cooldown of 5 maps is enough.

  • Afaik the walkthrough overlays will be in the menus too. Ill talk with viruz today and make some overlays. Anyone is free to bring up own overlays which we can choose from then cuz the more stuff we have to choose from, the sexier the overlays will look like. About the maprotation stuff i agree with viruz in that point. The cooldown of 5 maps is enough.


    Can you show an example of an overlay? (or the features of an overlay)

  • you could watch one of our youtube walkthroughs. Afaik the shown fps there is just an ingame overlay (HUD Element)


    Alright, if that's the only feature of a walkthrough overlay then I see what such a walkthrough overlay means.


    I also got another idea for the mod, if poss ofcourse:
    4. An acceleration measuredisplay. There is already a speed measuredisplay and a max speed measuredisplay but I think it would be very helpful to see your acceleration as a number than estimating how fast the speed measuredisplay is escalating. The way it could work out as I (as someone who only had physics on school and knows nothing about scripts) imagine is:


    let a script check the speed at a t1 (time 1) and let it check it a second later on t2 and then let it do t2-t1 and display the result of that sum. Let the script repeat that progress each second, so when the progress starts again t2 becomes t1 and let the script measure the new t2 and do t2-t1 again. Now doing it this way I think this would mean that the accelerationdisplay would only refresh every second. You can make it more frequent by letting the script measure t1 at 0 seconds and t2 at 0.1 seconds, then let it do t2-t1 and multiply the result times 10.


    The only thing to do now is translate what I just described into the cod4 scriptlanguage which I personally understand as well as why you would go to the toilet while keeping your pants up.

  • Hmm the way you describe it it seems quite easy. But i dont really think that this is nessecary tbh. But i also use the speedometer very rarely so might have no clue about how an acceleration measurement can be usefull or not. Speedometer for me is only to see if i hit a bounce correctly or if i did the strafe angles correctly.


    What is need to be done before release?

  • I see a list of 11 unfinshed tasks. I think after fixing this tasks we will do some more tests and if all works fine we need to make seperate scripts for local usage, test this and if all works fine we can release :P hue

  • But i dont really think that this is nessecary tbh. But i also use the speedometer very rarely so might have no clue about how an acceleration measurement can be usefull or not. Speedometer for me is only to see if i hit a bounce correctly or if i did the strafe angles correctly.


    I know a few codjumpers, me included, who use the speedometer for some extreme (distance) jumps. We often use it to test jumps in bouncebuilder or to try to perform some hard montagejumps.. I've had some chats in bouncebuilder where we talked about 'this is a 1900 jump', meaning that you need to reach 1900 speed as maxspeed to do the jump, therefore a specific acceleration is required to reach that 1900 speed and having a display which shows your acceleration could help a lot making those jumps more presizely. Also, this means that when it comes to difficulty in the distance of jumps we could figure out some exact accelerationnumbers to relate it to a jumpdifficulty (x/20 scale) since a big part of codjumpskill lies into how well you can accelerate in the game aka how well you can strafe. (to strafe=to accelerate)

  • the idea sounds good.
    One main problem there is, that cod4 has a getVelocity() function which returns the velocity in each direction (x,y,z) as vector. We eliminate the z vector and get the Vectordistance. The vectordistance is your speed.


    The acceleration is a bit harder because CoD4 doesn't have a build-in function for it. Also there are 2 ways of implementation:
    The first one uses normal gsc functions which have a delay of 0.05 seconds. The second one gets called every client frame and would run each 1000/125, 1000/250, 1000/333 milliseconds.


    Do you only need a normal acceleration or the max. acceleration of a jump

  • when uhave the xy speed and time points its easy to get the acceleration,
    one main problem, i also use speedometer sometimes, but it doesnt work that u could say u need 1900 speed for getting the jump, i found myself getting the jump with sometimes lower speed and sometimers higher speed not getting it, also it doesnt rly say anything about correct 333 usage, as it give u height, and velocity is just xy. dunno acceleration is something we can do but not before release

  • Do you only need a normal acceleration or the max. acceleration of a jump


    I don't know if that question was pointed to me but I would say 'a normal acceleration' which just shows your acceleration as I described when I gave the idea. having a max acceleration measuredisplay doesn't really seem useful in my pov.



    one main problem, i also use speedometer sometimes, but it doesnt work that u could say u need 1900 speed for getting the jump, i found myself getting the jump with sometimes lower speed and sometimers higher speed not getting it, also it doesnt rly say anything about correct 333 usage, as it give u height, and velocity is just xy. dunno acceleration is something we can do but not before release


    The reason why it doesn't work all the time even when you reached a higher speed and you still didn't make it or using a lower speed and you do still make it depends on how long you got that speed during your jumpattempt and that is depended on how well you accelerated. Also, talking about a '1900 speed jump' where the 1900 is based on the speed you probably got when you landed the jump is indeed not a very accurate way of making a jump with a specific difficulty. It's better to estimate the average speed you get, but that's really hard to tell since you can only figure that out by paying attention to how long you have let's say about 500 speed, how long you have about 1000 speed, how long you have about 1500 speed and then take the average of those (in relation on how long you got those speeds). Well.. that's not even worth to try to figure out since that goes way too fast to see. However, that all has to do with acceleration, so having an accelerationdisplay which shows your acceleration which will also increase during a jump, just like the speedmeter does, will also be a situation similar to when you would figure out the average speed you got during a jump as when you want to figure out the average acceleration you got during a jump BUT, figuring out the average acceleration would probably be way easier to estimate than figuring out the average speed since the number of the acceleration won't change as much as the number of the speed which means you could figure out an estimation of the average acceleration you got during a jump to relate a more presize difficulty (x/20) of a jump. Could you follow what I am trying to say? ^^


    Edit: oh ye, and as for the height, for when you do a distance or a distance-height jump it's rougly the same and I don't think it doesn't make it impossible to determine the difficulty of a jump. As a jumper you can have way more influence in the distance of a jump than the height of it.

  • for jumping the acceleration doesn't seem important to me in codjumper you only care about your traveled distance and averaged speed. When doing a distance jump while paying attention to velocity you can easily see when it stops increasing and by how much it increases. for height jumps the acceleration seems more important to me because you can see when you begin to fall and how much height you have lost, however if you are using an interval of 0.05 seconds than the measurement error will be a big problem since height jumps need to be accurate because every unit counts.


    as fribeesky pointed out above the average speed is way more usefull when doing distance bounces, this can be easily implemented in the mod by measuring the bounce location and the player location
    after that you can take the difference and subtract that by the elapsed time and you got your average time.

  • EDIT: Another closed beta test will take place tomorrow @ 15:00 UTC+1!

  • EDIT: Another closed beta test will take place tomorrow @ 15:00 UTC+1!


    This time i want to test through all gsm commands and check out if the speedrun caster system is working properly
    Also we will search for new bugs as usual

  • moved it 2 hours back